LucasForums (
-   JA Mapping (
-   -   Scripting: Relative movements (

{NJO}*Dark 01-22-2006 01:39 PM

Scripting: Relative movements
I want to make an elevator that covers several floors. The gaps between these floors are the same distance, so i would like to know if its possible to make a Func_static to move the same distance in the same direction each time the script is used.
For example, if the list starts at 0 and the script tells it to move 256 vertically upwards, the first time it goes to 256. then the the second time the same script is used the lift goes from 256 to 512. etc.
Its been a while since i did some scripting and i was wondering if this was possible, since it would only need 2 scripts (one up and one down) needed, rather than a new script for each elevator and going from each place.

lassev 01-22-2006 03:03 PM

As far as I know, the only method that uses relative movement is roff.

What you are trying to do could either be done with multiple scripts, like you said, or by using conditional statements (if-else) and a variable (or parm) to store the current elevator position.

I actually built a fully working three floor elevator, which allows you to first select the desired floor with one switch and then launch the elevator to that floor with another switch. Without stopping at possible floors between. That system could also be used for elevators with even more stops. However, it was pretty complicated and even just three floors required somewhat lenghty scripts.

{NJO}*Dark 01-22-2006 03:28 PM

It would be interesting to try making that if you wouldnt mind emailing me the files for it and a bit of an explaination,

lassev 01-22-2006 05:07 PM

I could pack a test map and stuff into a pk3. However, I wouldn't be including much in the way of explanations. Like I said, to build such a system needed mid-high level scripting and entity usage. If you happen to be at that level, you would understand it after some studying, if not...Well, nothing I could really help with any manner of explanations shorter than a novel.

I'll see what I can do. It might take a little time.

{NJO}*Dark 01-22-2006 05:52 PM

thanks for the help, i am sure that i could make some useful sense of it

lassev 01-23-2006 08:03 AM

Alright. Check your email. The file should be there.

{NJO}*Dark 01-23-2006 01:22 PM

I just got it. It works rele well, got to try to understand it now then try to impliment it

lassev 01-23-2006 02:13 PM

Be sure not to stare at the scripts only, when you study it. The entities in the system have some very important keys and concepts in use.

{NJO}*Dark 01-23-2006 04:08 PM

On the khk1, why have you used always_on and wait 1, is that the only way to stop it firing too fast? also what is the animframe 2 bit mean?

lassev 01-23-2006 06:32 PM

Good points. Animframe must be an error. Likely I remembered incorrectly the key name and typed animframe instead of endframe at first, and then forgot to delete the wrong key. Sorry about that.

Wait is indeed to make sure the script isn't launched multiple times. And the entity description says wait is only valid with the always_on, so that's why it's checked. Might be redundant with the endframe, but who knows. Just like Jesterspaz, I'm not overly concerned, anymore, about pure ways but working ways.

Edit: There might be other ways than the wait to control multiple firings. One way could be a key to target an entity instead of the usescript key. Like usetarget, or something. Then that corresponding entity could set the wait. However, that wouldn't solve the issue with the animmap. Well, this was an elegant way, and seemed to work. Did you have some concerns regarding it?

{NJO}*Dark 01-24-2006 02:18 AM

never really dabbled in making a shader before, let alone one with an animMap, so had to try and work that one out as well. Overall i understood it fine. Only other question i have is about the set USE_INACTIVE true/false, i understand why you put them into there, but i am not sure which of the use commands you used for it and where it came from

lassev 01-24-2006 03:53 AM

Hmm... It's set_inactive. It's under the set_types command class, among boolean commands. It makes inactive or active the entity currently being affected. Also target_activate and _deactivate could have been used, but it was easier this way, since those entities were being affected anyway.

{NJO}*Dark 01-24-2006 03:15 PM

is it possible for the script to control which animFrame the shader for the button is on?

lassev 01-24-2006 03:19 PM

If you find out how, please tell me! :p

{NJO}*Dark 01-24-2006 04:18 PM

i have 2 questions now. in your script there are the three Affect commands each of which has a wait with in them, when i use the same set up, the different parts wait for each other to move before doing so. secondly my platform will not move, there is no reason why it should not but it isnt, you have any ideas?

lassev 01-24-2006 05:14 PM

Edit: I noticed you sent a pk3. I'll have a look at it...

Alright. You have a wrong retrieval function in use for the platform:

This is what you have:
move ( $get( FLOAT, "lift1_position_2")

And this is what is should be (and the buttons do have):
move ( $tag( "lift1_position_2", ORIGIN)

I have also seen many a scripter use the wrong datatype for the move command timing, but I doubt that matters at all in practice ($2000$ instead of 2000.000). I suppose this is caused by how you have set up your BehavEd.

Edit2: It would also be very wise to follow good (if not essential in this case) programming conventions and build your conditional statements using the regular if - else structures. Now you have only ifs, which is a seed for disasters.

Edit3: Notice also that _scriptrunners need the "count -1" key/value if they are to be used more than once.

Edit4: It has nothing to do with this, but your light stripe brushes in the elev shaft are for some reason an overlapping with brushes textured with the glow texture of the corresponding light stripe shader...

All times are GMT -4. The time now is 01:16 PM.

Powered by vBulletin®
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd.
LFNetwork, LLC ©2002-2015 - All rights reserved.