I would not. But I think SC has mentioned that the VR beta has this part more or less fixed. So it might not be necessary to comment out that break. The delays of 2 s between checks on the other hand are probably unchanged. Cannot be bothered to check right now.

Originally posted by Finale:

The scripted spawns for different parts of the map are definitely active, but they all show up as zero in the script file dump. Not sure what's going on there. Example of the relevant groups is under "add_prefered_escape_bridge_spawns".

The converter does not check for self._group_data.spawn_type == "group" in contrast to ElementSpawnEnemyGroup:on_executed(instigator). Because that ignores amount entirely. It basically forces an assault or recon group to spawn right here and right now. The exact group type is randomly chosen from the options given; and obeying the assault and recon group chances.

The check has been in the game well before update 100. Though it did not exist when I wrote the converter.

It's a rather silly issue anyway that can be fixed by commenting out the break statement below. I've also noticed that the detection calls are queued in 2 s intervals instead of the 1 s from since the last time I checked (some update <50). So even without the swamped queue, unaware NPCs essentially open their eyes once every 2 s and are blind for the remaining time. Only if they notice something interesting they will check every 0.1 s. That's plenty of time to do some crazy stuff. But there is no way to tell when they are blind and when they are not. And all cameras still check every 0.1 s no matter what.

And after giving it some more thought I have realized that the problem does not exist in the first place because the weights are already correct. Phew, no need to implement anything. I still ought to run a few times with different weapons because the current numbers are based on the Brenner which has lots of hurt animations.

This is just me rambling. Maybe someone has an even better idea that I had not thought of. As you might have noticed, nowadays I don't have that much time, and when I find the time I am rather interested in exploring new gameplay mechanics instead of updating the knowledge on the already investigated mechanics (reading the same file over and over again is not fun if it gets more and more bugs over time).

I assume that you have read the Bots section in the guide.

Anyway, because NPCs aim at the detection point instead of the center of the head, they may miss even on successful shots; or they might hit the legs on a miss. And of course, single shot weapons do not use their accuracy stat at all.

I know that the head is a sphere with 20.15 cm radius and the body/torso is a capsule with 19.2 cm radius and a length of 110 cm. The capsule is angled but I don't know how to access that. It would change anyway depending on stance and animation. Similarly, the detection point is not just offset by a fixed amount, but may not change at all for some head animations.

So while I can run some simple simulations where I just assume that the detection point is 6 cm below the center of the head, where I feed in the head radius and body radius and so on, I think the results are still too optimistic because of various animations messing with the detection point offset.

In the end I decided that running heists and getting data directly is the more reliable approach.

Because more samples mean more reliable data I decided that whenever a bot shoots, I make 360 raycasts in the circle around the target for the different spread values and check how many times the head and body is hit. (I have confirmed that the randomness for spread is indeed fairly random.) I only considered situations where the bot actually shoots to make things a more realistic (with hurt animations and so on), and the (damageless) raycasts should give a good picture of what's going on. Only later have I realized that the model is flawed and tends to underestimate the chances: Say a bot fights two enemies. The first one is killed with one shot and the 360 raycasts all hit the enemy. The second one is protected by cover and is killed after 9 shots where only about 30 raycasts hit each time. The average chance to hit is then 360+9*30 / 3600 = 17.5%. So I assign a greater weight to enemies that are harder to hit.

Solution 1 is to leave out all the extra raycasts and only consider the actual raycasts that are shot. The problem is the small sample size and that I need to run different bot weapons to consider different spreads; before that, I had 360 raycasts for each of the 4 spreads, i.e. 1440 raycasts whenever a bot fired. So that's 1/1440th of the data. An advantage is that because I only consider the actual bot weapons, the hurt animations are perfectly represented (in contrast to bringing along the Brenner and then making raycasts with 25 spread to get sniper rifle spread; snipers are not as much affected by hurt animations because enemies usually die if hit).

Solution 2 is to keep the raycasts and just kill enemies immediately afterwards regardless of their cover. That way I could keep all the raycasts, but ignore hurt animations.

Solution 3 is probably the best of both worlds. Actually I do not need to kill the enemies immediately but could just stop counting. But if I were to do that, the results would be biased towards the first hit, before any hurt animation. I could randomly choose one result for that enemy, or better yet, take the average result. This fixes the false weights. Results might be slightly biased when I use Brenner bots for sniper spread, but that's still better than having 1/1440 of the sample size. Now to implement it...

Done. 11 bundles are not resolved

1f3659cac2f46c1a.bundle
2c2bb98fbf816f3f.bundle
2dccec58121c9b6c.bundle
31c106044eeaf778.bundle
5260b1c4a7cf1ed9.bundle
7e1aa3c5d2fee40d.bundle
a4476c23be98fba4.bundle
b7157694724e46d2.bundle
c65e3b0a042cc9d3.bundle
eeb6eee3c0e55e4e.bundle
ffd74bd8273870dc.bundle

but they are basically empty (~200 bytes) except 31c106044eeaf778 which has some architecture.

Right. It's incendiary grenade as in incendiary grenade fired from grenade launchers. I guess I forgot about the throwable.

This matches one of my comments in the guide some time ago:

Frankelstner
Money. 1-2 on N+H. Else 2 (25%), 3 (50%) or 4 (25%). When that second floor office with the two doors is disabled, 50% chance for +1 money in the safe on N+H.
Coke. Each of the following chances becomes 1 coke if successful, else nothing.
If Normal: Evaluate 4 of the following chances: 40%, 45%, 50%, 50%, 60%, 55%
If Hard: Evaluate 5: 40%, 45%, 50%, 50%, 55%, 60%
If Very Hard: Evaluate 7: 40%, 40%, 45%, 50%, 50%, 50%, 50%, 55%, 60%
Else: Evaluate 9: 20%, 40%, 40%, 45%, 50%, 50%, 50%, 50%, 55%, 60%, 60%, 70%

Frankelstner
With 10 million samples, I get this OK+DW coke distribution: 0: 0.19%, 1: 1.79%, 2: 7.32%, 3: 17.23%, 4: 25.53%, 5: 24.71%, 6: 15.56%, 7: 6.18%, 8: 1.38%, 9: 0.13%

Where are they used? My script strips off anything that is not a file path or found in the strings folder; so I need to know where the hashes are used in the first place to make the script aware that they need to be resolved (keep in mind I just make a massive pool of strings and filter out about 99.99%).

My current setup: https://bitbucket.org/Frankelstner/hashlist-update-script/overview

The main bottleneck is the first part of the Regex function. I've also noticed that I had already iterated over (unique) files, not bundles.