Geep

I'm setting up a "do not kill civilians" objective, which is a bit hard to test quickly, so let me ask here if I'm doing it right. It's always kinda unclear what should be entered in the component subfields. In particular, should the "Kill target" be "Any AI of specified type" "is_civilian"? With Amount = 0? Here's all the details: Initial State INCOMPLETE Flags: Mandatory - TRUE (for the moment) Ongoing - TRUE Irreversible - FALSE Visible - FALSE (later TRUE) Component #1 ============ Component Type: Type AI is killed Flags: Satisfied at start - TRUE Irreversible - FALSE Boolean NOT - TRUE Player responsible - TRUE Kill target: Any AI of specified type : is_civilian Amount: 0

Good to hear about setKey. Since I have a working system, I'll just stick with that. I likely couldn't just drop "setKey" into my current script code, because that code is triggered by the door opening, so would probably be too late to change the door limits. I'd likely have to set up another trigger zone in front of the door to see if rotate changes stick. As for a notPushable moveable, I wonder, if you shoot an arrow at it, does the arrow pass right through it? Because that's what the door does. I'm not saying that's wrong, just for me unexpected (and perhaps undocumented).

Solved! I didn't need to copy/paste, your suggestion was enough. I arranged a moveable plank on the floor that is hit by the opening door. The other end of the plank is against an immovable knob of worldspawn... required! Regarding the earlier attempts, it remains surprising to me that setting "notPushable 1" on a moveable doesn't make it act like worldspawn to the physics engine.

Didn't seem like the player grabbing the movable first made any difference. I tried wrapping the hammer in a forcefield and giving it a nudge with that too, to activate physics. No luck. I guess I could use an AI as door stop, that might work... but will introduce other problems.

Here's my problem du jour... I've got a door that, depending on conditions I evaluate in a script, either opens fully or just cracked. If I needed to do just one of those two, I'd just set the "rotate" value appropriately. But I don't think there's a way to set "rotate" from script. (The setSpawnArg function would only work before you spawn the door, not afterwards. It would get messy to spawn the door dynamically just-in-time.) So I tried creating a named "door stop" object, which I can easily remove via script when I need to. The problem now is that the door travels through the door stop as if it's not there. This is true with both a func_static door stop, and a stock moveable (the builder stone hammer) with "notpushable 1" set. Anything else to try?

@mmij, here's a thought. If you've set your speaker up to play a non-looped sound when triggered, you have to remember to add the spawnarg "s_waitfortrigger 1". Otherwise, the sound plays on world start, and you're probably not positioned to hear it. Unfortunately, s_waitfortrigger is not listed among the default spawnargs in the Entity Inspector, so it's easy to overlook.

OK, so a lot of questions. I won't change the wiki. In the FM, I re-implemented using "within radius" objectives, all working well. Unlike info_tdm_objective_location, which I bug-reported as apparently broken last year.

I've had a small trigger_once that fires a script function OK when the player walks into it, but now I'm trying to make it both persistent and auto-reset when the player is outside it, so it can be used again. I know this can't be done with trigger_once, which gets removed from the game once triggered. But I was surprised that trigger_multiple didn't do it either, even with wait time of either "-1" or "32000" specified. So I'm moving on to try info_tdm_objective_location for this. But I'd like to change the Triggers wiki to be more helpful. Would the following be the correct understanding? Instead of: trigger_multiple Similar to trigger_once but will activate again and again, use "Wait" spawnarg to control how many seconds between triggerings. ...replace with... trigger_multiple Similar to trigger_once but will trigger repeatedly as long as the entity that triggered it remains within its volume, after which the trigger_multiple is removed from the map. The "wait" spawnarg controls the seconds between triggerings. A wait of "-1" makes it equivalent to trigger_once.

Oh, I thought touch = frobbed when I read the Signals article. BTW, @Dragofer, I just became aware of the AI spawnargs death_script and ko_script (or is it knockout_script?). Probably need to include that in A-Z too.

@Obsttorte, I'm sure that "get" functions are more easily implemented than callbacks, so if I was proposing a specific API expansion, that would be the place to start. @Dragofer, thinking further about the Signal system as currently defined, I'm not sure what it brings to the table. Is there any thing you can do with it that you can't do more gracefully by using entity spawnargs like "frob_action_script"?

Also, I could imagine extending signals to callbacks for sound shaders completing, animations ending, etc. If there's not already a way to do that.

Ha, I guess it does, now that I reviewed the "Signals" wiki page. Except the discussion above was more about values that were known to the engine, like LightGem value, and not entities defined in scripting, which Signals deals with. Also, the wiki article seemed to hint at some doubts as to how thoroughly signaling was implemented. I hope your Scripting A - Z efforts might cover Signals and so raise awareness about them.

@Obsttorte, sounds fair enough. I agree that hook functions would be a new feature for TDM. What would be gained is that the per-frame checking is done in C++, so real fast, rather than in an endless Doomscript loop thread. And would only call the slower script upon a change. Just floating it out there as a thought.

Assuming that Obsttorte is talking about the C++ side of script function implementation, not Doomscript... Please recall how much time (measured in years) and effort it takes to come to a complex C++ system like a game engine and gain "understanding how the whole setup works". That includes not just the code, but the whole process of gaining access to it and developing and propagating a change to it. So asking if someone who already has achieved that mastery could add a function seems collaborative and not unreasonable. By putting in a formal request, including any attempts at work-arounds, the need is documented, even if it won't be fulfilled in a timely way because of the press of requests. More importantly, if gives other FM authors the chance to comment and say "I could use this too"... thus showing community interest and making it more appealing for a C++ coder to take it on in the near term. Regarding the slowness of scripting, which HMart reiterated... Yes, so my abstract design about getting the lightgem value is not really best from a performance standpoint. What would be better is a design where the scripter asks to be notified whenever a value changes, e.g., sys.RegisterHookFunctionFloat(LIGHTGEM, myHookFunction, CALL_ON_CHANGE); where the third parameter is UNREGISTER = 0, CALL_ON_CHANGE = 1, CALL_EVERY_REFRESH = 2) void myHookFunction(float changedValue) { } There would be something similar for vectors. In the most evolved version of this, the registration process would involve a linked list, so that multiple hook functions could monitor any given value. Does this design make sense for MirceaKitsune's actual updating of a custom GUI? I have no idea.

Following up on HMart, because there is no longer an FM-specific dll to modify in C++, I'm thinking that it is far less likely that FM authors will seek to change the C++ code. So doing increasingly more of the mod stuff via scripting becomes important. It is a challenge to design this in a way that minimizes slowdowns inherent to scripting.

I think we FM mappers need to be less shy in requesting new script API functions (e.g., as New Features in the bugtracker) where existing methods are inadequate, overly convoluted, or non-existent. The case for a new API offering is strengthened to the degree that it's clear it will be generally beneficial across FMs. The bar for this should be particularly low for "...get..." functions. So, in MirceaKitsune's case, I gather something like this is wanted: float gem = sys.GetLightGemValue(); // as just calculated this frame by engine sys.SetLightGemValue(MY_HUD_GUI, gem); // pass it on to my custom HUD The first of these should be easy to justify. The second would take more persuasion.

Regarding the sound file, I'd like to know that too. It is possible to create a video that either precedes or takes the place of the text briefing. While I suppose the visuals in such a vid could be just a static shot of the text, the user interaction would be different and so probably just confusing. And, for me at least, creating a video is a heavier lift than an audio file. There is a hook in a gui file to add your own audio file during the mission end screen, but I'm not aware of one for the briefing screen. You could probably override the audio file used for the briefing screen (suggestive of deep wind chimes) with your own with the same name. But that track is used not just for the briefing, but also for the objectives, the shop, etc... So overriding it probably won't give you what you want.

Good catch! Fixed

And for the holiday season, more Stolen Heart WIP pics, this time of the music hall, where a priest coaches an acolyte in song. When the game is released, you'll find it's a Latin chant, a Builder version of a 13th century plainsong by Thomas Aquinas. Thanks be to @AndrosTheOxen, who voices both roles including the singing!

Clearly people differ in what they want out of a wiki tutorial, and where they are on the quick-read versus more-depth spectrum. I generally prefer a bit of depth. Coming to TDM with OOP experience already, I'm interested more about TDM-specifics; so with Dragofer in that regard. As a for-instance, the recent discussion in the Newbie Forum that you can declare an object of type "ai"; didn't know that before.

@Dragofer, just saw your new multipart "A to Z Scripting" wiki piece. Much appreciated!

Update on (2), probably SOLVED. The problem was that the .ogg song files (unlike the spoken files) were in stereo. Once I converted 1 of them to mono, the lip sync with that audio was good again.

1) 5 second delays did not stop glitches. 2) Adding the snd_... to the AIs did not solve the out-of-sync problems. (Subjectively, it is possible it made it somewhat better at the margins.) This result makes it more likely that the singing will have to be broken up into short phrases. Not a good outcome.

1) Later today I'll try some experiments along the lines you suggest. But even if that's the case, I can't put in a 5 second delay; conv1 and 2 are all part of an overall conversation flow that would be too halting with delays like that. The glitching would be the lessor of 2 evils. 2) Let me see if I understand what you're saying. In my atdm_conversation_info_1, that holds all the conv, I should have snd_1, snd_2, etc. with the names of the sound shaders? Or should they be on the AIs that speak them?

@Dragofer, the good news is that this works (abstract syntax here): conversation1.ActivateTarget(target_callscriptfunction with "call done_1") --> void done_1() {sys.wait(0.1); sys.trigger($target_startconversation_2 with "conversation conversation2") --> start of conversation 2 The wait(0.1) is required, or else the audio in conversation 2 doesn't play. OK, the bad news... 1) When a new conversation is triggered, the AI idle animations glitch/jump. Haven't found a way to prevent this. (I'm only using the AIs' idle animations, not specifying anims in the conversations themselves). 2) With a longer ogg file in the conversation (e.g., singing for 20 seconds), lip sync gets a significant offset, e.g., the lips move 1 second later than the sound). A hypothesis is that precaching/preloading the sound would fix this. Anyone have a recommendation for the best way to do this with a conversation sound shader (which in some cases may have multiple ogg files)?