Originally posted by blinya:

ATM's frontal cover has little blind spot in center of hitbox.
http://images.akamai.steamusercontent.com/ugc/84844125211657665/4569166E285BF8325F7C83CA72B9870FBEF82D4F/

It does not work like that. We have two parts:

A) the visible model
B) the (invisible) collision mesh

Ideally, the collision mesh follows the visible model exactly. But in reality it is simplified for better performance. I don't know how to hide A or show B. So we scan the world for collision meshes.

Now remember that A cannot be hidden. If B is smaller than A (due to simplification), then we see no green points because A is blocking the line of sight.

The only fix that I know is to increase the radius of the points, IIRC:

:sphere( col_ray.position, 1 )
=>
:sphere( col_ray.position, 10 )

But then it looks a bit ugly.


Anyway, I think the deposit boxes indeed have this tiny gap.

Enemy spawn points are shown with: managers.groupai:state():set_debug_draw_state(true)

Some other stuff is found here: http://gtm.steamproxy.vip/groups/pd2mech/discussions/0/451850468376386445/

IIRC the warp.lua does crash the game when going into the menu, though I don't remember for sure. Some other scripts might also be outdated. Let me know.

Anyway, I have not investigated interactive points (cones?). And for collectibles I teleport from place to place with warp.lua. Just copy+paste parts from the mission scripts and press the hotkey to teleport from place to place.

I don't remember if those files include a way to execute mission elements. But I do have a script for that somewhere; e.g. look at the raw mission scripts and find the id of the element that spawns 1 keycard in one of 10 different places, then execute that element on keypress 20-30 times more. The map now has keycards in each place (and depending on map, maybe several keycards at the same spot). Then either teleport from place to place or use contour mods to see them through walls.

Added. Are these textures used by the game?

Yeah. This is just grand. So at some point I thought that I should use Cython to improve performance. Then rewrote the most critical parts into that Cython language (which is not valid Python). Which then turned a few KBs of scripts into several MBs of C source and then somehow compiled them into .pyd files instead of the .py used by normal files. Apart from Cython occasionally deciding not to re-convert or even do anything after I just commented out some parts from my Cython source (just deleting those lines worked correctly however, sigh), I did not notice any performance improvement and lost all the flexibility of Python.

Now here's the kicker, even the standard Python can apparently import .pyd files just fine. So I had a module "extract.py" and a module "extract.pyd" in the same folder, and the latter was given priority. Cython messing with me even after I abandoned it...

Thanks for letting me know. I hope I've wiped out Cython completely now.

Which script? I have ~5 different scripts that visualize ~5 different things.

Ah, my bad. Internally I run a larger hashlist based on what the bundle modder used. That larger hashlist can only grow. I check the .blb file for which hashes are actually used in this update and remove the unused entries from the larger hashlist. My function removed a bit too much. I didn't notice because my file extractor does not add that middle part in the first place.

Alright, the next list will include those too and the heuristics are updated as well. I'm pretty sure that the vast majority of the remaining files is unused, as shown by Ellie's zeal_bulldozer_halloween_husk.

One open question is whether the goal is to resolve all pathnames or resolve only exactly the pathnames that are used. At this point I'm already confident that these heuristics are better at determining file dependencies than the dev tools.

I wonder if it's worth just dumping the list of unresolved pathnames in a bug report. (But then I might even have to downgrade my script because it already resolves many unused files.)

Nah, I'm talking literally nanometers:

- position -0.00258636, -1142.0, 50.0
+ position -0.00261688, -1142.0, 50.0

1 unit is 1 cm. Some civ spawn has been moved 300 nanometers and that adds some line noise to those automatic changelogs.

Jimmy's bartender:

- Spawn civ: civ_male_bartender_chill (1800.0, -0.00205994, -3.0)
+ Spawn civ: civ_male_bartender_chill (1800.0, -0.00209045, -3.0)

I just realized, the overkill_290 implementation literally does that check for nil which means that whenever an ElementFilter has no DW values defined, it just checks the OK values instead. When an ElementFilter has no MH or OD values defined, it just returns false on those difficulties. Great.

For reference, part of the ElementFilter.lua file that implements the logic of ElementFilters.
easy is not used,
normal is N,
hard is H,
overkill is VH,
overkill_145 is OK,
easy_wish is MH,
overkill_290 is DW,
sm_wish is OD.

I don't know when exactly the guards were added. This is the classic stuff that is changed without mention in the changelog. At least with the converter being fully deterministic now, and with the issue of the hashlist resolved, it will be easier to spot such changes earlier. Although they could tone down the "randomly moving objects by some hundred nanometers" part.