Jump to content


Photo

AAS of lantern bot


36 replies to this topic

#26 Destined

Destined

    Advanced Member

  • Member
  • PipPipPip
  • 1560 posts

Posted 22 June 2018 - 01:33 AM

 

AFAIK, no.

 

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.



#27 grayman

grayman

    Master Builder, Coder

  • Active Developer
  • PipPipPipPipPip
  • 12676 posts

Posted 22 June 2018 - 08:46 AM

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. 

 

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

 

Discussion?



#28 grayman

grayman

    Master Builder, Coder

  • Active Developer
  • PipPipPipPipPip
  • 12676 posts

Posted 22 June 2018 - 09:01 AM

Better detail on the spider situation ...

 

 

atdm:ai_spider uses aas48. (So AAS areas require a ceiling height of 82 for the spider to walk them.)

 

atdm:ai_spider_thin - ditto

 

atdm:ai_spider_huge - ditto

 

atdm:ai_spider_huge02 - ditto

 

atdm:ai_spider_child uses aas32. (So AAS areas require a ceiling height of 68 for the spider to walk them.)

 

atdm:ai_spider_tiny uses aasrat. (So AAS areas require a ceiling height of 12 for the spider to walk them.)

 

 

 

Since there are 5 spider types using incorrect aas* settings, the number of maps using them will be higher than 6.



#29 Springheel

Springheel

    Creative Director (retired)

  • Admin
  • 37376 posts

Posted 22 June 2018 - 09:39 AM

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.


TDM Missions:   A Score to Settle   *   A Reputation to Uphold   *   A New Job   *    A Matter of Hours
 
Video Series:   Springheel's Modules   *   Speedbuild Challenge   *   New Mappers Workshop  *   Building Traps

#30 Springheel

Springheel

    Creative Director (retired)

  • Admin
  • 37376 posts

Posted 22 June 2018 - 09:46 AM

It's in the menu at the top of the DR screen.

 

If you don't see it, then upgrade to the latest DR and it'll show up.

 

I have the most recent one I know of (2.6.0?) and don't see that option.  Am I missing something?

Attached Thumbnails

  • 777.jpg

TDM Missions:   A Score to Settle   *   A Reputation to Uphold   *   A New Job   *    A Matter of Hours
 
Video Series:   Springheel's Modules   *   Speedbuild Challenge   *   New Mappers Workshop  *   Building Traps

#31 grayman

grayman

    Master Builder, Coder

  • Active Developer
  • PipPipPipPipPip
  • 12676 posts

Posted 22 June 2018 - 09:58 AM

aas.jpg



#32 Springheel

Springheel

    Creative Director (retired)

  • Admin
  • 37376 posts

Posted 22 June 2018 - 10:32 AM

Thanks, now I see it.


TDM Missions:   A Score to Settle   *   A Reputation to Uphold   *   A New Job   *    A Matter of Hours
 
Video Series:   Springheel's Modules   *   Speedbuild Challenge   *   New Mappers Workshop  *   Building Traps

#33 Destined

Destined

    Advanced Member

  • Member
  • PipPipPip
  • 1560 posts

Posted 23 June 2018 - 04:40 AM

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?



#34 ERH+

ERH+

    Advanced Member

  • Member
  • PipPipPip
  • 719 posts

Posted 23 June 2018 - 05:29 AM

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).


Edited by ERH+, 23 June 2018 - 05:37 AM.

S2wtMNl.gif


#35 Springheel

Springheel

    Creative Director (retired)

  • Admin
  • 37376 posts

Posted 23 June 2018 - 07:43 AM

BTW will ever humans be able to crouch in lower passages,

 

 

Not likely, for multiple reasons.

 

Are there any existing games that include this?


TDM Missions:   A Score to Settle   *   A Reputation to Uphold   *   A New Job   *    A Matter of Hours
 
Video Series:   Springheel's Modules   *   Speedbuild Challenge   *   New Mappers Workshop  *   Building Traps

#36 ERH+

ERH+

    Advanced Member

  • Member
  • PipPipPip
  • 719 posts

Posted 23 June 2018 - 08:18 AM

I didn't found any clues it does, but couldn't AI use two aas exchangeable just with different stance?

 

I found this article

https://www.rockpape...erson-shooters/

I would thought jumping from a higher ground or go over a table would demand more calculations than "change stance here".


S2wtMNl.gif


#37 Destined

Destined

    Advanced Member

  • Member
  • PipPipPip
  • 1560 posts

Posted Yesterday, 04:21 AM

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.


  • VanishedOne likes this



Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users