Archive: 16 posts

---

There may be an obvious solution but I'm running on two hours of sleep and haven't been able to come up with anything. So I'm working on my mech's jumping mechanics again. What I want is for the player to be able to hit the button and trigger a 3 second jump (rockets will run for 3 seconds). If he hits the button again before the 3 seconds runs out, I want it to add an additional 3 seconds, for a total of 6. I don't mean that I want the timer to reset to 3 seconds: I want it to add 3 seconds to whatever is left. Meaning, if the player triggers the jump, and then triggers it again one second later, I want him to have 5 seconds of jump left. Once the timer runs out, the player will not be able to trigger the jump switch again until the mech lands (the ground sensor triggers); if he jumps once and lets the 3 second timer run out, he should not be able to trigger it again until he's on the ground, but if he triggers it a second time before the 3 seconds are up, he'll get the extra 3 seconds. Also, it should only allow 2 consecutive triggers for a max of 6 seconds. I can't for the life of me think of a way to do this. Anything that relies on emitter lifetimes would just reset the timer to 3 seconds rather than adding 3 seconds to the remaining time. Any ideas?

2010-05-02 01:45:00 Author: Sehven Posts: 2188

---

I have an idea that I'm sure will work... I'll send you one on LBP. It emits a key-block with a lifetime of 3 seconds. If you grab again, it will trigger another key-block for another 3 seconds into the same space as soon as the previous block dissolves. That's the basic principle of it. I don't think the keyswitch would detect the two separate 3-second blocks. It would be like a single six-second block, if you grab twice.

2010-05-02 02:04:00 Author: Incinerator22 Posts: 3251

---

I'm pretty sure the rockets would cut out during the changeover. My ground sensor uses continuously emitting keys and it would cut out even if the keys' frequency and lifetime were identical (I got around it by adding a velocity to the emitter so the previous key wouldn't block the next one). I'll test the idea, before writing it off, though. Also, the mech is pretty thermo heavy already, so the more thermo-efficient the timer can be, the better.

2010-05-02 02:15:00 Author: Sehven Posts: 2188

---

I made one and sent you it. Optimized, It's about the thermo equivalent of the logic pack randomizer. There's a cut, but it's just .1 or less. Does it matter? Also, please describe your requirements for the double-grab switch. I have it so that after you tap, it resets before the first 3 seconds are over. You'd then have to tap two more times for the next three seconds of the rocket, if you didn't double-grab right away.

2010-05-02 02:56:00 Author: Incinerator22 Posts: 3251

---

I'll take a look at it. Any interruption of the rockets will cause a loss of momentum, though. I'm not using a grab switch (well I am, but it's for shooting). I'm using a jump switch (patent pending ). There's a plunger type thing that pushes sackboy down so he keeps traction with the control wheel, but he can jump to push it up. After a LOT of trial and error, I've gotten it to work nearly flawlessly. Anyway, the idea is that one jump will trigger the 3 second timer and a second jump any time during that 3 seconds will add an additional 3 seconds. I'm doing it that way 'cuz approx 6 seconds are needed to make big jumps, but there will be some smaller obstacles that you can just sort of "hop" over and you won't want to be stuck in the air for the full 6 seconds. [edit] I tried out your switches. One of 'em didn't seem to work. Like it'd run for 3 seconds and then if I grabbed again, it wouldn't add any time. The other one seemed to work alright but it's really complicated/thermo heavy, and I've still got to add the cut-off logic to keep the player from spamming the jump button. I'm trying out something now that should've occurred to me before I started. An incremental bolt. (https://lbpcentral.lbp-hub.com/index.php?t=19915-Incremental-Bolt) I'm feeling really stupid for not thinking about it 'cuz I asked a very similar question a few months back and the incremental bolt was the answer. I just didn't realize how similar this problem was to the other one.

2010-05-02 03:45:00 Author: Sehven Posts: 2188

---

I'm trying out something now that should've occurred to me before I started. An incremental bolt. (https://lbpcentral.lbp-hub.com/index.php?t=19915-Incremental-Bolt) I'm feeling really stupid for not thinking about it 'cuz I asked a very similar question a few months back and the incremental bolt was the answer. I just didn't realize how similar this problem was to the other one. That's pretty much what I was going to suggest. Double-bolt two motor bolts, one which slowly rotates counterclockwise, and the other pushed clockwise from a short on/off pulse. And perhaps something akin to the mechanism I use in my copyable "Multi-speed Train Example for TSFRJ v2" to prevent it from travelling too far in either direction. There will be an upper limit problem, in that you can only rotate so far before you're back to the start again, but I think there'll be a limiting factor like this with any approach.

2010-05-02 12:52:00 Author: Aya042 Posts: 2870

---

Yeah, I threw together the incremental bolt and set it up so that each one-shot fired into it adds 3 seconds to the clock. Incinerator and I spent a little while trying to think of an efficient way of implementing the cutoff, but we couldn't come up with anything. The upper limit isn't a problem, 'cuz each 3 second hit is only 18 degrees on the wheel, with a max of two hits. To recap: I need it to cutoff if the timer runs out, or after two button presses. Meaning, once the player has let the 3 second clock run out, or has triggered it twice, he shouldn't be able to trigger it again until the mech lands. I figure an S/R latch is in order: the reset will be triggered by the mech's ground sensor. The thing I'm having a difficult time figuring out is the set portion of the latch. Sure I could make some big complicated rig that uses paintball counters or something, but I'm trying to go as thermo efficient as possible (if the mech uses too much thermo, there won't be enough left to make a level for it). Any ideas on a thermo efficient way of detecting that the timer has been triggered twice OR has run out? I've actually just had an idea while typing this--got a full night's sleep last night so I'm not as stupid as I was yesterday--but I won't have time to try it until later. In the meantime, I'd like to hear any thoughts: my idea might not work, or someone else's might work better.

2010-05-02 18:15:00 Author: Sehven Posts: 2188

---

The upper limit isn't a problem, 'cuz each 3 second hit is only 18 degrees on the wheel, with a max of two hits. D'oh. Serves me right for not reading the whole of the OP. How about a three-state machine instead of an SR-latch, seeing as how there seem to be three possible states:- No buttons pressed Button pressed once Button pressed twice rtm's mutual exclusion switch (https://lbpcentral.lbp-hub.com/index.php?t=25067-Mutual-Exclusion-Switch) design is believed to be the most thermo-efficient for an n-state machine. Then all you need is some basic combinational logic to handle the state transitions:- State 1 active AND jump button pressed -> activate state 2, and trigger the incremental bolt State 2 active AND jump button pressed -> activate state 3, and trigger the incremental bolt (State 2 active OR state 3 active) AND timer expires -> activate state 1 By only implementing these three transitions, this should effectively disable the jump button when the machine is in state 3.

2010-05-02 22:45:00 Author: Aya042 Posts: 2870

---

State 3 would be where the switch is disabled, right? The only thing that should trigger state 1 is the ground sensor. I think I understand the process now, though. I'll still have to try my idea out first: I'm thinking that since I'm using an incremental bolt to move a mag key 18 degrees per hit, I can set a mag switch with a 342 degree detection area and have that feed into an SR. If the key moves more than 18 degrees (as long as there's even 1 degrees left on the timer, a second hit would move it past 18) it'll trigger, and if it returns all the way to its initial position, it'll trigger (obviously, it won't actually be 342 degrees: it'll depend on exactly where I put the switch). Of course, that means having a one-shot switch in an already triggered position when the level starts, which can be problematic, but that shouldn't be too difficult to work out. [edit] Seems like my idea won't work Mag switches with angled detection just don't seem to be accurate enough: I set it to on/off and hooked it to a light and it would sometimes flicker and sometimes just not trigger at all. I'm not too thrilled about the notion of at least two AND gates, an incremental bolt, and 3 mutual exclusion switches all just to implement one function. I'll have to give it some thought to see if I can trim it down before I build it, but that can wait 'til tomorrow.

2010-05-03 05:55:00 Author: Sehven Posts: 2188

---

Got it working! I'd love to explain how, but it's a really goofy (albeit thermo-efficient) set up, and I'm really not sure how to describe it. It uses Rtm's mutex switch but in a wierd way: instead of having two of them for two states, I use one that relays a one-shot signal when it gets triggered and then it moves to the right so that its emitter isn't blocked by the key it just spit out. If it's triggered again, it spits out another key and relays another one-shot signal, but now it can't move any more so it's blocked from emitting. When the mech lands, another mutex emitter fires resetting it back to its default state. I abandoned the idea of having the jump switch disabled by the timer running out: now it only gets disabled if you trigger it twice. It's easier/more thermo efficient this way, and I think it's actually more playable too: you can make a short hop and then, if you don't want to fall back down yet, you can trigger it again, before or after the apex of the jump: but you can only trigger it twice before you have to land. Thanks Incinerator and Aya for the help. I saw Rtm's mutex switches a while back but hadn't really comprehended what they could do until you suggested using them.

2010-05-04 03:08:00 Author: Sehven Posts: 2188

---

Got it working! I'd love to explain how, but it's a really goofy (albeit thermo-efficient) set up, and I'm really not sure how to describe it. Sounds interesting. I'll have to swing by and take a look sometime. You should also check out this thin/theck gas logic device that comph recently built to replace my slightly clunkier device. Something that I hadn't thought of is that you can bolt an arbitrary number of overlapping theck gas layers onto the same thin gas layer in exactly the same location. Oh. Another oddity I found was that, despite having no mass, rotating gas still produces torque on whatever it's bolted to, including other gas. Weird.

2010-05-04 03:40:00 Author: Aya042 Posts: 2870

---

I knew gas could apply torque to other gas (gas wheels would never move if they couldn't) but I didn't know that they could torque non-gas objects. I would be interested in seeing Comph's device. Have I shown you my newest control pod? It occupies one thin layer (which is just the backplate) and one thick layer, but there's basically 5 layers of stuff going on in it. It's got two theck gas wheels double bolted to the backplate: they're bolted to each other but they're still in the same layer! Then it uses the theck and thick layers for the hamster wheel, and the thack layer for the part that holds sackboy in place and the plunger/jumpswitch. Thin backplate + Theck x3 + thack = 5 layers (6 if you count the thick layer wheel separately). Other than that, I don't do much logic overlapping 'cuz it gets easy to lose track of everything when you can't see it all laid out. I'm pretty sure I showed you the invisible logic that I stuck on my weapons, though. Thin and theck gas have radically changed the way I do things. One thing to be careful about when overlapping gas logic is that when you capture it, mag switches/keys, emitters and such can transfer from one gas to another. Drove me crazy when I first ran into it, but now I use that trick to harvest switches from Mm objects (I added instructions into that tut I wrote up a while back (https://lbpcentral.lbp-hub.com/index.php?t=25258-Sourceless-lights-invisible-spikes-and-a-couple-other-tricks-[UPDATED-4-29])).

2010-05-04 04:02:00 Author: Sehven Posts: 2188

---

I knew gas could apply torque to other gas (gas wheels would never move if they couldn't) but I didn't know that they could torque non-gas objects. I'm not 100% on this, but it certainly looked like it. I had a thin/theck gas logic device glued to a car, and it looked like whenever one of the 0.1s wobble bolts flipped, it actually produced torque on the whole car. It's possibly not the same as bolting the gas directly to the car itself, but it seems reasonable that the torque produced between the two gas layers would be transferred to the car, since it was glued to it. It's got two theck gas wheels double bolted to the backplate: they're bolted to each other but they're still in the same layer! Ooh. This is kinda new territory for me, but it's somewhat unclear when bolting two layers of gas onto the same object whether you're just bolting two onto one, or whether you can double-bolt into effectively three different layers, despite only using two. Freaky stuff. Other than that, I don't do much logic overlapping 'cuz it gets easy to lose track of everything when you can't see it all laid out. Indeed. That's a major problem with all this. It's usually best avoided, unless there's some specific benefit of using overlapping gas which can't be achieved any other way. I use that trick to harvest switches from Mm objects... I did take a brief look, although I haven't actually tried it out yet. I was somewhat deterred by your assertion that the success of that method is somewhat random.

2010-05-04 13:49:00 Author: Aya042 Posts: 2870

---

Why not try using a double piston-and-mag-switch setup. Each piston is hooked up to an AND gate. The AND gate for the first piston is the trigger AND a key that checks the mag switch is in the unactivated position. Pressing the sensor should extend the first piston, pushing the mag key into the radius. The second piston's AND is connected to the trigger AND a switch that checks that the mag key is in range. This would then double the length and lengthen the time the mag key is in range. A block would then be emitted above the retracted piston when the timer ran out, that is dissolved on contact with the ground. Give us a shout if I've confused you. Hope this helps!

2010-05-04 14:03:00 Author: Holguin86 Posts: 875

---

I was somewhat deterred by your assertion that the success of that method is somewhat random. Only a little bit. So far the only times it hasn't worked for me was when I was trying to do two switches onto two separate blocks of gas. I haven't done enough testing to know for sure if it just randomly doesn't work sometimes, or if you can only do one at a time. @Holguin: sorry, I can never follow descriptions like that. Maybe if I read it a few more times it would click. Anyway, I've got the problem solved now with not a lot of thermo spent on it, so I'm content to call the problem solved.

2010-05-04 18:34:00 Author: Sehven Posts: 2188

---

I could build a prototype for you if you want - I'm rubbish at explaining things like that.

2010-05-04 22:42:00 Author: Holguin86 Posts: 875

Posts: 1077139    Threads: 69970    Members: 9661    Archive-Date: 2019-01-19

Aus dem Archiv wurden alle persönlichen Daten wie Name, Anschrift, Email etc. - aber auch sämtliche Inhalte wie z.B. persönliche Nachrichten - entfernt.
Die Nutzung dieser Webseite erfolgt ohne Speicherung personenbezogener Daten. Es werden keinerlei Cookies, Logs, 3rd-Party-Plugins etc. verwendet.