Dragofer

Taking a closer look at your script line, the syntax is in fact off. It should be m_target_name.setKey(m_key, m_value). When you use a $ you tell the script to look for an entity in your map that's actually called m_target_name, but what you really want is to use m_target_name as a placeholder for whatever your init script found when it did getKey("target0"). That needs no $. Similarly for m_key and m_value, when you put those in quotations you're telling the script to literally set a spawnarg "m_key" with the value "m_value". But again, you want to use them as placeholder names so they should be input without any extra formating. $m_target_name.setKey("m_key", "m_value")

I'm encountering the same issue with sys.waitFor(self) in a scriptobject for a new func_mover: it doesn't wait at all. The only time sys.waitFor() will work is if I put it in a map script and manually enter a name: sys.waitFor($func_mover_1). Won't work with placeholder names, i.e. sys.waitFor(mover_name); Is something like the below broken for you even when it's in a map script? string spawnarg_name; string spawnarg_value; $door_1.setKey(spawnarg_name, spawnarg_value); If yes, then we may have encountered the same problem.

For the new spawnarg-controlled func_mover STRUNK and I are developing I'd like to make it trigger its targets upon reaching certain positions (position # = the # of motions away from the starting point) I've implemented this for a single position, but I'd like to allow the mapper to specify an indefinite number of positions via spawnargs. For this I think I'm missing, and would appreciate advice on: (1) something like numTargets and getTarget(#), but for my custom spawnarg series trigger_at_positionx instead of targetx (2) the correct way to form this conditional: if(current_position == any of the positions retrieved by (1)) For (1), it looks like numTargets and getTarget(#) are hardcoded, so I'm not sure how I can derive something that works for a custom spawnarg. For (2), all the C tutorials I found mention things like != and <=, but never something like if(number == 3, 4 or 7).

S/R is best for this, takes a total of 5s if you've done it before: Select the pouch -> go to top and click Entity -> Stim/Response -> Response tab -> add Response 'frob' -> right-click & 'add' effect in the box on the right -> change the new effect to run_script with your thread name. Plenty of other effects available too, and you can also make these happen in response to a 'Trigger' instead of a 'Frob'.

Alright, I can take a look at that tomorrow. Could you edit your post with a link to what you have so far please? Also, since this discussion has taken on a mostly two-way character I'd suggest switching to direct messages from now on. My hope was a public discussion would let coders weigh in on any roadblocks, but I think that's much more feasible if we keep most of our exchange in a PM and post the roadblocks as precise questions in this thread.

@STRUNK those are spawnargs, so they should go into the def file. Also, blue screen indicates you're working with the script from the /scripts folder? I found it much easier to develop it while it was in the map script.

I'm thinking if the player drops a crate in the way of the mover. The mover should stop and, when the crate is removed, be able to continue to its target position & angle. Either automatically or when re-triggered. Would be a good reason to check each frame how far the mover has gotten so it can resume from where it stopped. Or check i.e. every 10 frames. This would also work, because we have disabled its response to further triggers/frobs, so it can't move any further in those 10 frames.

This line can both enable and disable a response to trigger & frob: void ResponseEnable(float type, float state); state: 0 = disabled, 1 = enabled Type is the ID # seen in the S/R Editor Hmm, spawning a speaker might not be so good after all. If something stops the mover, how does the scriptobject know it's stopped so it can turn off the speaker? Could maybe check the location & angle every frame, but that may slow things down if there are many movers moving. Note to self: we also want trigger_at_start and trigger_at_end for all targeted entities. If it's not already existing, we can find suitable code in the candleholder scriptobjects.

@STRUNK Great, thanks for including all the remaining spawnargs already existing for func_movers in the entity def, that'll make it easier to use those, and for further developing the scriptobject. Haven't had as much time for actual TDM work today so it's nice to see progress still being made. Regarding the trigger response, there are script commands to deactivate and activate responses. Just need the ID # of 'trigger', which you can find in the S/R editor. I'd also switch from frob_action_script to S/R for frob and use the above method to deactivate/activate. (Initially I sought other solutions than S/R because all the 'official' entities seem to use other ways to trigger themselves. But for a community resource that works as it should it's certainly fine.) Don't really like the existing snd spawnargs. Snd_move starts playing at the start of acceleration, then restarts at the end of acceleration with a pop, then at the start of deceleration there's another pop and then silence. Also, if the soundshader for snd_accel or snd_decel loops by default, it'll continue looping after the mover has finished moving. And unfortunately scripted sounds for movers are broken. That's why I sought to workaround by spawning a speaker that can be controlled more accurately. I think for most scenarios just a single sound throughout the entire movement will be enough, for now.

@JackFarmer the circling suggests the AI is trying to get to a position but can't get close enough because something is in the way (monsterclip or the door). It might be the switch is too close to the door / the path_corner is too close to the switch or the door. I'd suggest spreading the switch & the path_corner out more. (An AI can't get closer than 16 units to a monsterclip wall, and doors/moveables seem to dynamically create monsterclip walls around themselves). Btw the correct way to use path_interact is to use "ent" spawnarg with the name of the entity to interact with.

Thanks again for sorting this out, I was wondering what was going on there. Btw, In Remembrance of Him by RPGista is well-known for the whole map being bathed in faint purple parallel moonlight. I don't recall seeing anything wrong when I played it, but you know what you're looking for.

Took a look at his actual script too now - just need to put that into his while loop like so and you're set: while(1) { if (distanceTo($player1)<1024) { vector direction=$Statue.getOrigin()-$player1.getOrigin(); direction_z=0; $Statue.setAngles(sys.VecToAngles(-direction)+'0 90 0'); } } sys.waitFrame(); Probably also bind a trigger_hurt brush to the particle and toggle it on whenever it starts flying. Please do post that to the Trap Workshop when it's finalised (f you're not first reserving it for your own FM). On my side, looks like the func_mover already supports movement sounds (snd_move, snd_accel, snd_decel etc.), but they don't really seem to work properly unfortunately and are bugtracker-worthy in several ways, i.e. don't play at their intended times, loop forever if the original shader has looping, popping sounds etc. Guess I'll just use my own way and spawnargs for getting sound to play.

@STRUNKnice, who'd have thought I'd get an entity named after me one day Good idea to make it a proper entity so that it displays all the custom spawnargs properly in DR. As you point out there are indeed still a few things that can make the new scriptobject fully versatile. Func_movers aren't really accessible to mappers who don't script, so it may be quite useful to have one that mappers can control by spawnargs instead of scripts. 1) the mover could spawn its own speaker (def_attach). A sound for it can be selected from a list provided by a new snd_move spawnarg. (Workaround for bug #5102) 2) maybe I can find a way to let the mover call its move_mover component when triggered or frobbed. Any button could set it in motion then. 3) the move_mover script shouldn't respond to new triggers until it's done. Unless the mapper wants it to be interruptable. 4) the trigger_count spawnarg can be used to make the mover's first inversion occur sooner (i.e. the mover has already moved a few times at map start) etc. Something of a stumbling block for me atm is I couldn't yet figure out how to access an entity's rotation. I'd like something like $mover.getRotation() so I know what direction it's facing currently (in x, y and z). Essential for an "interruption" functionality. Well probably mover_door has what I need.

Making speed equal to 1/distance would make it slower the further away the player is. The formula would rather be speed = distance/1, or just distance. It'll always take 1s to travel, so might as well just set a time of 1 for the mover. Anyway, float x = 1/y; or 1 / y; looks like correct syntax to me, but I don't think I've tried it before.

Nice - about your func_shooter script, you can use speed() instead of time() for a constant speed. Also no need for the lines accelTime & decelTime if you're setting them to 0. You can use sys.waitFor($BindToThis) instead of sys.wait() to let the script wait however long the projectile needs to reach the player. As for turning gargoyles towards players, something similar was done in Obsttorte's turning statues script, where the statues turn towards the player whenever he doesn't look at them. It looks like he uses mathematics (cos, sin, tan) to calculate the angle of the vector between statue & player.

There is a player model that you can see in mirrors, but I'm not sure if you can use getHead on it. How about getEyePos();? Also I've always used sys.println();, idk if sys.print(); works

Alright, I've figured out the scriptobjects now, scripting JackFarmer's desired setup as an example. Feel free to correct anything I write below of the way I understand their workings. It's a test map containing 3 cloned setups for a mover (gravestone + speaker + button). The gravestones have numerous custom spawnargs that get looked up by this scriptobject to control various aspects of their movement, i.e. invert 1 and invert_count 4 causes the mover to reverse direction after 4 movements. Both rotation and translation are supported. The scriptobject consists of 3 smaller scripts. First comes the main script (object reusable_script) where you define variables that should be available for all other scripts and what the names of the other scripts are. There must always be an "init" script, and I've also defined a "move_mover" script that does the actual movement. Note that all the variables start with an m_. This is optional and means "member": a member of this particular scriptobject and not available to any other scripts. The "init" script gets run at mapstart. The variables that were defined in the main script now get assigned values by looking up spawnargs on entities in your map. These variables can then be used in the "move_mover" script. The "move_mover" script is basically like a normal script that controls the mover, the button and the speaker. The difference to a normal script is that it uses variable names that are specific to entities associated with that particular mover. So you can simply select 1 mover setup in DR and duplicate it to get more. The only way I could find so far to call the scriptobject is: button -> atdm:target_callobjectfunction with spawnarg "call" "move_mover" -> gravestone mover with spawnarg "scriptobject" "reusable_script". You can have this scriptobject either in your map's .script file, or you can put it in its own .script file in your /script folder. You will need to include the name of that .script file in your tdm_custom_scripts.script file so that it gets loaded. Having it in the /script folder reduces clutter in your map's .script file and makes it available to all of your maps, but you have to restart TDM before changes take effect and you get a blue error window when there's a mistake in the script. (Maybe there's a reloadScripts function?) Click on copy and paste it to a text editor to read the full error message. The lines at the very top and bottom of the script file (#ifndef) ensure the script file can only be included once. scriptobject.pk4.txt

Ah, I must've merged my memory of getOrigin with moveToPos. Btw, I just remembered you can make scriptobjects if you want to use variable entities. That's how candle holders work, they call all their script functions on their associated entities. Scriptobjects are on a different level from plain scripting and go in a different folder. I haven't really gotten into them yet. There's a wiki article here, but it seems to assume some prior knowledge, i.e. it says you need definitions, constructors and members but not what they are.

@STRUNKnot that I know of, but what you can do is take the origin of the player and increase its z component. Should go like this. vector player_position = $player1.getPos(); player_position_z = player_position_z + 40; moveTo(player_position); Btw, I could suggest taking a look at river.script from my fm Down by the Riverside. It contains lots of the scripting I've done so far, with a fair amount of commenting.

No, as far as I'm aware that's an instruction for how to 'spawn' a new map and therefore can't be reloaded in a running map.

@STRUNK it's not quite done yet. Unfortunately at present there are only exceptional situations where you can provide a script called from ingame with additional parameters, that go in those brackets next to the name. The one example I'm aware of is trigger_touch brushes, which can tell its called scripts which entities are inside its volume. I've used that in the past for a teleportation script, switching it on and off for one frame. In this case my workaround would be to make a small script of each call, and update the call spawnarg on each call_scriptfunction entity when you duplicate each set. void move_script1(){thread reusable_script($mover1, $speaker1, $button1);} void move_script2(){thread reusable_script($mover2, $speaker2, $button2);}

@STRUNK I've never tried it, so I can only try to experiment from here. It is possible to make scripts reusable and give them information like numbers or entity names. With my present level of scripting I'd do something like this: void reusable_script(entity mover, entity speaker, entity button) { button.setFrobable(0); mover.moveTo('100 0 0', 2); sys.trigger(speaker); sys.waitFor(mover); button.setFrobable(1); } And call it like this: thread reusable_script($mover1, $speaker1, $button1); thread reusable_script($mover2, $speaker2, $button2); thread reusable_script($mover3, $speaker3, $button3); Not fully automated renumbering, but I guess it's easier to have all the variable parts within 1 bracket. Maybe a more knowledgeable scripter wants to step in? Note that you're using in-script names like "mover", "speaker" and "button". The engine doesn't need to look them up from your ingame entities, so they don't need a $ sign.

@JackFarmerthere's a wiki page referring to reloadDecls here (capitalisation doesn't seem to matter). Note that it'd be DECLS in all capitals, there's not an I there. Or you mean it doesn't reload particles?

@JackFarmergrayman describes a method for stopping rain particles out of rain patches from going through sealing brushes. He does this by making sure the rain patch is in a different visleaf from the one that he wants to stay dry. The particles are coming from a patch and not a func_emitter in grayman's case, but it's maybe worth a try. Otherwise it'd look like reducing the particle's lifespan would be the way to go. You can use reloaddecls in the console to reload particles ingame, or even make yourself a shortcut like: bind "p" reloadDecls. Pressing p would reload particles, entity defs, materials etc. @STRUNKnice to see that you aren't shying away from scripts, I think all the various subsystems of TDM (script, S/R, entities, objective editor) really potentiate each other to make a sum greater than its parts. Btw, you can alternatively use sys.trigger($Sound); for triggering entities, no need to name player1 all the time. The 3 commands you posted look like they're borked. No matter whether I put in a soundshader or a sound file name, it stays mute for me too. Maybe you'd like to create an account and post a bug report on bugs.thedarkmod.com?

Not really sure I can follow from the description how this specific task is elaborate. By the sounds of it you could speed up the task by selecting the switch, then additionally selecting one lamp after another and hitting ctrl - k to set them as targets. It'd cause plenty of clutter in your editor window, but I could suggest adding a new layer for 'disturbing things' so you can hide things like this switch with its huge web of lines.