Jump to content


Photo

AAS of lantern bot


35 replies to this topic

#1 Destined

Destined

    Advanced Member

  • Member
  • PipPipPip
  • 1494 posts

Posted 20 June 2018 - 01:37 AM

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.



#2 Obsttorte

Obsttorte

    Scripting guru, Mapper

  • Active Developer
  • PipPipPipPipPip
  • 5581 posts

Posted 20 June 2018 - 03:28 AM

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
WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.
Mapping and Scripting: Apples and Peaches
Sculptris Models and Tutorials: Obsttortes Models
My wiki articles: Obstipedia
Let's Map TDM YouTube playlist: ObstlerTube
Texture Blending in DR: DR ASE Blend Exporter

End of shameless self promotion.

#3 Destined

Destined

    Advanced Member

  • Member
  • PipPipPip
  • 1494 posts

Posted 20 June 2018 - 05:23 AM

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



#4 grayman

grayman

    Master Builder, Coder

  • Active Developer
  • PipPipPipPipPip
  • 12552 posts

Posted 20 June 2018 - 08:37 AM

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.


  • Destined likes this

#5 Springheel

Springheel

    Creative Director (retired)

  • Admin
  • 37174 posts

Posted 20 June 2018 - 09:47 AM

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.



#6 nbohr1more

nbohr1more

    Darkmod PR, Wordsmith

  • Development Role
  • PipPipPipPipPip
  • 8802 posts

Posted 20 June 2018 - 09:51 AM

Hmm new spider and lantern AAS types eh?

Make a tracker?
Please visit TDM's IndieDB site and help promote the mod:

http://www.indiedb.c...ds/the-dark-mod

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

#7 Destined

Destined

    Advanced Member

  • Member
  • PipPipPip
  • 1494 posts

Posted 20 June 2018 - 10:32 AM

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.



#8 Destined

Destined

    Advanced Member

  • Member
  • PipPipPip
  • 1494 posts

Posted 21 June 2018 - 01:14 AM

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.



#9 grayman

grayman

    Master Builder, Coder

  • Active Developer
  • PipPipPipPipPip
  • 12552 posts

Posted 21 June 2018 - 06:38 AM

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.



#10 Abusimplea

Abusimplea

    Member

  • Member
  • PipPip
  • 368 posts

Posted 21 June 2018 - 06:46 AM

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?



#11 grayman

grayman

    Master Builder, Coder

  • Active Developer
  • PipPipPipPipPip
  • 12552 posts

Posted 21 June 2018 - 06:48 AM

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.



#12 grayman

grayman

    Master Builder, Coder

  • Active Developer
  • PipPipPipPipPip
  • 12552 posts

Posted 21 June 2018 - 06:51 AM

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.



#13 grayman

grayman

    Master Builder, Coder

  • Active Developer
  • PipPipPipPipPip
  • 12552 posts

Posted 21 June 2018 - 06:52 AM

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?



#14 Springheel

Springheel

    Creative Director (retired)

  • Admin
  • 37174 posts

Posted 21 June 2018 - 08:52 AM

 

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



#15 nbohr1more

nbohr1more

    Darkmod PR, Wordsmith

  • Development Role
  • PipPipPipPipPip
  • 8802 posts

Posted 21 June 2018 - 09:03 AM

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.c...ds/the-dark-mod

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

#16 grayman

grayman

    Master Builder, Coder

  • Active Developer
  • PipPipPipPipPip
  • 12552 posts

Posted 21 June 2018 - 09:24 AM

But the old maps already work. Whats to fix?

#17 nbohr1more

nbohr1more

    Darkmod PR, Wordsmith

  • Development Role
  • PipPipPipPipPip
  • 8802 posts

Posted 21 June 2018 - 09:32 AM

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.c...ds/the-dark-mod

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

#18 Springheel

Springheel

    Creative Director (retired)

  • Admin
  • 37174 posts

Posted 21 June 2018 - 09:42 AM

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.

Attached Thumbnails

  • 333.jpg

  • nbohr1more likes this

#19 Destined

Destined

    Advanced Member

  • Member
  • PipPipPip
  • 1494 posts

Posted 21 June 2018 - 11:19 AM

 

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.



#20 grayman

grayman

    Master Builder, Coder

  • Active Developer
  • PipPipPipPipPip
  • 12552 posts

Posted 21 June 2018 - 07:33 PM

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.



#21 grayman

grayman

    Master Builder, Coder

  • Active Developer
  • PipPipPipPipPip
  • 12552 posts

Posted 21 June 2018 - 07:36 PM

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.



#22 grayman

grayman

    Master Builder, Coder

  • Active Developer
  • PipPipPipPipPip
  • 12552 posts

Posted 21 June 2018 - 07:41 PM

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?



#23 Springheel

Springheel

    Creative Director (retired)

  • Admin
  • 37174 posts

Posted 21 June 2018 - 07:58 PM

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?



#24 grayman

grayman

    Master Builder, Coder

  • Active Developer
  • PipPipPipPipPip
  • 12552 posts

Posted 21 June 2018 - 08:46 PM

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.



#25 Obsttorte

Obsttorte

    Scripting guru, Mapper

  • Active Developer
  • PipPipPipPipPip
  • 5581 posts

Posted 22 June 2018 - 01:20 AM

 

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
WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.
Mapping and Scripting: Apples and Peaches
Sculptris Models and Tutorials: Obsttortes Models
My wiki articles: Obstipedia
Let's Map TDM YouTube playlist: ObstlerTube
Texture Blending in DR: DR ASE Blend Exporter

End of shameless self promotion.



Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users