Sotha

You always need one unsatisfied mandatory objective visible to keep the mission running. You could add an objective like "do not die" or "escape after you are done" or similar. If you think that looks bad, you could control the objectives this way: show the new mandatory objective, wait a moment (0.1-1 second), complete old objective. The delay is ultra-important! If you add the new objective in the same frame as the old is completed, the mission will end! This way you always have an incomplete objective visible. The setup is easy to do if the objective is controlled by entities or a script. If the objective completion is caught by the objectives system (kill AI, close readable, etc) you need to have an invisible proxy objective that catches the completion and fires a script. The script would add a new objective, wait a moment and close the old one. The actual objective the player sees is in fact controlled by a script. I am not aware of any other way. It is more work, but doable.

Yep, why use location for it? Just use a trigger_once to complete a custom objective and be done with it.

I checked it. For those wondering, func_emitter uses "start_off" to control if the emitter is on or off at map start. "entityname" is for trigger_entityname "ent" is for path_interact

There are many generic spawnargs, but if you examine it carefully, you will find the relevant ones among the clutter. For example, trigger_once_entityname needs a spawnarg for the entity who triggers it. The only way to know it is "entityname" is through that list. Or was it "ent"? Sometimes finding the relevant spawnargs are a PITA if you are not familiar with the entity. Anyways: I do not know other ways to find what spawnargs the entity can take. Check the list for func_emitter to see if it is "start_on" or "start_off" or "hide" or something else. When you get acquainted with the clutter spawnargs, you start seeing the relevant ones more quickly.

Choose entity. Press N. Entity inspector appears. There is a list of entity spawnargs. Right click on the white area. Choose add new spawnarg. You get a list from which you can choose.

Or was it "start_off 1" ? You can usually see what is available by right clicking entity inspector spawnarg list and choose add spawnarg. Or check if the spawnarg lists in the inherited spawnargs. These do not necessarily show all spawnargs, though.

So I think, you need to have on the location where you have the particle effect "call_on_entry" "toggle_particle" and "call_on_exit" "toggle_particle" Now, if the player starts in the area where the particle is, you need to have it ON when the map starts. If otherwise the particle needs to be initially OFF. The script looks like this: void toggle_particle(entity old_zone) { sys.println("toggling particles!"); sys.trigger( $entity_name_of_particle ); } If you need more things to trigger, keep adding lines sys.trigger( $entity_name_of_thing1); sys.trigger( $entity_name_of_thing2); etc No need to rename (entity old_zone). I think you do not even need it, because no parts of you script need to know anything about the "old_zone." Having the call_on_exit and call_on_enter will have the particles triggered each time the player moves in or out the zone. That is: *if the player starts in the zone and the particle is ON, the particle goes OFF when the player leaves and goes ON when the player comes back. *if the player starts outside the zone and the particle is OFF, the particle goes ON when the player arrives and goes OFF when the player leaves.

Yeah, Transaction disabled the global thunder with location setting entry and exit targets. You could check the derelict house to see how it was put together.

You could have a trigger that turns off the particle when the player leaves the area where the particle is. I had to do this in Transaction. IIRC, I used location system to disable rain particles when the player went into the derelict house, otherwise there would have been rain in the basement where the player was supposed to sleep.

The current setup was a deliberate choice. It would have increased the mission difficulty drastically if the guards would kill the fleeing prisoners. In effect, the player would have been required to kill/ko everybody, which is boring.

I sometimes still play the original. http://www.dxx-rebirth.com/

Glad you liked it!

Completed this. Boohoo, I was sort of expecting more. Thanks for the mission, though. I appreciated the experience, even though it was not my cup of tea.

Glad you liked it. The masks are already part of the core mod.

*Reels thinking about the man hours required to build 100 missions.* *Faints thinking about the man hours to make the framework required for all those missions possible* We are an unstoppable workforce of epic proportions!

Completed it now. Comments: Thank for the nice mission!

Played this just now. Comments: But still, it was a good 20min of sneaking fun. Thanks for the mission, Goldwell!

Played this just now. Thank for the mission!

Cool! Until what day do we now have time to play the entries and vote?

Confirmed! 0-50% is done with 1 unit of energy. 50-90% with 2 units of energy. 90-100% is done with 2 units of energy PER PERCENTAGE UNIT!

Awesome! Please let it be so!

Huh? I've not set the AI to have any custom paths if they are alerted. They should relax and resume normal patrols after The Incident It is not a feature of this map. Perhaps a quirk in the AI behavior?

It is fine for me. It is correct to declare a time period for the voters and then conclude the contest when the Iron is still hot. Nbohr could even make a moddb circus out of it to gain PR for TDM?

Most atmospheric! Can't wait to hear the soundscape of that scene.