AAS of lantern bot

There are different AAS tables for each AAS size. The AI's aas definition determines which table pathfinding should use.

That is what I mean: Example: AAS96 (since this is the one in question) uses a table that sais "in order to create an AAS area here, each point on the surface must be at least 47 units away from each wall and 96 units away from the next ceiling". With this logic each point on each surface is checked for each AAS present (throug hthe respective entity) and if true is added to form the surface.

This is a room with a width of 100 units, the obstacle in the middle is at a height of 80 units. I added two AAS_flood entities (AAS32 and AAS96). The larger AAS area you can see is for AAS32, the small one (1) is for AAS96. The borders of "1" are exaclty 47 units from each wall and 47 from the obstacle. The larger ones have exaclty 16 units distance to all walls, which are the values for AAS32. If you like, I can check the behaviour for each other AAS_flood entity and each hight, but I think it is pretty clear that the AAS area is calculated as I described.

I verified that the problem is when the AAS file is created, not when the AI is moving at game time.

So the "maxs" height value of "82" defined in aas48 is being used by dmap when it creates the *.aas48 file.

For humanoids, the "maxs" height is "68", which matches the "size" vertical definition of "68" for humanoids.

I examined the doom3 def files, and found numerous monsters using aas48, and their heights were in the "82" range. So aas48 was originally designed for creatures taller than a human, but wider.

So I'm guessing that when these monsters all went bye bye in the early stages of TDM, and the large spider was created, the designer(s) simply dropped him into the now unused aas48 category, w/o moving the height value down from 82 to around 32.

Our only other monster who uses aas48 is the werebeast, and since he doesn't exist yet, we can ignore him in any future changes we make. If he ever shows up, we can give him his own aas designation if that's the right thing to do.

=====================================

So what happens now?

Two paths, as I see it:

1. Change aas48's height value down from 82 to 32 (or so) in the aas.def file. Since the large spider is the only creature using this, we only need to retest existing maps that use the large spider. By a quick count, this is roughly 6 maps. (More digging might reveal a few more from the latest crop of maps.)

a - Leave the affected maps as they are. They'll retain their current behavior, because they were built with versions of dmap where the height value used was 82.

b1 - Re-dmap the affected maps using the new aas48 definition, creating new *.aas48 files for them. Don't change the *.map files. Huge spiders would begin walking under lower ceilings, changing the dynamics of the map.

b2 - Re-dmap the affected maps using the new aas48 definition, creating new *.aas48 files for them. Change the *.map files with the author's permission to either retain the original spider behavior, or take advantage of the new behavior.

2. Create a new aasNN definition with the proper height for huge spiders, and give that to the spiders dropped into maps that would depend on 2.07+.

The same approach would be taken for the lantern bot, which has an incorrect aas96 height definition.

In the case of the lantern bot, he shares aas96 with a not-yet-created humanoid-size guard bot, so this guard bot falls into the same category as the werebeast: not here yet, so ignore him for now.

1. Change aas48's height value down from 82 to 32 (or so) in the aas.def file. Since the large spider is the only creature using this, we only need to retest existing maps that use the large spider. By a quick count, this is roughly 6 maps. (More digging might reveal a few more from the latest crop of maps.)

a - Leave the affected maps as they are. They'll retain their current behavior, because they were built with versions of dmap where the height value used was 82.

If we change the value in the aas def file, will that cause any problems with maps that aren't updated? They won't get an "aas out of date" error? If we can change the def file without affecting current maps, that would be my vote. Any mappers who really want spider behaviour to change in their released map can modify their maps on their own.

The spider_child case is a bit different though, because we can't modify aas32. We would need to create a new aas for spider_child AI. In that case, the easiest option is probably to move the spider_child entities to a deprecated folder and create new entities that use the new aas.

If the AAS48 is only used by the spiders and changes to it won't affect older missions (the problem Springheel describes was the first that came to my mind, too, but if the level has AAS48 areas for all AI, I believe it won't complain and keep the areas as they are until re-dmap), I would defnitely vote for changing the values to fit the spider, as it is quite confusing for new (and apparently veteran) mappers, that openings for them must be quite high, even though they do not look like it. The same goes for the lantern bot. For the guard bot (if it reaches the final stage), I would suggest to intoduce its own AAS; like AAS96t (for "tall") or something similar. Maybe the guard bot AAS could be used for the werebeast as well. That way, the werebeast would need a bit more space to navigate, which can make sense given its hulking nature.

The only problem left in this case would be spider_child, as this would require its own AAS and as a consequence re-dmapping all maps that include this AI. Another option would be to also give spider_child the AAS48, as this would not fit too bad. However, this would also requre re-dmapping all maps, so this would not solve this problem. Maybe Springheels suggestion of a new spider_child for future missions would be quite good. It would solve the problem for future releases and not affect the old ones.

Regarding not affecting older releases: Would it make sense to have a cut reagarding downward compatibilites of older missions at some point and just keep one older verion of TDM (e.g. TDM-classic; or stop at v2.07 and continue at v3.0) for all older missions to run on? Then a new version could be created, in which all the workarounds and deprecated stuff necessary for downward compatibility could be ditched. Personally, I have the feeling that the requirement to keep older missions working (which I completely support in itself as I find it very desireable) is impeding the progress of newer verions and is causing TDM to get unnecessarily bloated code and asset wise, but maybe I am mistaken here. If nothing else the number of maps that has to be tested for new features, which is steadily increasing, would be cut down.

This is just a thought I recently had and wanted to suggest. What do you think about that?

I fear that dmaping old maps under 2.06 will cause some hidden unexpected troubles, not only graphics' glitches but i.e. AI getting stuck for no reason, as it sometimes occurs between builds with small unrelated changes.

Heritage versions of AI, models and other should be very clearly separated from the rest or newer mappers will get confused, but we definitely need aas that fits actual AIs.

Even now we have TDM version compatibility sometimes mentioned in darkmod.txt but you need to exactly know what it means to use it properly (and I don't see older versions of TDM in download section anyway). If this distinction will ever take place we need "TheDarkMod part2" and missions specific for TDM2, casual players want just turn it on and go, not some 2.54744578547 build of seemingly the same thing.

BTW will ever humans be able to crouch in lower passages, does anyone care about this option? (I know we don't have animations for even less complicated things but it could be a game changer).

I played around a bit more with AAS definitions and ran into a problem: for some reason, when I change the "use_aas" spawnarg in DR, it is not registered by TDM (or rather dmap?). I tried with different AI, but changing the spawnarg did not affect dmapping. If I wanted to use a different AAS, I had to change the spawnarg in the defintion of the AI.Could it be that dmap does not check for any changed use_aas spawnargs in the map, but only checks entity types and the according AAS definitions in the def files? Would make sense, as this saves resources and time, but it should maybe be noted in the help text of the spawnarg.