Dungeon patrols

[alois]

Hi to all.

As the title says, I've created a little framework which allows to create monster patrols inside the dungeon; i.e., monster going back and forth (or only forth...) between a sequence of points in the dungeon. Every monster is aware of its surroundings (i.e., if it 'spots' the party, it reverts to a 'non-patrol' state = attacks the party...), reacts if attacked, and can 'call for help'.

First and foremost:
Thanks to mahric for his NPC script (here) which I modified: without it, nothing would have been possible
Thanks to JKos for his LOGFramework (whose installation process I blatantly copied)
Thanks to Xanathar for the Animation Toolkit (and for pointing me in the right direction!)

What it does:
- calculates a path between two points in a dungeon (there *must* be a path between them!), taking into account closed doors, obstacles, etc
- joins the paths found in a complex path which can be closed, or repeated in reverse order (or terminated!)
- creates a 'patrol': a monster walking such a path, endlessly (or not), well aware of the surrounding, ready to react to the presence/attacks of the party
- patrols can be grouped (if one is attacked, all the others of its group may react)

What it does not do
- the patrols are not aware of each other and/or of other monsters: even if the may spot the party, they cannot spot others; therefore, intersecting paths are discouraged!
- if a door is opened, the patrol - once started - cannot change its course (unless, of course, you tell so, by creating another one): it will still continue on its path, however long(er) [a further version can have the patrol change course, however]
- worst: if a door is closed, the patrol (once started) passes through it...
- every patrol has a 'sight' parameter; if the party arrives at less than 'sight' from the patrol, it has been spotted; to avoid ugly collisions (such as the monster walking through the party...) it is better to keep the 'sight' parameter greater than the square root of 2.
- therefore, 'blind' patrols (sight < 1) should be 'separated' from the party (say, with gratings)

Well, that's it; you can download everything here.

Feel free to comment, and make suggestions! (insults are allowed, too )

alois

[Neikun]

Bravo! This should be an excellent modding resource. Consider throwing it on the Nexus as well.

[mahric]

Really gotta try this soon. This has everything that I wanted to build into my script yet

But RL calls, can't tell my wife that we don't celebrate her birthday today..

[Komag]

Wow, this is very impressive stuff

[mahric]

The source looks way better than the script I made.
I can make stuff work in scripting, but making it look good/reusable is another thing...


But I noticed something that I had trouble with too. Once in a while you see the animation reset before the next animation is spawned. Think this will worse at slower computers too.

In my script I tried to solve that with custom animations that streched the last frame a bit, but that requires custom animations for every model and that's relatively expensive (in MB).
I tried to shorten the animations a bit, but the quick animations (like the scavanger's) look choppy then. So I couldn't think of anything else to do.

If we had a brilliant mind that could solve that problem, this would be perfect!

[alois]

The source looks way better than the script I made.
I can make stuff work in scripting, but making it look good/reusable is another thing...

Thanks! [however, quoting Newton: "If I have seen further it is by standing on the shoulders of giants." ]

But I noticed something that I had trouble with too. Once in a while you see the animation reset before the next animation is spawned. Think this will worse at slower computers too.

In my script I tried to solve that with custom animations that streched the last frame a bit, but that requires custom animations for every model and that's relatively expensive (in MB).
I tried to shorten the animations a bit, but the quick animations (like the scavanger's) look choppy then. So I couldn't think of anything else to do.

If we had a brilliant mind that could solve that problem, this would be perfect!

Yes, I noticed it too: if you decrease the quality of textures/particles etc, the monsters almost flicker... I too do not have any idea as how to solve such an issue (moreover, I do not know how to stretch frames in animations!).

alois

[mahric]

I did this with the GrimRock Animation Editor:
* Open the animation in the GRAE tool
* Select the last frame of the animation (of a line with bold text containing the name of the animation you want to 'stretch')
* put 3 in the box after "repeat in copies" and press the button
* press "save animations"

This seemed to solve the jittering, but it does require a new left, right and forward animation for each monster.
Could be and extra 2-5mb in filesize is my guesstimate. Still worth it though.

[SpiderFighter]

I did this with the GrimRock Animation Editor:
* Open the animation in the GRAE tool
* Select the last frame of the animation (of a line with bold text containing the name of the animation you want to 'stretch')
* put 3 in the box after "repeat in copies" and press the button
* press "save animations"

This seemed to solve the jittering, but it does require a new left, right and forward animation for each monster.
Could be and extra 2-5mb in filesize is my guesstimate. Still worth it though.

I did it with touchplates and blockers: http://www.youtube.com/watch?v=BIzlxSDpslI. Great minds, we all have!!

Seriously, terrific work on this, Alois!

[Xanathar]

Nice work! (and thanks for the credits! )

[Grimfan]

Great work Alois!

Hopefully AH will incorporate something like this in LoG2 (unless it goes against their monster philosophy of course). This would also be very helpful to the LotNR people I'd imagine (such as making NPCs move along set paths through a town or village).