Geep

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 doo

@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

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-a

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 o