Boothand

Asgarath, I know you're trying to be helpful, but a few things to consider: There is no way I can relate to a script that takes 20 minutes to read, which has something to do with the +1 command, which I requested a simple explanation for (read: Veeeeery small portion of a script. One or two sentences summary) - which in turn, turned out to not have a clear relation to what I was trying to achieve, which you said aaaafter the wall of code I appreciate your effort to help, but maybe hold yourself a bit more back when you're aware that you don't have a solution. Way too much information. I do think I get what the +1 thing is though. But let's not talk more about the +1 deal. @, thanks for the insight!

That's correct. Another way to do it, which gives you more overview in the big picture is to set the targetname of the elevator yourself (one of the brushes). Then set the target of the trigger to the elevator's targetname, and it will connect by itself.

Wasn't aware of this. That's great though. The "add to entity" feature isn't on my GtkRadiant 1.5 unfortunately. For 1.5. users, Entity > Ungroup will reset it to worldspawn.

I don't know where you got all these ideas from - no. I don't want to make anything randomized or appearing away from each other. All I'm interested in, in this thread, is finding a way to do math in Behaved. I want a script to get an entity's origin. Then take that origin and do for example "+ 0 30 30". What this means: You could make a brush and a trigger. Everytime you press the trigger, the brush moves 30 units on the Y axis and the Z axis (0 30 30). So, in theory, you could press that trigger forever, and it would move everytime. You could use two steps to make a stairway to the sky, if you wanted. I'm not talking about adding steps either. Only moving the brushes that I have. Another example of usage for this method: You could have a floating platform that would go wherever you wanted. Pressing the trigger would loop an offset on the X axis. So you would constantly be moving in one direction. The next time you press the trigger, it offsets on the Y axis. Please don't give suggestions on how to do this now - this is not something I want to make. Again, all I'm interested in, is getting a vector, and adding values to the vector. You mention something about "+1" here. Try to explain in a simple manner what you mean here. And how would you do + in Behaved?

You have to make the multiple brushes first, then when selecting all the brushes, make it an entity. If you already have an elevator and want to add brushes to it: I don't think there is a way to set an entity back to worldspawn. But if you select the new brushes together with the old entity, and make that a new entity, the old one will probably still stay in the Entity List (L). This can cause problems during compile/testing. So I would first identity the current entity in the Entity List, and then select the old and the new brushes, make it a new entity, and then make sure you delete the right one (the old one) in the Entity List (select it and press backspace).

But, that provides all those steps are actually there Might as well use func_usables. Step3-4-5-6-7-8-xxxx. This is unnecessary to script compared to the usables. My steps appear instantly (no visible movement). I'm looking for something like a mathematical function designed for two steps. If not, I'd go with the usables.

It's a good thought, but - yes, you can move step1 to the origin of step2, but where you would move step2? As far as I know, there's not a way to move both of them with the same move command (and to an unset origin in this case).

Haha glad you learned something! Strange how the game flips stuff. Defies my logic. Even when I changed it the way it should be (from left to right), it didn't get right in game. The ones I sent you worked in my game, but not in yours - that's the most annoying part

I already know how to deal with tags and move brushes. My point was that if I did that, I would need very many tags and much work and time. The only thing I'm looking for in this thread now, is if it's possible to do relative movement. The next best solution is the func_usables.

The water map can't help me I'm afraid. The water going up and down is just a door, or similar with two positions. The func_usables could actually be a better alternative than scripting, since it's easier to make changes - thanks for the reminder! It could make it difficult to have many steps though, because of the entity limit (I don't remember the specifics here, but things could stop working if there are too many). But it's probably currently the best solution, until eventually math is possible in the scripting.

Not like Escher But that would be the top of interesting, of course. Actually, it's just a staircase that "builds itself" while you're walking it. Only 2 steps exist in the staircase. So I was thinking that I would include it in a sort of puzzle, where the player needs to reach a level/platform high up that he can't reach. It doesn't go in circles, just straight forward. I've thought of a lot of things, but I can't think of a smart way to do it. Not unless you can move several entities with a single command either. I could make it the hard way, but it would have very low re-production value.

Maybe instead someone could help me think of a better way to do something. I don't wanna create a new topic, as relative positions would be ultimate solution though... I'm creating a magic staircase. Or an infinite one, if relative positions were working. I'm creating a staircase that only consists of two single steps (step1 and step2). When you step on step2 it runs a script where step1 and the trigger that belongs to it, moves in place for you to step forward again. Then when you step on step1 it runs a script where step2 and its trigger gets up infront of step1 again. This works, I can confirm that. And I only need two scripts. But it creates really really a lot of work, and huge scripts, and busy looking map files since I have to deal with very many tags/vectors. I'm currently using the "if parmX is X, on this and that step and trigger, move step and trigger to tag and set parmX to X". I would really like just a function, one that would get the current origin, add values to the vector, set this as the new origin and then run the same function next time it's triggered. This could be useful for a lot of stuff though, not just this one (stair)case. Any suggestions?

Is this when you are on the elevator, or while waiting for it on the down or upside? Almost sounds as if the trigger field gets activated again while you're waiting for the elevator. Do the triggers have the use_button enabled? Or else it could be activated by you just standing in the field and waiting for the elevator, thus shooting up again as you described.

Hmm, what I did fixed it 100% on my own computer. The problem was only the naming. They didn't fit together because for example the redsky_ft should really have been redsky_rt or lt, and so on with the others as well. I don't remember the exact cases now. After I renamed them, I sent the new files back to you. Are you sure you replaced the old files completely? The ones in your textures/skies folder. Screenshot of it working: https://dl.dropboxusercontent.com/u/58757568/shot0000.jpg If, for some reason, it still doesn't work with my files (which would be a first class mystery), you have to use the same method I used. It's just a matter of looking at which images are going to fit together, and envisioning the position they must have. Left --------> front, right, back, (left). Then up and down. If this works, but the up and down textures don't fit in yet, you have to rotate them until they do, since you have changed the positions of east, west, north and south in your images. Hope you get it working, and once again, check if you truly have replaced the old files. -----------------------------------EDIT: ------------------------------------------------ Actually, I noticed now that the direction is inversed. I don't understand how this should differ in our games, however, but what has happened with the new files is this: The left sky is compatible with the front sky along the left seam, not the right as it should be. <------- and so on. This is strange, as I made sure it made sense a few days ago. It does work flawlessly in my game however. I'm finding it very hard to turn it around the way it logically should be... but it.. works?

Wasn't aware of the attach file function! That's cool though Next time I'll just.. give my PM on email instead.

I'll give you my email on PM.

If you're really into that sky, I could take a look if I could make it seamless (if they are at all meant to be used together)

Yeah, you're supposed to type in the name of the .shader file along with the other names in the shaderlist.txt. You usually have one .shader for every level, where you collect all your shaders in. Your skies are named redsky_etc, but you're making the shader look for "thesky".

There we have the answer! This works Thank you! (Is the accept as answer feature gone?)

I've got an idea that requires me to move brushes relative to their current position. I was hoping there would be a way to do math equations within Behaved, but I haven't found a way with my limited experience. What I was thinking of was something along the lines of move ( $get( VECTOR, "SET_ORIGIN")$ which (I believe) would get the entity's origin. Then I'd want to simply do + (x y z) and add coordinates to the origin. It sounds like a thing that should logically work! Any ideas how to move brushes relatively? Edit: There is something called set_z_offset which can do it only along the Z axis, and you can't set the speed in the traditional way. The description says "Vertical offset from original origin... offset/ent's speed * 1000ms is duration". I can confirm this feature works. So it can't be that far away?

Yeah I see the difference. Actually that was what I thought I had to avoid - affects within affects. Affecception. Everything looks like it's the minion of downwardstrigger. But believe it or not, it still doesn't work. Same behavior, after I changed both scripts' hierarchy like this. Tested on two different maps, with slightly different scripts. Here is a pk3 using the same method you showed. I tried your exact one on my other map, but with the same result. https://dl.dropboxusercontent.com/u/58757568/scripttest.pk3 (same link as earlier, but with new content)

Sorry, didn't see the post before now. The close-trigger is activated again after the movetask has happened. I have re-structured my script, like @ said, but maybe not in the right way. I did notice some obviously bad things, like the trigger inactivating itself before running the task, and affects within an affect (for some reason the task was carried out either way though). My scripts now do: affect door - move affect open trigger - inactive affect closing trigger - active ________________________ affect door - move affect closing trigger - inactive affect open trigger - active I thought this would fix it, but the same thing happens (was this what you referred to, @? Or was it directed to the strict use of affect and lack of use of if/else? - which I don't see the use for in this context). And Asgarath, what you're presenting with the func_door is a workaround. I'm interested in making this very possible thing functional, and to learn scripting. I don't want to redirect the attention to something that works, but doesn't let me learn what's not working in this method I did try to switch out the static with a func_door though, but they acted the same way.

Polarity, I will try the method you showed, thanks for that! But to answer your question, I'm building this from the foundations so to speak. If I can't make a script reset itself in such a basic form, I cannot truly utilize the potential of scripts and use them for other things. When that's said, it might be I'll use the method you showed me, but I would still like to know how to solve the problem I have on the current script I'm using, since it's highly relevant to further scripting mastery

Unfortunately I've tried using flushes and they make no difference, it seems no matter how I do it! Here's a test map you could try, to see exactly what happens + the source files. https://dl.dropboxusercontent.com/u/58757568/scripttest.pk3 Just go behind those brushes and press use.

Actually there is no problem with the activating and deactivating. The problem is that the "move" command doesn't happen the second time the "upwards" script runs. I'd much rather solve this issue with Icarus because I have the same problem in other scripts. For example, I have one script that runs a looping animation on a brush. Then when you press a trigger, it will run a different script on the brush, and in the end of it, it will run the idle script again. This almost works, because when it runs the idle script again, it only runs the animation once, and the loop never happens. So instead using workarounds, I'd rather just know why the scripts don't run as they should