Leaderboard

I wouldn't want a timer running from the start of the mission. The nearest I can recall from the original games is the mission where you had to tail those two assassins; that's effectively on a timer because if you fall too far back you lose. But you get visual feedback on how you're doing, so it's not as annoying as an invisible clock ticking somewhere. Timed portions in missions can be effective, like in Undercover where you have only a few minutes to hit all the hidden levers. But that is only part of the mission; you can take your time to scout the place out beforehand and carefully plan your heist if you want to. Given that patient exploration is one of the reasons people play stealth games, I wouldn't want to force people to rush around.

It's not a question of overwriting. When the map loads, the #include lines are replaced with the contents of the specified .script files so that you get one giant merged script file in tdm_main.script. tdm_main.script includes tdm_custom_scripts.script, then tdm_user_addons.script, so the contained scripts will be added in that order. If you #include the same .script file multiple times from different files, like in your example, you risk getting multiple copies of the same script which causes map loading to fail - see one-definition rule. Inclusion guards (#ifndef, #endif etc.) stop more than one copy of the same script from being added. If you want your version of the script to take priority, you should give it the same file name and folder location as the base script, without using tdm_user_addons.script. It works the same as, for example, letting a custom model take priority over a base model.

@DragoferRegarding the bugtracker: It appears that the reason for the issue might be a typo. if ( alert < ( owner->thresh_4 + 0.1f ) ) // it should be > { alert = owner->thresh_4 + 0.1f; } I guess this code is intented to be used as a cap. In addition, the part of the description stating that the ai goes into agitated searching if absence_alert isn't specified is not implemented. Maybe the above code was also intented to do that but got changed afterwards?! Regarding your comment on the misinterpretation of the absence_alert spawnarg. The wiki explicitly states what it is intented to do and DarkRadiant explicitly states it to be a float, not a boolean. So either the fm authors who set that to 1 only wanted minor reactions which may accumulate, something we would break that if we use a new spawnarg instead, or they all suffer from dyslexie, which we hardly solve by introducing a new spawnarg. I would fix that so it does what it is intented to do but leave the spawnarg alone. If other members share your point of view that a new spawnarg should be introduced it can be easely changed afterwards. Additionally we may consider modifying the description, as "If set, the alert increase of the AI when the entity is missing" sounds odd to begin with and may be the root for misinterpretation. I would suggest "Set the amount, by which the alert level of an AI increases, if it sees this entity missing." EDIT: I've provided a fix with revision 9953 which can be tested in SVN. Feedback is welcome.

I have removed the pm_* cvars from the player def as of rev 16483

Hah ha! Yes! tdm_player_thief.def // movement settings "pm_bobroll" "0.0015" //side to side roll "pm_bobpitch" "0.001" //forward roll "pm_bobup" "0.03" //upward bounce "pm_runroll" "0.003" //running side roll "pm_runpitch" "0.001" //run forward pitch "pm_runbob" "0.35" //speed of run bob "pm_walkbob" "0.3" //speed of walk bob "pm_crouchbob" "0.2" //speed of crouch bob We should remove these from the def and ensure that the cvar values associated to them are archived so that they persist. Then players will finally be able to force these off.