Sotha's mapping thread

[Fidcal]

grayman is probably the best person to answer this. I've never done a cinematic. I can't even guess what the problem is.

[Sotha]

In desperation I put a trigger_once between the script call entity.

So that worldspawn targets a trigger_once, which targets the script call.

 

Nothing happened: No cutscene, but no dead AI.

 

So I put the trigger_once to use delay 0.2.

 

Now I got the cutscene to run, but again some AI's just died.

 

The cutscene script looks like this:

void update_entrycamera()
{
sys.threadname("aim_entry_loop"); 
while (1)
{
	sys.trigger($entry_keyval); // keep Camera6 pointed at target_null_6
	sys.waitFrame(); 	// wait a frame before continuing
}
}


void entry_scene()
{
sys.println("entry_scene running..");
$entry_camera.activate($player1); 
thread update_entrycamera();
$entry_mover.time(9); 	// How many seconds it will take to move along the spline
$entry_mover.accelTime(0.1); 	// How long it takes to accelerate
$entry_mover.decelTime(0.1); 	// How long it takes to decelerate
$entry_mover.disableSplineAngles(); // Stabilizes the camera view as the camera follows the spline
$entry_mover.startSpline($entry_spline); // Start the func_mover $Mover5 moving along $Spline5
sys.waitFor($entry_mover); 	// Wait for $Mover5 to finish its movement
sys.killthread("aim_entry_loop");
$entry_camera.activate($player1); // Return control to the player

}

[Sotha]

I have several cutscenes in the mission, which work pretty much the same. But AI's do not die during those. Only during this opening cutscenes the mysterious deaths occur..

[Fidcal]

Just guessing but it takes many seconds from map start while moveables are allowed to settle and I don't know what else. Try it with a really long delay say 25 seconds. If that stops the deaths then reduce the time until they start dying again then increase it a little. You can always improvise a message to show or something if there is an obvious strange delay.

 

btw the trigger_once I think needs a spawnarg wait or wait_trigger or something or it just waits for a player contact.

[Sotha]

Just guessing but it takes many seconds from map start while moveables are allowed to settle and I don't know what else. Try it with a really long delay say 25 seconds. If that stops the deaths then reduce the time until they start dying again then increase it a little. You can always improvise a message to show or something if there is an obvious strange delay.

 

I'll try that, it may indeed be that it has something to do with the AI "relaxing" from their intial positions.

 

btw the trigger_once I think needs a spawnarg wait or wait_trigger or something or it just waits for a player contact.

 

I use notouch 1. That way trigger_once can only be triggered by targeting it. I've used this kind of things routinely in my map without any delay-spawnargs. It is odd that worldspawn targetted trigger_once needs a delay or it won't work...

 

What I can't comprehend is that why does this work on knightons, but not in my WIP.

[Sotha]

Phew! Managed to fix the issue. Now I got the starting anim to work without the any AI's being killed.

 

I found a common element in all dying AI: they were floating in the air, just a few units above ground. When I carefully snapped them on the ground, they did not die anymore.

 

Even when the AI's do not have the cinematic property, they probably somehow were 'falling' all the time during the intro anim. And when the anim was over: splat, million damage. When the AI's are touching the ground they are safe.

[ocn]

Thumbs up!

[Tels]

Phew! Managed to fix the issue. Now I got the starting anim to work without the any AI's being killed.

 

I found a common element in all dying AI: they were floating in the air, just a few units above ground. When I carefully snapped them on the ground, they did not die anymore.

 

Even when the AI's do not have the cinematic property, they probably somehow were 'falling' all the time during the intro anim. And when the anim was over: splat, million damage. When the AI's are touching the ground they are safe.

 

That sounds like an issue that should be tracked as a bug report.

[Sotha]

That sounds like an issue that should be tracked as a bug report.

 

Yeppers. Done. Over here: http://bugs.angua.at/view.php?id=2654

 

Remember, the bug can be avoided by simply placing the AI perfectly to the floor so while waiting the bug to be fixed the problem can be sidestepped by mapper enlightenment. But yeah, it might be really difficult to place accurately the AI on some uneven cave patch floor..

[Sotha]

Is it possible to prevent an individual AI from closing doors behind them? Or is it possible to have AI walking towards a certain path_corner to be set not to close doors after them? Ie. the path_corner had some kind of "dont_close_doors_when_getting_here" spawnarg. The AI should still open doors.

 

For example in knighton's manor: when the scepter is taken and the alarm sounds off, the sleeping guards in the guards quarters get up and rush to the scene. It is a bit silly when they are going to path_corners with "run 1" and they stop after every door and calmly close them behind them as they rush towards the alert.

 

More realistically they would just run to the alert and leave doors open behind them. No time to close them.

[Aprilsister]

Sotha, just read about ocn's vid-preview-promo-intro-somethingorother... And I'm trying a bit to stay out of these developing threads for the most part nowadays... but I wouldn't mind getting a new percentages breakdown from you on the mission in question.

 

Hopefully you'll say 100%, 100%, 100%, 98%, 100%, because the Contest is supposed to be underway (4 days so) now and, though you never seem to need the whole of the alloted time, it would be nice for you to have some time to do your Seasons Contest entry... and maybe even do as you've always said you wanted to do: the 2 entries thing this time?

 

 

But, seriously, do you have an estimate on the "completeness" of this latest mission?

[Fidcal]

I don't know of any AI alert door handing options.

 

Current options are at http://wiki.thedarkmod.com/index.php?title=Doors#AI_Door_management

 

In your case you might give the door ai_should_not_close 1 or create movers > atdm:door_handling_position entities and give them the spawnarg ai_no_close 1 so they only don't close it when passing through in one direction. But it's not ideal because they will always do it not just when alert. A complicated system you might set up would be an invisible option objective to test for alerts which calls a script or targets something to change the door properties (another metaproperty needed) or teleport in different doors. A second alert objective might restore the doors. But all very messy and fraught with problems like the blue room doors are closed and suddenly teleported in to replace an open door, or an AI is halfway through his animation when the door is whisked away to be replaced by another!

 

Looks like we need new code for AI door handling when alert. I think one solution would be if a general rule is set that when AI are they never do the animation but it skips all that and simply triggers the door to close after they are through as if to suggest they have pushed it behind them after rushing through. Or alternatively they just never close doors when alert.

[Sotha]

I don't know of any AI alert door handing options.

 

Current options are at http://modetwo.net/d...Door_management

 

In your case you might give the door ai_should_not_close 1 or create movers > atdm:door_handling_position entities and give them the spawnarg ai_no_close 1 so they only don't close it when passing through in one direction. But it's not ideal because they will always do it not just when alert. A complicated system you might set up would be an invisible option objective to test for alerts which calls a script or targets something to change the door properties (another metaproperty needed) or teleport in different doors. A second alert objective might restore the doors. But all very messy and fraught with problems like the blue room doors are closed and suddenly teleported in to replace an open door, or an AI is halfway through his animation when the door is whisked away to be replaced by another!

 

Looks like we need new code for AI door handling when alert. I think one solution would be if a general rule is set that when AI are they never do the animation but it skips all that and simply triggers the door to close after they are through as if to suggest they have pushed it behind them after rushing through. Or alternatively they just never close doors when alert.

 

Just to avoid confusion: it is not about the AI being alert. It is about having the possibility to have certain AI's not close the doors while idle. Or having AI's moving towards certain path-corners (ones with run 1, for example) and then they would not close doors on their way to the path_corner.

 

Also when thinking about zombies, it would feel intuitive they can bash and flail a door open, but surely they do not turn around and close the door like they do now... if we had a spawnarg "do_not_close_doors", we could have it on as default for zombies.

 

The door closing thing while AI's running (in idle) somewhere is not a critical thing, but more of a cosmetic one: one of those things that break immersion: a guard runs to an alarm, but after rushing through a corridor, he turns and closes the door behind him. Mappers will most likely use running (idle) guards for scripted events. But it is not so critical for the mapper to try making complex objectivework.

 

@april:

Soon or Very Soon. Or was it monSOON, can't remember now.

[Tels]

@Sotha: Yeah, having an exception for rats (do not close doors) feels silly, because we need the same exception for zombies, werebeasts, ravens, guards running etc etc. That setting should be:

 

* settable by the def files (e.g. and the mapper), so you can set it on entire AI classes (like the "poor beggar without arms" special AI, or the "ladies do not close doors, they have their servants for this"

* and auto-set to "1" under certain conditions (like in combat, when running, when swimming etc).

 

I do not know what the current code is, but you might PM this to grayman and ask him if and what bug to file.

[Fidcal]

Well, this should not need any code. It just needs the spawnarg I gave above adding to the zombie def so it applies to them all rather than putting it on individual ones. But it really needs the team to agree generally because it's not a bug but a design decision.

[Sotha]

Well, this should not need any code. It just needs the spawnarg I gave above adding to the zombie def so it applies to them all rather than putting it on individual ones. But it really needs the team to agree generally because it's not a bug but a design decision.

 

Grayman is going to make a test dll with some changes: running AI will not stop and close doors they pass and a spawnarg which can be used to control the probability of AI closing doors behind them.

[ungoliant]

would it be possible to hack out something in the meantime, to script an event when an ai operates a door like

 

if(target.isopen() && AIentity.AI_AlertLevel) //any alert level thats not 0

{

//do something to set door spawnarg ai_should_not_close = 1

sys.wait(2)

//do something to set door spawnarg ai_should_not_close = 0

}

 

I don't know if if its possible to access an AI entitys private variables that way, or if you can even manipulate spawnargs through a script (still learning scripting basics). just a thought.

Edited March 4, 2011 by ungoliant

[Sotha]

I was wondering what else to update in knightons and I thought that having the card players to patrol if the player alerted them would be a nice touch.

 

However, I am stumped how to do it. Any ideas? It would feel logical to have card playing AI's patrol if they are alerted.

 

I tried to use alert_idle_only and idle_only path_nodes like this:

AI is idle and goes to sit at the gaming table. path_sit targets two path_sits. The other is idle_only and other is alert_idle_only. The alert path corner would then send the AI to patrol. The idle path node would target another sit node to keep the AI at the table.

The problem is that the AI stands up after each path_sit's wait time has ended. Not good.

 

Because of this, path_sit targetting another path_sit cannot be used.

 

This means the only way to do it so it looks good would be giving the AI new targets when they are alerted. How can give AI's new targets when they are alerted? Can I somehow monitor individual AI alert levels? When this AI goes over this alert level, put all card gamers into patrol routes.

[Sotha]

This means the only way to do it so it looks good would be giving the AI new targets when they are alerted. How can give AI's new targets when they are alerted? Can I somehow monitor individual AI alert levels? When this AI goes over this alert level, put all card gamers into patrol routes.

 

Ha! Objective system for the win! Exactly what I want to do can be accomplished there.

[Springheel]

You don't need two different sitting paths. Just put idle_only on the sitting pathnode, and alert_only on the node you want them to go to when alert. After searching, the AI will go to the alert_only node, and shouldn't sit down at all.

 

Ha! Objective system for the win! Exactly what I want to do can be accomplished there.

 

How are you able to do it with the Objective system?

[Sotha]

You don't need two different sitting paths. Just put idle_only on the sitting pathnode, and alert_only on the node you want them to go to when alert. After searching, the AI will go to the alert_only node, and shouldn't sit down at all.

 

But basically I still need some kind of selector path_node. The one which targets the alert only and the idle only paths. Therefore there still would be the situation that the AI sits for a while, and then targets the path selector node (gets up and does something) and then targets the sitting node again if he is not alerted.

 

 

How are you able to do it with the Objective system?

 

This works beautifully. The AI are placed at the seats just like in the card player prefab. Each player have "sitting 1" so they sit down at map start. AI's have no targets.

 

Then I have one unseen objective per player:

Objective component is only "AI is alerted", with the single entity card playing AI name. I can set the minimum alert level required for the AI to react. I set that to 3, so if the AI search actively, he won't be playing cards anymore, but goes patrolling instead.

Basically the objective component says: "Alert entity cardgamer1 1 times to a minimum alert level of 3."

 

And when that gets satisfied, the objective has completion target gopatrol_start, which is an ordinary trigger_once. This in turn targets a func_static which gives all the cardgamers new targets to their patrol routes.

 

When I make one objective for each player, alerting any single one of them will make everyone of them to go for patrol. And once the trigger_once is gone, further alerting of the AI has no effect.

[Springheel]

But basically I still need some kind of selector path_node.

 

It should work if you have the AI target the alert_idle node directly. The AI will ignore it as long as they're not alert and follow their other pathnodes like they normally would. Once they are alerted and finished searching, they'll return to the closest pathnode that isn't set to idle_only.

 

Your objective method sounds interesting though, and more flexible too since you can set the specific alert level. I might have to use that myself.

[Sotha]

Hey!

 

I just spotted that the wiki animation list contains a cool new anim: idle_stir_pot.

 

I tried to put a path_anim in the map and gave it anim idle_stir_pot. The AI does no anim at all and does not resume patrol.

 

How can these new anims be employed? It says they are "flavour animations to be called by scripts or triggers." Why cannot they be set in ordinary patrol path_anims?

 

http://modetwo.net/d...=Animation_List

 

EDIT:

Also it seems female characters do not play cards? They do not have those anims yet?

 

EDIT2:

Also I tried to make an eating character. He picks up the food he is supposed to eat, but drops it on the floor instead of putting it back on the table. How can I get him to put in on the table?

[Springheel]

How can these new anims be employed? It says they are "flavour animations to be called by scripts or triggers." Why cannot they be set in ordinary patrol path_anims?

 

There's no reason they can't be. Was it a male or female character? It's possible the animation isn't working on females....yes, it's commented out because it hasn't been tested yet. I'll uncomment the rest of the untested ones for 1.05--better they can be used, even if they're not totally lined up for tables, etc.

 

Also I tried to make an eating character. He picks up the food he is supposed to eat, but drops it on the floor instead of putting it back on the table. How can I get him to put in on the table?

 

That's a test animation Tels used to test the spawn/destroy code. Those are placeholders that probably shouldn't be used--they're just cough animations that spawn food.

[Sotha]

There's no reason they can't be. Was it a male or female character? It's possible the animation isn't working on females....yes, it's commented out because it hasn't been tested yet. I'll uncomment the rest of the untested ones for 1.05--better they can be used, even if they're not totally lined up for tables, etc.

 

Yeah, I tried them for a female character.

 

 

 

That's a test animation Tels used to test the spawn/destroy code. Those are placeholders that probably shouldn't be used--they're just cough animations that spawn food.

 

Okay. I just found the AI prefab with the guards eating and drinking. I assumed they're fully working since someone has made a prefab available. BTW: the prefab WAS made incorrectly in a way the guards are standing in the table, rather than sit and turn towards the table. That prefab shouldn't be used as is and without manual fixing by anyone as the AI will get into trouble if they are alerted.

 

At any rate, the eating looks fine enough to be useable, but only if the AI would put the food back to the table instead of dropping it. Strangely, the drinking works just fine. The AI grabs the bottle from the table, drinks a bit and properly places the bottle back on the table. For food, he takes it, eats, and drops to the floor. I see a difference which may cause this: the bottle entity is somekind of special prop_bottle_sit_and_drink. The food is just an ordinary moveable. I suspect that if there was this mysterious eatable prop entity for food, it might work while a real eating anim is made.