ungoliant
-
Posts
1741 -
Joined
-
Last visited
-
Days Won
11
Posts posted by ungoliant
-
-
yea i heard that "interactive movies" were supposed to be a thing a long while back. where viewers can vote on a multiple choice question of what happens next during the feature. its all filmed before-hand, and then the viewers choice gets played out for the rest of the movie/tv show/etc. they should do that. let game designers design the games. hell if they did that with tvshows, i might watch reruns.
-
void setFrobable(float frobable) (you can call this on any entity)
for the button something like
void frob_function(entity ent) { frob_button(ent); ent.setFrobable(0); sys.waitFor(ent.getTarget(0)); // retrieves target0 (the door), and wait til it finishes its move ent.setFrobable(1); }yep that eliminates the whole state machine. pretty sure i can run the whole script right from this spawnarg on any button linked to any doors. since i want to trigger when door starts closing, i think i'll just fire the sound when button frobbed and door is open. on an uninterruptible door that can't be frobbed that only uses button that is unfrobbable during open/close animation, i think it works.
also, how did you know that frob_action_script passes an entity argument that passes itself? intuition? or did you look it up somehow? normally i'd use bloodgate to see this sort of thing, but I dont know where to go now. searching wiki for frob_action_script doesn't turn up anything useful on that subject.
-
4:08 got me pretty good too. "sometimes you'll have to improvise" *plays cut-scene action sequence*
-
1
-
-
can't believe i didn't see that.
well now i just need a way to disable new frob_action_script calls while door open/close anim plays, and possibly remove the frob highlight while door opens/closes. really wish bloodgate was up right now, and i'm sure it exists.
-
frobbing doors is not allowed! buttons only! (its an elevator)
I suspect the reason that i lost frob capability was because i changed that argument to a different script function. The defaults are different depending on the mover. Button default is frob_button. door default is frob_door. the button needs run frob_button or nothing happens, if you are on a door, it needs to run frob_door script event on itself too in order to open. so basically, if you change that spawnarg to anything else, you dont get the expected behavior.
i think frob_action_script is most likely meant to be left alone, and not sullied by dirty scripter hands.
or maybe not. I think entities with no expected default frob behavior could make efficient use of this. like a stone or something the player touches that updates an objective or something. but using it on a button or door where you want to keep the basic functionality and add a little more is kind of like reinventing the wheel because you have to manually add all that default frob behavior.
state_change_callback is likely a better option. but I've found with buttons that 1 frob = 2 state changes = 2 script calls. annoying.
-
i think frob_action_script might be a bit too much to handle. it looks like it replaces everything that the frob would normally do with the script function. so the button doesn't depress or undepress, doors dont open, button sound doesn't fire, targets aren't triggered. its a mess.
-
This sounds pretty messy for the purpose of simply opening a door
well the doors open fine without the script. its the sound thats the issue. The whole thing is a work-around to the lack of a 'play-when-mover-starts-closing' spawnarg. I could just wait until one pops up, but I think its been several years since the issue was first reported. Also, its great practice to start messing around with scripting again.
- a sound should be played (on entity A, which one is that?)
- and a variable should be changed to a value that is already represented by the command you are using to get its value (see below script).
entity A is just an arbitrary choice of one of the doors in a doubledoor. It is a target of the target_callscriptfunction entity with 'foreach 1' setup. I mean, I could target anything in the map and pass it to the function. Its fucking amazing. B and C are the activator of the target_callscriptfunction and the target_callscriptfunction entity itself, which i dont need here, but is pretty freakin awesome to have access to the activator entity, which in this case is the button, not the player.
I guess thats true about doorState, but at the time i was writing it, I wanted text output to keep track of stuff and when it was happening.
From how I understand it you could set the opening/closing sounds on entity A. Double-doors can be setup so that if one opens the other does, too. If entity A is the button, you can prevent the player from spamming it by setting the frob_action_script to a function that makes the button unfrobbalbe for an amount a bit longer then is needed for the door to open/close.
The closing sound in question is indeed on entity A on spawnarg snd_lockpick_pin_14. The double doors are already setup to open together, thats not an issue.
However, using frob_action_script in the way you describe could completely eliminate the need for a state machine at all, which would be fucking fantastic. I tried using it once, but all it did was prevent me from ever frobbing the button. probably because I did it wrong.
- a sound should be played (on entity A, which one is that?)
-
alright i guess the foreach 1 + call does work, i thought it was going to trigger the target, but I guess it doesn't. That was hella fun figuring out how to work all that garbage. Also unpredictable results if you don't start with target0, but printing getName() on all the args passed helps to figure out exactly what is going on. Also i had no idea that you don't put the arguments in the call spawnarg. its just 'call stateCheck' not 'call stateCheck(this, that, other)'.
Now on to the next problem, the state machine simply isn't going to accommodate multiple sets of doors without some kind of fancy footwork, unless i can come up with a better implementation, because its pulling states from random doors that might be opened/closed at any time, and i think a new state machine might be required for each set...
Here is a copy of the script if anyone wants to take a stab at it:
void stateCheck(entity A, entity B, entity C) //trigger with button only, fires every time button is pressed. //shouldn't matter if fired before/after stateChange() { sys.print("checking doorState value\n"); if(doorState && !k) { sys.print("door is open and sound has not fired yet\n"); //$elevator_cargo_floorb_door2.startSound( "snd_lockpick_pin_14", 0, 1 ); A.startSound( "snd_lockpick_pin_14", 0, 1 ); //sys.print(A.getName() + "\n"); //sys.print(B.getName() + "\n"); //sys.print(C.getName() + "\n"); k++; sys.print("sound fired\n---------------\n"); } else { sys.print("door is closed, or is open and sound has already fired\n------------------\n"); } } void stateChange() //trigger with door only, fires only on_close and when_opened //shouldn't matter if fired before/after stateCheck() { sys.print("changing door state to: "); if($elevator_cargo_floorb_door2.IsOpen()) { sys.print("open\n-------------------\n"); doorState = 1; k = 0; } else { sys.print("closed\n--------------------\n"); doorState = 0; } }basic rundown: doors are all set uninterruptable, k represents whether sound has been fired, doorState is if its fully open/closed when checked. sound should only be fired if k=0, once sound fires k set to 1. basically prevents sound from firing repeatedly if player spams the button while the door is in the process of closing.
-
waiting patiently... need my hols fix
-
that is a pretty long assed story. i'd rather get some education than achieve the specific result though.
alright i'll give you the rough of it. I want to access an entity dynamically rather than explicitly, to call a script event on it. i have many buttons and many doors. each button opens or closes a pair of doubledoors. each open or close action needs to run 2 different script functions that are part of a sortof state machine thing. a statecheck and a statechange. the statecheck is where i want to fire off a script event on one of the doors.
so right now the setup is thus: a button targets door1, door2, and a target_callscriptfunction entity that calls stateCheck every time the button is pressed. when door1 is activated by the button it also targets a separate target_callscriptfunction entity that calls stateChange.
So, I want to run script event on door 1. the script function that wants to do this is called by target_callscriptfunction that is activated by button that targets 3 things, 1 of which is door 1. So somehow i need to chain back and forth to get to door1 to call it dynamically. Like, activator.target(3).scripEventX()
I do not know how to do that. If i don't do that i need a pair of target_callscriptfunction's and a new function (that does the exact same thing) for each button+doorpair to call the different doors explicitly. I refuse to do that on general principle and would rather set my map on fire.
-
alright, that last one actually wasn't what i needed. I guess what I want to know now is how setting up my own user-defined parameters to pass in script functions works. Can I create my own and just pass whatever i want? what kind of restrictions are there on that sort of thing?
-
- Popular Post
- Popular Post
i double dog dares you to try to find a broadhead arrow with builtin HD killcam and a timewarp device that freezes time for less than 20g at any other outlet. its a steal i tell you.
-
5
-
i heard there will be mutiplayer in witcher 3. you collect sex cards and then play them against other online players like magic the gathering.
just kidding. thatd be hilarious though. can't wait for more sex with npcs... part 3.
Seriously though, this game is going to kick ass.
@ST, did you hear this from Anita Sarkeesian perchance?
-
...REALLY bad games like TDM...
repent, sinner
-
1
-
-
So, @ungoliant, how does this proposal fit what you need?
the functionality is all there, but theres gonna be a lot of hate from anti-feature-creepers when you introduce 8 new sound spawnargs dedicated solely to movers, and i couldn't blame them.
Honestly, i think you can get away with much less.
snd_open - when the door was completely closed, and starts to open, doesn't cut off at end of animation
snd_opened - when the door finishes opening, and has become completely open
snd_close - when the door finishes closing, and has become completely closed
snd_closing - when the door starts closing. doesn't cut off at end of animation.
snd_open_loop - loops continuously from start to finish of open animation then cuts off.
snd_close_loop - loops continuously from start to finish of close animation then cuts off.
snd_move - because you can't get rid of it.
this keeps the original 4 and adds 3. But only 6 are necessary. I cannot think of any circumstance that is not covered by these spawnargs.
snd_open_loop and snd_close_loop serve dual purposes. they can loop short sounds until animation ends, and cutoff very long ones.
i think everything is covered.
edit: i didn't notice the part about interruptions. I think its pretty difficult to find a use for soundshaders for interruptions, its kind of based on the surface type of the interruptor most of the time. Might be better to just cut off the sound on the existing spawnargs if interrupted, if possible.
-
an extra boolean spawnarg like snd_cutoff that affects move-close would be very helpful. move-open is not necessary because thats what snd_open does. thats why i'm saying snd_move is currently redundant because it adds the snd_open functionality in where it is not needed or wanted.
-
I noticed this in The Gatehouse. The instant you click to open a door the sound of creaking as the door moves starts and then stops once the door is fully open.
When you click again to close the door it is completely silent until the moment the door closes which then plays a creaking noise and then the shutting sound and all that while the door is now closed and not moving.
I agree, it is odd.
nah, that is the opposite problem. must have used snd_open + snd_close when the solution to that issue would be to only use snd_move with that one particular creaky sound. unless its 2 seperate obvious open/close sounds, and then it becomes an issue like i'm having, and they just used snd_close for some reason accidently.
-
The most common use for this is sliding doors, where you do want them to play both while opening and closing.
Don't snd_move and snd_close both play? So the door can play a sound while moving, and the snd_close takes over when the door closes fully? Or does snd_move override snd_close? I've been experimenting with this a bit myself but I'm not really sure.
my door does slide open and shut. but i its a metal sliding clangy gate thing, and the sounds it makes when opening vs closing should sound very different. also i have 3 custom closing sounds i made that all have the *clang* sound in the closing sound, and i really dont feel like re-editing them out just to add in a snd_close argument. also, there is still cutoff issues or gaps in the sound issues with doorclose to the clang sound transition that way if you don't time the transition and the door speed flawlessly. its a huge pain.
It cannot override the sound because snd_move literally shuts itself off right when snd_close begins. snd_close begins once the animation is over, and that is where snd_move ends.
-
scripting issue.
the "call" spawnarg in a target_callscriptfunction entity states this:
The name of the global script function to call. If 'foreach' is 0(default), then it will be called with no arguments. Otherwise, the function will be called for each target entity of this entity, with the arguments like Function(target, activator, this);I would like to use a target with my target_callscriptfunction, and be able to pass that target in the script that is being called by reference, but even with the tooltip, i cannot figure out how to do it. Can somebody give me an example of script syntax that will make this work?
Something like
myFunction(valuetype myTargetEntity) { dostuffwith myTargetEntity; }i dunno... i'm a bit lost.
I don't know the value type of 'target', 'activator', or 'this', and i don't really want 'activator' or 'this'. Dont know how to assign the target i want to a parameter in the script function with a pass by reference.
-
OK so here is the problem with this spawnarg: the functionality works exactly as stated in the DR description.
"Points to the sound shader to play while opening or closing".
We already have snd_open. This plays a sound while the door is opening. So snd_move doing this is completely redundant.
Other than snd_move, we have no spawnarg to play a sound as a door starts to close, only when it snaps to the shut state(snd_close).
So, if you want a sound to play while the door is closing, you must currently suffer through the same sound playing as the door opens, which you probably want to be a different sound. Like if the sound creaks from fast to slow, and then clicks shut. Doesn't really work too good while a door is opening. So I would like to see snd_move only function when the door starts to close.
The other problem is that once the open/close animation completes, the sound is immediately cut short, instead of playing the whole duration of the sound. I feel this should be optional, because otherwise it dictates the door swing speed the player needs to use unless they wish to manually edit the sound itself. Like, if the door closing sound includes a snap-shut sound, you would want to play the entire duration of the sound instead of cutting short.
Currently I have a door whose swing speed set to where the close animation ends right on the snap sound, but it gets cut short during the snap sound directly to silence, and it sounds absolutely god awful.
So basically, requests are: pls change snd_close to only function while closing, and stop it (or create option to stop it) from cutting the sound short when the closing animation completes.
-
I think the simplest and easiest way to support a patch cutting utility, cmd prompt or gui or otherwise, would be to just add a visual cue to the patch inspector that selects vertices of a whole column, row, or just a single vertex based on row+col. Would make it about 10000x easier to determine the lines you want to cut at if you've already messed around with the patch a lot. I look forward to the day i can split an inverted endcap in half easily just by checking the the visual layout of rows/cols before plugging in the row or col i want to be the seam into a patch split tool like this. so many possibilities.
edit: or, additionally, add a toggle option that puts a visual display of the RC pair like example: (2,3) next to each vertex. Or if multiple vertices share the same space, put an ordered list like {(0,0), (1,2), (2,3)} or something that shows all verts in that space. And holy crap, if you could mouse over the rc pair and select a single vert you want just by clicking on that rc pair... man. would change how we work with patches dramatically forever.
-
ooo, my first DR tutorial vid made it to moddb TDM page, yayyyyy. Also nice to see that TDM headline on front page again, awesome stuff. Stand forth and be recognized!
-
saw some of the new stuff posted up at eidos forums. looks like broadheads and sawtooths can be perma-upgraded into moss-broadheads and moss-sawtooths that make no sound on impact. that upgrade should really require a game clear to unlock.
-
Whoops I was wrong about something. I was looking at the wrong fencing during my last tests that were using vanilla textures, not the custom.
scale with a real image file works as intended. I can modify the values and it behaves as expected. Still doesn't look all that good though. using rgb with image file does not work at all.
I think it actually looks better to leave out the spec stage entirely and let the default values in interaction.vfp when it finds no specmap take over. Well, spread the word, using _white doesn't really work, and it sucks even if you use an image file and scale down the colors. just leave out the spec stage entirely if you don't have a spec map and don't feel like making one. thats my conclusion, but you guys can test it out for yourselves and see which way you think looks better.
I guess one thing we can take away from this is that if you want to ramp up or tone down your specmap, use scale and not rgb. There, something practical came out of this
Ungoliant's mapping questions
in TDM Editors Guild
Posted
i assume that doom_events.script and tdm_events.script have been merged since 2.0. It looks like the new tdm_events.script is completely alphabetical instead of sorted by entity class. this is... bothersome.