Jump to content
The Dark Mod Forums

AAS of lantern bot


Destined

Recommended Posts

Hi all,

 

I just noticed that the lantern bot has "use_AAS" "aas96" even though it is only 48 units high. Is there any specific reason for that or is that simply a typo or the initial plan to make it bigger? The base is roughly 60x35 units, so it is also smaller than would justify an AAS of 96. The reason I noticed is, because JackFarmer wanted it to crawl through a couple of holes in his map (height 56) and the bot would not walk through, which makes sense, if it uses AAS96. I think this may happen to more map authors as the bot looks much smaller than its AAS suggests.

Link to comment
Share on other sites

The size of the aas does not relate to the height of the unit, but to the size of the space it requires on the floor it is walking on. So it depends on length and broadness.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Really? Each AAS has a width depth and height (width and deth are also 47, not 48 each for AAS96, which is no bid deal, but still not really the given value) How is the height determined? The holes in JackFarmers map are big enough for all parameters (except height) and the regions get no AAS assigned, so it must be a height problem (did not test it, yet; will try this evening or tomorrow morning).

Link to comment
Share on other sites

Height gets involved in two ways:

 

1. An AAS area will not be created if there's no room above that potential AAS area for the AI's bounding box to fit.

 

2. For a flat surface, the AAS area will sit on the surface, and itself have no height.

 

3. For a slanting surface, if the AAS area crosses the area, and the surface is higher at one end then at the other, the AAS area will have a vertical dimension.

 

 

If you want to see the AAS areas for the bot, in DR, select "View->AAS Area Viewer", and in the dialogue box, select aas96. DR will paint the AAS areas on the screen. Look to see that an AAS area is being painted (created) inside the tunnel where the bot is supposed to creep. If not, you'll need to raise the height of the tunnel to satisfy #1 above.

 

If "View->AAS Area Viewer" doesn't appear in your DR version, install the latest from here.

  • Like 1
Link to comment
Share on other sites

There is some kind of issue with height., even if it's not specifically AAS related. I couldn't get spiders to walk through areas with low ceilings when updating St. Lucia. I forget exactly what the problem was, but it was something like all AI having bounding boxes of humanoid height, no matter how small they actually are.

Link to comment
Share on other sites

Height gets involved in two ways:

 

1. An AAS area will not be created if there's no room above that potential AAS area for the AI's bounding box to fit.

 

2. For a flat surface, the AAS area will sit on the surface, and itself have no height.

 

3. For a slanting surface, if the AAS area crosses the area, and the surface is higher at one end then at the other, the AAS area will have a vertical dimension.

 

 

If you want to see the AAS areas for the bot, in DR, select "View->AAS Area Viewer", and in the dialogue box, select aas96. DR will paint the AAS areas on the screen. Look to see that an AAS area is being painted (created) inside the tunnel where the bot is supposed to creep. If not, you'll need to raise the height of the tunnel to satisfy #1 above.

 

If "View->AAS Area Viewer" doesn't appear in your DR version, install the latest from here.

I did not know, that DR itself can show AAS areas. I will definitely check this.

 

There is some kind of issue with height., even if it's not specifically AAS related. I couldn't get spiders to walk through areas with low ceilings when updating St. Lucia. I forget exactly what the problem was, but it was something like all AI having bounding boxes of humanoid height, no matter how small they actually are.

usually AI have the mins and maxs spawnargs that define their size. I once got a ghost character to seemingly walk through a wall by giving it a height of 1 through these args and using nonsolids in an extremely narrow tunnel, so it is possible. I thought I had to create a special AAS for that character as well, as this tunnel was not considered, so I expected the AAS areas to be determined according to the AAS height, not the bounding box. I will check the bounding box of the lantern bot and can have a look at the bounding box of the spiders as well.

Link to comment
Share on other sites

I checked the def files and found that AI ususally do not have a bounding box defined, which is why I assume that the bounding box is defined by the used AAS. I created an individual AAS for the spider bot that better describes its boundaries and with that it appears to work. Comparing the size of the bounding box of AAS96 with a guard, I suppose it was supposed to be used on a tall walker bot Thief 2 style as it is a bit taller and much wider than a human guard. Since it was defined in the steambot_base entity, it was transfered to the much smaller lantern bot as well. I would suggest to use a more suitable AAS for the size of the lantern bot (this is only changing one line in a def file, os not too much trouble).

 

Regarding the spiders: They use the AAS48, which also descibes the boundaries not too well. The standard spider requires an area of 74 x 68 and aheight of 24 (as measured in DR). The AAS48 covers an area that is smaller than the area required by the spider (48 x 48) and requires a height of 82, which is much too high for a spider that only has a height of 24. I am not sure for which entities these AAS types were made, but I would suggest to create new ones. I will have a look at suitable sizes, when I find the time.

Link to comment
Share on other sites

I checked the def files and found that AI ususally do not have a bounding box defined,

 

What were you looking for?

 

The bounding box on an entity (including AI) is defined either by a "mins"/"maxs" keyword pair, or the "size" keyword.

 

In the case of the lantern bot, he has this line in his def file:

 

"size" "56 48 48"

 

 

I'm interested in knowing which AI you think don't have a bounding box.

 

Edit: The large spider has this:

 

"size" "32 32 30"

 

This size might be smaller than what you can measure in DR because the designer is treating the legs as "outside the bounding box" because they're just appendages to the main body of the beast.

Link to comment
Share on other sites

Regarding the spiders: They use the AAS48, which also descibes the boundaries not too well. The standard spider requires an area of 74 x 68 and aheight of 24 (as measured in DR). The AAS48 covers an area that is smaller than the area required by the spider (48 x 48) and requires a height of 82, which is much too high for a spider that only has a height of 24. I am not sure for which entities these AAS types were made, but I would suggest to create new ones. I will have a look at suitable sizes, when I find the time.

Could this explain why spiders exhibit odd behaviour (getting temporarily stuck or circling for a time) in many missions?

Link to comment
Share on other sites

I am not sure for which entities these AAS types were made, but I would suggest to create new ones. I will have a look at suitable sizes, when I find the time.

 

If you're going to "create new ones", they'll have to be map-specific. We can't change the defaults, because we have 100+ maps that rely on those defaults.

Link to comment
Share on other sites

Could this explain why spiders exhibit odd behaviour (getting temporarily stuck or circling for a time) in many missions?

 

That's a leap. Why a spider gets stuck or circles should be investigated by examining the map where this happens.

Link to comment
Share on other sites

There is some kind of issue with height., even if it's not specifically AAS related. I couldn't get spiders to walk through areas with low ceilings when updating St. Lucia. I forget exactly what the problem was, but it was something like all AI having bounding boxes of humanoid height, no matter how small they actually are.

 

"all AI having bounding boxes of humanoid height"

 

Where does this idea come from?

Link to comment
Share on other sites

 

"all AI having bounding boxes of humanoid height"

 

Where does this idea come from?

 

It's from when you and I tested the spiders in the revised St. Lucia. I can't find the thread anymore, but the problem was spiders not being able to pathfind through areas with low ceilings. I forget the details, but it had something to do with the spiders requiring the same height as other AI.

Link to comment
Share on other sites

If you're going to "create new ones", they'll have to be map-specific. We can't change the defaults, because we have 100+ maps that rely on those defaults.

(I suspect you already understand this implication but here goes...)

 

If this is truly a problem, I think the solution is to create spider_new, lanternbot_new, etc entities for a future TDM

version so that new missions can have proper AAS behavior while not needing to recompile all old maps. We can then

fix the old maps at our leisure if so inclined.

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

But the old maps already work. Whats to fix?

True. But if the spiders (etc) can chase the player better due to having better AAS there may

be some incentive to improve things. (At mapper discretion of course.)

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

Here's the issue. See the map below. When the selected brush is absent, spider_child patrols back and forth normally.

 

When you add that brush, spider_child does not patrol to distant pathnode. This is because he does not understand that he can fit under the brush (even though he clearly should be able to).

 

I don't know exactly WHY he doesn't think he can fit under the brush--from the previous conversation years back I thought it was because the height was set to the same height as a humanoid AI.

 

But regardless of the reason, it's not ideal that spiders can't go where they look like they should be able to go. Mappers cannot put spiders in vents or other low areas that players can access by crouching.

post-9-0-60856900-1529592152_thumb.jpg

  • Like 1
Link to comment
Share on other sites

 

What were you looking for?

 

The bounding box on an entity (including AI) is defined either by a "mins"/"maxs" keyword pair, or the "size" keyword.

 

In the case of the lantern bot, he has this line in his def file:

 

"size" "56 48 48"

 

 

I'm interested in knowing which AI you think don't have a bounding box.

 

Edit: The large spider has this:

 

"size" "32 32 30"

 

This size might be smaller than what you can measure in DR because the designer is treating the legs as "outside the bounding box" because they're just appendages to the main body of the beast.

Sorry, I was used to the bounding box being described via the "mins" and "maxs" spawnargs and missed the "size" spawnarg. Regarding the legs: fair enought; personally I would include them to the bounding box to avoid clipping issues. This was acuatlly, why I thought that AAS96 was used for them. Otherwise AAS48 would have sufficed to describe their size.

 

 

 

If you're going to "create new ones", they'll have to be map-specific. We can't change the defaults, because we have 100+ maps that rely on those defaults.

I know that this is has to be tested, but I am under the assumption that it would only increase the moveability of spiders as the size would be decreased. I have no idea how much mappers rely on spiders not getting to specific places by creating tunnels, where they don't fit, but would suspect that only a minimal part (if any) would be affected by the change as spiders would still be able to go where they have gone before. They just can go to a couple of additional places. As long as they are patroling this should make even less difference.

 

 

Here's the issue. See the map below. When the selected brush is absent, spider_child patrols back and forth normally.

 

When you add that brush, spider_child does not patrol to distant pathnode. This is because he does not understand that he can fit under the brush (even though he clearly should be able to).

 

I don't know exactly WHY he doesn't think he can fit under the brush--from the previous conversation years back I thought it was because the height was set to the same height as a humanoid AI.

 

But regardless of the reason, it's not ideal that spiders can't go where they look like they should be able to go. Mappers cannot put spiders in vents or other low areas that players can access by crouching.

This behaviour would fit the observation that the spider uses AAS96, which requires a minimum height of 96 units. Humanoids use AAS32 with a height of 68, even lower than the spiders'. I have not enough knowledge from the coding side, to be sure how pathfinding is determined, but I was under the impression that the available areas are calculated from the AAS of all entities in a specific area. As a consequence, I supposed that for these calculations not the acutal size, but the AAS is used (mainly to safe recources, as it is easier to use a limited amount aof AAS values instead of comparing the size of each entity with the dimensions of each opening). This (I thought) is also the reason, why we have to place AAS_flood entities in areas, where no AI is at map start, as the pathfinding cannot be detrmined afterwards.

Link to comment
Share on other sites

I am under the assumption that it would only increase the moveability of spiders as the size would be decreased.

 

That's the problem. If an existing map relied on the moveability of spiders (and conversely, the non-moveability of spiders), and suddenly spiders are free to roam into smaller places, it might wreck the mission.

Link to comment
Share on other sites

I was under the impression that the available areas are calculated from the AAS of all entities in a specific area.

 

AFAIK, no.

 

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

Link to comment
Share on other sites

Here's the issue. See the map below. When the selected brush is absent, spider_child patrols back and forth normally.

I don't know why this behavior occurs. Someone would need to debug the situation.

 

If you use DR's View->AAS Area Viewer feature, does it show AAS areas covering the spider's path w/o the blocking brush, and not covering the spider's path with the blocking brush?

Link to comment
Share on other sites

I don't know why this behavior occurs. Someone would need to debug the situation.

 

 

You debugged it a few years ago. Frustratingly, I can't find the thread. It was when we were beta-testing the updated St. Lucia.

 

 

If you use DR's View->AAS Area Viewer feature

 

Where do I find that feature?

Link to comment
Share on other sites

 

That's the problem. If an existing map relied on the moveability of spiders (and conversely, the non-moveability of spiders), and suddenly spiders are free to roam into smaller places, it might wreck the mission.

This is true if there are missions that rely on the non-moveability. The question is whether there are any and if so whether the mappers didn't monsterclip the specific areas anyways? Spiders are not the most common ai used.

 

Imho it is at least worth investigating to see what's the case, as I think it would be a much cleaner solution to update the defs instead of creating new one or rely on mappers doing that, which would probably only lead to inconsistencies and player confusion.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recent Status Updates

    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...