Archive: 53 posts

---

Hi everyone, I haven't been here (at least not posting) for a while again, and I'll probably be away again (very little time), but of course I got myself LBP2 at release Some might still know I was looking into grid movement in the beta. I got something okay, but I tried to look deeper into it today. What I mean with grid movement is basically what's used in various puzzle games; blocks moving in fixed intervals. I haven't seen any grid movement logic yet, so here's what I found. Now Updated to V1.2. Here's a copyable level: lbp.me link (http://lbp.me/v/w4bked) Includes: - Slow Grid Mover (V1.0) - Fast Grid Mover (V1.2) - Grid Border - Square - Hexagonal Grid Mover - No Border & Square Border Versions (V1.0 logic) The Slow Grid Mover moves at speeds of 0.1 seconds per grid unit. The Fast Grid Movers movement speed is equal to that of a feedback Not-Gate, which is the fastest "recognizable" pulse in the game, I think. (I once discovered that using a selector to "relay" the signal through it's ports pulses twice as fast as the Not-Gate. However, I haven't found an uses for it, since every other piece of logic seems to be unable to process the signals that fast) Because it is that fast, I included a 0.1 second delay after moving one grid unit when holding down the directional button. When holding down the button, all further movements will be without delay. The delay time can be adjusted by simply chaning a timers target time. I added a not on this and on how to remove the delay inside the microchip, it's easy, don't worry. Though removing it will make it a bit hard to accurately move single grid units, because it will have moved 2 before you even know, but feel free to try =). I also included a button "filter" inside the chip. It makes sure that only one direction is "recieved" by the mover at a time, even if you press multiple directions. It also keeps the first input active for as long as you hold down that button, ignoring all other inputs during this time. There's another note in the chip on how to remove this. The Grid Border - Square chip allows you to add a square border to your grid by just connecting the grid movers outputs to this chip and connecting this chips outputs to the advanced mover. This only applies for 4-directional grid movement, it cannot be used with hexagonal grid. The grid size can simply be changed by adjusting the maximum count of 4 counters. Another note inside the chip for this. Hexagonal grid is something I made after requested in this thread. There's a borderless version and a version with square border, which includes a few pieces of confusing logic however. Generally, If you need completely costumizable grid, I suggest to use tags & sensors instead of complicated logic. It's easier and you can achieve any costumized form of border. This applies to all kinds of grid movement. Heres screenshots of an example on how to do it with hexagonal grid and hexagonal border: http://i3.lbp.me/img/ft/6b37fd0cee6e134d53760d5b78290e10c486a310.jpg http://id.lbp.me/img/ft/c8d3d2b2c7bf3071c47f2ed6816ff212001a0598.jpg A short discussion about this can be found on page 4 of this thread. Basic concept (V1.0): First the most important stuff: The specs - 100% accurate alignment on grid, no matter how fast you press the buttons - Moving at 0,1s Intervalls, may be possible even faster - Excluding a controllinator and an advanced mover, it only needs 8 logic components for left/right movement! - Can be expanded to do 2D movement, of course. And here's how to do it: http://ie.lbp.me/img/ft/68ef6e9073d874fb527a00fbbdf371f8c9f9904c.jpg There are 3 Timers, 2 And-Gates, 1 Or-Gate, and one Direction Splitter/Combiner The timer on the left is set to 0,1s; Count Down; Inverted Both timers on the right are set to 0,1s (time actually doesn't matter); Count Down, not Inverted Mover is set to 100% acceleration and 100% deceleration! In the picture, the grid-blocks are one large grid unit big. The mover is set to 30,0 speed and moves one big-grid unit per pulse. Adjust your speed accordingly, depending on how big your grid should be. And that's it; I think that's pretty awesome If you want to add the second dimension movement, repeat the same pattern for the other 2 directions and hook all 4 directions to the same Or Gate (the same one which is on the picture, just with 4 inputs) You will have 5 Timers, 4 And-Gates, 1 Or-Gate with 4 inputs, 2 Direction-Splitters, 2 Direction-Combiners Theres' still an extra adjustment to do for 2D movement though. You have to make sure that the player cannot input 2 directions simultaneosly (e.g. by holding down left/down on the D-pad), because that will screw up the deceleration again. To achieve this, use a Xor-Gate with 2 (or 4) inputs and connect both direction buttons (or all 4 outputs of the direction splitters) to it. Add a third input to all the And-Gates and connect the Xor-Output to it. Done. (Only negative effect: you can't hold down buttons anymore, this can be fixed though, but I'm sure you'll figure it out if you need it.) For everyone lazy, here's how the complete 2D movement looks like: http://ie.lbp.me/img/ft/bcef65bda5ba920202e405fdefc8954e7070da85.jpg _________________________________ The difficulty of grid movement - how and why does it work? (V1.0): The problem with grid movement is that movers need a specific amount of time to decelerate, even on 100% deceleration. If you just use a basic pulse as input for the mover, it will look like it works at first, but the moment you press the buttons a little faster, it screws up the grid alignment. And to prevent that, all you have to do is put a delay after each button press, which is what I did. Now the lowest time is 0,1s and the second lowest is 0,2s, meaning at first you'd think there would have to be at least 0,2s delay between each button press, which is already not so welcome. A timer hooked to it's own reset however, outputs a shorter pulse than 0,1s, which means you can make the delay be 0,1s, which is twice as fast and results in "smooth" controls. A pulse using a Not-Gate looped into itself is even faster that the self-resetting-timer, so it might be possible to get even faster movement (if anyone needs that). You'd have to test the grid alignment first though, because the cooldown might not be enough for the mover to decelerate completely. || Update: tested this, doesn't work too well. V1.2 makes this unneccessary however. I'm feeling a little stupid thinking back how I spent days in beta to get 100% accurate grid movement, but still ended up with not-so-good controls I hope this helps some of you, maybe we'll see some nice puzzle games in the future with this. I made a Puyo Puyo level with this, so be asured it's very accurate and well-working.

2011-01-28 22:30:00 Author: Shiwayari Posts: 167

---

So could i use this for a turn grid based RPG like "Disgaea" or "FFT"??? if so that sounds cool. :3 *mew

2011-01-28 22:36:00 Author: Lord-Dreamerz Posts: 4261

---

I haven't played these games, but as long as you can do the game-logic it should be possible. I just uploaded a copyable tech-demo level called " [Tech Demo] Grid Movement "Perfection" ", for the lazier ones =)

2011-01-28 23:12:00 Author: Shiwayari Posts: 167

---

good stuff. This should help me a lot. thanks. I haven't tried it yet, but I'm assuming it would be easy to make it so that the object is in constant movement, and the d-pad would only be used to change the object's direction? I'm also hoping to make it so that I can slowly increase the object's speed of movement over time. Any suggestions would be appreciated.

2011-01-29 01:39:00 Author: Jay_mb Posts: 3

---

100 rogues, HERE I COME! (grid will make it possible!!!)

2011-01-29 11:15:00 Author: .jamo Posts: 172

---

Looks like it's really useful. Definitely going to try this later.

2011-01-29 14:49:00 Author: ADS_LEGEND Posts: 140

---

Nice to see it helps. I was working on reproducing my calculator from the beta the whole day and while I was at it I added a logic-only solution to define a border for the grid (I'm using it for the button inputs). So it moves only in a fixed box. I'm sure other shapes are possible as borders as well, but probably not so easy without tag sensors. But the box-grid I have now works like a charm. I'll update the level sometime, adding the above. good stuff. This should help me a lot. thanks. I haven't tried it yet, but I'm assuming it would be easy to make it so that the object is in constant movement, and the d-pad would only be used to change the object's direction? I'm also hoping to make it so that I can slowly increase the object's speed of movement over time. Any suggestions would be appreciated. Constant movement should be pretty easy to achieve. Actually, the logic is already set up so that it will move constantly as long as the button is held down. So all you have to do is wire the controllinator to a selector and use the selector outputs as input for the grid movement. I never really messed around with speed stuff, but this might get a bit tricky. The reason the thing stays on the grid, is because it moves at a fixed speed with fixed pulse-times. It should be easy to put a delay after each single movement though, if that's what you want. Then you could switch between different delay-timers and integrate them into the logic with And-Gates. Remember, the single timer in the middle of the microchip is the one that specifies the delay between movements. Edit: I added the grid mover with border-logic to the level.

2011-01-30 00:49:00 Author: Shiwayari Posts: 167

---

could you youtube that level please so your the guy who made the calculator!!!!!!! i've never typed to god before

2011-01-30 17:15:00 Author: GribbleGrunger Posts: 3910

---

Lol Sorry, Youtubing it would be quite hard as my only camera option right now is a bad cellphone cam. And what do you mean by "the calculator"? I'm not the one who made the very first one in LBP1, and there were many calculators around. But back in beta I made the first calculator that actually had a digital typing interface (or at least i don't know of any other) just like a real calculator. With shifting numbers and stuff. The calculator logic is finished now, but I'm having some trouble with timing pulses, it'll take a while to finetune. I've been coming up with enough logic for that interface, that I want to make another full "logic level" just like my Switch Collection from LBP1. Though university is consuming 99% of my time and I won't have enough time until probably Jule. I shouldn't even be playing right now

2011-01-30 17:30:00 Author: Shiwayari Posts: 167

---

you're not playing! you are creating!!!!

2011-01-30 17:43:00 Author: GribbleGrunger Posts: 3910

---

... Constant movement should be pretty easy to achieve. Actually, the logic is already set up so that it will move constantly as long as the button is held down. So all you have to do is wire the controllinator to a selector and use the selector outputs as input for the grid movement. I never really messed around with speed stuff, but this might get a bit tricky. The reason the thing stays on the grid, is because it moves at a fixed speed with fixed pulse-times. It should be easy to put a delay after each single movement though, if that's what you want. Then you could switch between different delay-timers and integrate them into the logic with And-Gates. Remember, the single timer in the middle of the microchip is the one that specifies the delay between movements. I've got constant movement working now. I had to place the selector after the direction splitters though. placing the selector before them screwed up the advanced movement controls for some reason. I haven't dug too deep into speed yet, but I do know that I'll eventually need the speed to be faster than 0.1, so I'll need to try using the Nor-Gate and Counter method. Would I place those right before the direction combiners?

2011-01-30 22:16:00 Author: Jay_mb Posts: 3

---

I've got constant movement working now. I had to place the selector after the direction splitters though. placing the selector before them screwed up the advanced movement controls for some reason. I haven't dug too deep into speed yet, but I do know that I'll eventually need the speed to be faster than 0.1, so I'll need to try using the Nor-Gate and Counter method. Would I place those right before the direction combiners? Yup, you'd place the fast pulse right before the combiners (instead of the timers, of course) and then you'd replace the delay-timer (the single timer in the middle of the microchip) with the timer-pulse (the same one that is before the direction combiners right now) Nor Gate pulses like 15Hz and timer like 10Hz. So the deceleration would have to finish in 1/5 of a second to keep the grid alignment. Might work, but I didn't try it. __________________________________________________ _______________________________ Some more advanced advice I encountered while creating. I decided try have a go at a block-based puzzle game a few hours ago and the main problem I knew was going to pop up is rotating blocks. Because the pivot has to be at a point so that the whole object will not go off-grid. And as many might already know, we can't really choose the pivot. But I need to choose it freely, so how to do it; I had this awesome idea, why don't I just change the geometry by using hologram material, because I can put hologram anywhere, to change the pivot! I figured that the pivot calculated by the game would be the geometric center of the object.. Well, long story short, that doesn't work, because as it turns out, the pivot is actually the gravity center of the object. And since hologram does not have weight, it won't change the pivot But then I had a similar idea: I could just glue a 2 or 3 layer thick hologram material to the block. And then I can just copy the block, mirror it at my own desired pivot and glue it into the hologram material at the furthest back-layer. My gravity center is now at the position where I want to have my pivot! All that's left is to hide the block on the furthest back layer by putting a thin wall in front of it. Keep in mind to destory the block on the back layer using a destroyer-switch, so that the next block won't be blocked by it. I've tested all that out and it works really well. Of course there's detection of surrounding blocks and extra "grid-border shifting" to do, but that's how you can choose your own pivot. Only downside with this method is that you'll use a whole layer, because it's used by the unwanted blocks. Another feature I could add to the level, maybe the basic frame of what I have now of my puzzle game. I'll see.

2011-01-31 00:57:00 Author: Shiwayari Posts: 167

---

This is awesome! I plan on using this to make a Bejeweled clone.

2011-01-31 03:55:00 Author: Yofig Posts: 288

---

Is there a way I could use this, so that it continues to move instead of having to press the button several times?

2011-01-31 11:36:00 Author: xForrest Posts: 72

---

Awesome, I can't quite figure out how to make it wireless, basically I'm trying to set it up to work on every object that is emitted, unfortunately a tag sensor is my only option and will only allow right movement and up movement, so I'm trying to set it up so left 1 block is L2 and right one block is R2, not bothered about up and down movement, any ideas?

2011-01-31 13:47:00 Author: RAWTalent Posts: 224

---

Is there a way I could use this, so that it continues to move instead of having to press the button several times? If you look a few posts up (#7, #11), you'll find an answer to that. The logic is already set up to do that, just use a sequencer as input instead of the controllinator directly. Awesome, I can't quite figure out how to make it wireless, basically I'm trying to set it up to work on every object that is emitted, unfortunately a tag sensor is my only option and will only allow right movement and up movement, so I'm trying to set it up so left 1 block is L2 and right one block is R2, not bothered about up and down movement, any ideas? I don't understand what you mean with the red part. Getting all 4 directions shouldn't be hard though, just connect the controllinator directional outputs to direction splitters, connect these splitter to 4 different tags. Then put the corresponding 4 tag sensors inside your objects and connect them to 2 direction combiners. Then you'll have back your directional input, which you can use as input for the mover. ___________________________________ I just added a demonstration of rotating blocks to the level. (What I talked about in my last post)

2011-01-31 14:31:00 Author: Shiwayari Posts: 167

---

Moving the block left needs to be L2 and moving right needs to be R2, but needs to be triggered by a coloured sensor switch.

2011-01-31 14:44:00 Author: RAWTalent Posts: 224

---

Ah, well then just do about exactly what I said in my last post: Outside the object to move: - Place a direction combiner. - Connect L2 to "-" of the combiner. - Connect R2 to "+" of the combiner. - Connect the combiner to Left/Right input of the grid mover. - Connect the Left/Right output of the grid mover to a direction splitter. - Connect the "-" of the splitter to a "Left" Tag. - Connect the "+" of the splitter to a "Right" Tag. Inside the object to move: - place a "Left" Tag Sensor and a "Right" Tag Sensor and a direction combiner. - Connect the "Left" Tag Sensor to the "-" of the combiner. - Connect the "Right" Tag Sensor to the "+" of the combiner. - Connect the combiner to the movers Horizontal Input. That should do the job I think.

2011-01-31 15:34:00 Author: Shiwayari Posts: 167

---

Nope unfortunately it seems to cancel out the grid mover entirely and ignores it :/

2011-01-31 19:19:00 Author: RAWTalent Posts: 224

---

Are you sure you did nothing different? Because I just tried it the way I described and it works. I just made a quick version of what you wanted to have (or at least how I understood it) and put it in my level, aaall the way to the upper-left corner of the level. So you can copy the level and have a look.

2011-01-31 19:45:00 Author: Shiwayari Posts: 167

---

Ah I see what I did wrong now, unfortunately because it only works if deceleration is at 100% it means the object wont fall :/ back to the drawing board for me , cheers for the help anyway

2011-01-31 20:12:00 Author: RAWTalent Posts: 224

---

Oh I see. Well yeah, deceleration at 100% is essential here. If you need the object to fall, you could try putting the mover inside an extra microchip, and then wire an Or Gate with all the direction inputs to the microchips on/off. That way the movers deceleration will only be active as long as the object is moving on the grid, and won't be "decelerated" otherwise. If you need grid movement while falling down however (simultaneosly, i mean), then I don't have any spontaneus idea.. I did a larger analysis on mover deceleration/acceleration back in beta and it does a lot of stuff noone wants it to do. Edit: Wait, I think that's about what I need to do for the puzzle game I'm trying to create right now. Though the down motion will be made by the mover itself. What you need is some kind of logic that takes the "move down" input as highest priority. So that it moves down no matter what other inputs are active at the same time. That's probably going to get a bit more complex, but it should somehow be possible. I'm finished with all the block-rotation logic for my puzzle game now, so nothing will break anymore; so one of the next things is going to be that down-movement. Maybe I'll upload a copyable version of the finished puzzle game logic when I'm finished, but I'm not sure. It got quite complex with that rotation logic already. Anyways, good luck.

2011-01-31 20:33:00 Author: Shiwayari Posts: 167

---

Thanks, yeah this is all great stuff, I have a full working Tetris now, the only thing left is the down movement and I'm done

2011-01-31 20:44:00 Author: RAWTalent Posts: 224

---

Yeah, that pretty much looks like how I did my grid movement only much, much neater. Seems to be a bit more elegant than mine too! (and to think, I was so proud! ) Although mine is currently wired up to the analogue stick, which is why I'm still able to confuse it by wiggling the stick rather than using precise, deliberate motions. I figured switching to the D-Pad would fix it but I haven't gotten around to it yet, at least I know it will work now!

2011-01-31 21:58:00 Author: Unknown User

---

awesome. i did this in the beta using sequencers instead of timers (more time = more distance) but it was too slow & follower jumping always got off track. this is nice & clean. congrats on the first actually helpful advice posted in this forum

2011-02-01 12:46:00 Author: Unknown User

---

Would a gravity toggle possibly work to send things in constant downward motion? Like a level gravity switch with weak pull that only activates when controllinator or sequencer is active?

2011-02-02 20:08:00 Author: Shadow_Wolf_1987 Posts: 108

---

After thinking about it a bit, I found that this is actually a bigger downside to having this simple basic logic. To stay on grid, there has to be a delay after each movement, or the deceleration will mess up the alignment. So there's no really easy method I can think of to achieve a simultaneous down-movement. What you can do however, is create the illusion of the object moving down, by moving everything except the object itself, up. You'd need a mover and tag-sensors on each object and a single gravity-timing logic that transmits a wireless signal to all objects. If you need to switch controls between objects, you'd need another piece of (probably small) logic on each object that tells it to only be affected by the down-movement while not being controlled by the player. This method could get a bit tricky with detecting collisions though. In the end it's a bigger downside that I didn't think of at first. I need down-movement for my puzzle game too, so I'll try out what I said above whenever I have time to continue creating. Or maybe someone else has a better idea

2011-02-02 20:41:00 Author: Shiwayari Posts: 167

---

That works, but unfortunately you eventually hit the level ceiling :/

2011-02-03 11:45:00 Author: RAWTalent Posts: 224

---

Well, if you don't need gravity at all times (for example you don't need it when spawning new blocks in tetris), you can just move it back to it's inital position in that short time interval. Or you could put a sensor on top of the level and fake a "loading time" where everything is moved back to the ground.

2011-02-03 17:42:00 Author: Shiwayari Posts: 167

---

Darn! I was gonna try to do this today. But you beat me to it. XD Looks like I'll just have to steal* yours. Less work for me I guess. *By steal, I mean look at your logic and go from there.

2011-02-03 18:28:00 Author: jalr2d2 Posts: 256

---

Deam i need to be faster on my project

2011-02-03 18:49:00 Author: Shadowriver Posts: 3991

---

Deam i need to be faster on my project That reminds me of what my old coach used to say "If you are not practicing, someone else is" except "If you are not creating Tetris, Someone else is" is more what I was thinking.

2011-02-03 19:05:00 Author: EinRobot Posts: 739

---

For Tetris wouldn't it be easier to have one emitter per shape. Have all shapes have tags that connect to dcs for control needs. And have a randomizer attached to all the emitters?

2011-02-03 20:10:00 Author: Shadow_Wolf_1987 Posts: 108

---

For Tetris wouldn't it be easier to have one emitter per shape. Have all shapes have tags that connect to dcs for control needs. And have a randomizer attached to all the emitters? That's one way of getting the blocks themself. I don't see how it does have anything to do with the movement itself, though? The problem is the grid alignment. My version is very simple in regards to the logic, but needs a workaround for the down movement. ____ There's other ways using followers for example, but most of them are much more complex in logic and a pain to manage. I had a grid-concept using a combination of pistons, tags and a single follower back in beta, and it would've been much easier to deal with "gravity" movement with this concept, but the controls were not really good. Maybe I should go back and remake that concept too, maybe I could improve the controls, but I don't know.

2011-02-03 21:16:00 Author: Shiwayari Posts: 167

---

It really is LBP1 all over again... here I am, again raiding your cookie jar! Thanks. :hrmf:

2011-02-04 14:18:00 Author: Gravel Posts: 1308

---

I just found a pretty good way to make automated down-movement (gravity) possible with this concept! This is not a solution if you need to have continuos (stepless) down-movement (i.e. you only want to stay on grid in the left/right dimension, while falling down). But for games like tetris where the blocks need to stay on grid in 2D all the time, this should work pretty well. Also, the controls might get a bit chunky if you need really fast down movement, so it's not a perfect solution. It needs a bit more logic though which makes it kind of hard to explain.. The first thing you need to do is make yourself a controllinator that only accepts a single button input a time and also has a short delay after each button press. That delay can be a single Nor-Gate Pulse though. Btw. I tested the frequenzy of the Nor-Gate pulse. It's 15 Hz, so you could press 15 buttons a second. What I did then is I connected a timer that resets itself to the "down" output of the controllinator. So it will output a down signal in intervals equal to the target time. The problem that is left is that the player could do one of these: - Press a button at the exact time that the timer outputs a down signal. - Press a button just before the timer outputs a down signal. - Press a button directly after the timer outputs a down signal. All of these 3 have a possibilty to break the grid alignment. So we need to remove these possibilies. We need 2 Nor-Gate/Counter Pulses for that. You need to adjust the counters target count of the first pulse so that it will take just a tad less time to reach it's target count that the timer takes to reach it's target time. For example, if your timer is 1,0seconds, that would be equal to a target count of 15 (because it pulses with 15Hz). We need a bit less, so we'd set the target count to 14. Now you connect that counter to the input of a second Nor-Gate/Counter pulse. The target count of the second counter should be 3 or 2. (I think 3 is better, but you can try if 2 works for you too) Connect the output of this second counter to a Not-Gate and connect the Not-Gate to the piece of logic that tells your controllinator to only accept one button at a time (I think a Xor-Gate is the best solution for that). These descriptions are always hard to read, so here's a screenshot of the piece of logic needed: http://ic.lbp.me/img/ft/d4c00c249335d8263cc86071ab39d0413f79f07a.jpg The components on the right is the timer connected to the "move down" output. The 2 components on the left are the counters of the pulses; and the Xor-Gate prevents simultanous button inputs (all buttons are connected to it) ____________________________ So what does this all do? Let's assume the player is hammering the buttons nonstop - - The timer activating your "move down" signal starts to count up from 0.0s, while at the same time the counter of the first pulse starts to count up from 0. - The counter reaches it's target count just a tad before the timer fills up. - It activates the second pulses counter, which starts to count up. This will take 3/15 of a second. - While this second counter is filling up, the player will not be able to input any more signals. - The timer reaches it's target count at the time that the second counter reaches count 1. Meaning player input has been disabled for 1/15 of a second; and your object will move one down on the grid. - Player input is still disabled for 2/15 of a second, because the second counter still needs to count from 1 to 3. Luckily 1/15 of a second seems to be enough for the deceleration to finish, so the grid alignment will not break. You can see why controls get a bit chunky for very fast down-movement now: If you want the object to move down for example every 0.4 seconds, player input will be disabled for 3/15( =0.2 ) seconds every 0.4 seconds; which is 50% of the time. Even though this does sound like a lot, the controls are still much better than I would've expected and it's not really a reason to switch to a more complicated grid logic. But try it out yourself. I don't know if I'll add this to the level, because it currently integrated in a much bigger network of logic for the puzzle game and I'd have to extract it somehow, as noone would understand what the important part is with all the other stuff right beside it.

2011-02-05 12:36:00 Author: Shiwayari Posts: 167

---

Hey this was great! I copied it in hopes that I can learn a thing or ... more I did notice in the far right demo (rotating circles), sackboy can't get out of the controlinator. Thanks for the hard work

2011-02-06 13:56:00 Author: Powershifter Posts: 668

---

How do I make it work so that there is a border? I know it's the counters but how do I tweak them to make it work?

2011-02-08 01:16:00 Author: Unknown User

---

How do I make it work so that there is a border? I know it's the counters but how do I tweak them to make it work? There's one counter for each direction. Both counters for left/right should have the same target count. Same for the up/down counters. The target count is the [(border size) - 1]. For example the target counts for a 4x5 grid would be 3 for left/right and 4 for up/down. Now place your object in the lower left corner of your border and set the status of the counters for up and right to be on/filled up (so that it is white) and set the status of the down and left to be off/empty (black). Hope that was understandable, if you haven't already figured it out.

2011-02-08 17:07:00 Author: Shiwayari Posts: 167

---

Awesome, I can't quite figure out how to make it wireless, basically I'm trying to set it up to work on every object that is emitted, unfortunately a tag sensor is my only option and will only allow right movement and up movement, so I'm trying to set it up so left 1 block is L2 and right one block is R2, not bothered about up and down movement, any ideas? to send an analog signal using a tag, wire the output to the tag, and set the tag sensor to [Signal Strength] instead of [Closeness] example: Direct control: [Input Device]-----[Logic] Remote control: [Input Device]-----[Tag] [Tag Sensor]-----[Logic]

2011-02-10 21:51:00 Author: Unknown User

---

To the person wanting a good Wireless signal, I have done as such. The only problem i encountered is that when I placed the Keys and the Key Sensors, the grid alignment distorted. But i managed to repair the situation by moving the Pulse Timers to the VERY end of the signal. Also i have added a little something of my own that might be useful for others. I have created a Single Long Delay before the Repeating Delay in order to make the first initial hold down of the button take longer. For example, You press the button and hold, It moves once, you wait 1.0s (or longer if you desire), it then begins moving every 0.1s (or longer if desired). Everything that i added is in a Red Color in order to better see what i have done. http://i897.photobucket.com/albums/ac176/trinaryatom/SANY0812-1-1.jpg On another note, Thank You Shiwayari, Your help with this logic has inspired me to create something very unique to LBP2 Although it took some effort to understand because i don't know the technical bits, but upon observing it in LBP2 i do believe i understand it efficiently. I'm still alluded by how this stays so precises do to the fact that these LBP games feel like it isn't made precise, in movements. (Due to previous attempts and creations of different factors.) Edit: I am also intrigued with the downward movement logic, I was wondering if its at all possible if you could place it in your [Tech Demo] so that i may get a closer look. Its hard to follow all those fancy words or i should say "technical bits." It's just easier for me to learn through personal involvement. ------------

2011-02-18 02:06:00 Author: TrinaryAtom Posts: 5

---

I don't know why there's problems with wireless signals, I did it like I would for every other piece of logic and it worked without modifications. The only problem is resetting the counters when emitting new objects, but that's not too hard. Said 'puzzle game' I'm working on is about done logic wise now, though there's a few bugs to fix and design to do. The down movement works quite well; I'll see if I can put it into the Tech Demo. I might make a tutorial level out of it cause I got some time now. The controllinator logic is a bit hard to explain though since there's so many components. I'll see how much I can do.

2011-02-18 07:19:00 Author: Shiwayari Posts: 167

---

Okay, HERE's a challenge for any and all of you.. Expanding this model to hexagonal grid movement. Lots of cake for anyone that can figure this out; it's been driving me batty.

2011-02-18 14:21:00 Author: jdteather314 Posts: 74

---

I'd like to give that a try, but what kind of grid and controls do you need exactly? By hexagonal grid i guess you mean something like: _▓ ▓ ▓ ▓ ▓ _▓ ▓ I have some kind of idea, I'll try it later. Edit: Post fixed

2011-02-18 15:04:00 Author: Shiwayari Posts: 167

---

I'd like to give that a try, but what kind of grid and controls do you need? If you just need something like: ▓ ▓ ▓ ▓ Not sure those symbols are appearing correctly to me.. But this is what I mean: http://docs.codehaus.org/download/attachments/153649407/grid_hex_simple.png?version=1&modificationDate=1275477347904 So your possible directions of movement are up, down, and four diagonals.

2011-02-18 15:10:00 Author: jdteather314 Posts: 74

---

Not sure those symbols are appearing correctly to me.. But this is what I mean: <img> So your possible directions of movement are up, down, and four diagonals. Okay, I just finished a version with integrated grid-size ("square"). The hexagonal grid itself (without border) wasn't hard actually, but making the border logic was confusing. Both use a few more pieces of logic, since I had to somehow deal with multiple movers, which is quite annoying most of the time. The concept behind it is exactly the same as with the other grid though. If you need to adjust the border and can't understand how to when looking at that huge microchip, I suggest you just use the borderless version and set up your own border by using tags and sensors. Should be much easier to understand that way, and you can do other borders than square-form . Or you could ask here and I'll try to explain, which might be hard to do with all the wires.. Or you just might understand after looking at it Anyway, I added both to the tech demo level and republished, have a look.

2011-02-18 23:44:00 Author: Shiwayari Posts: 167

---

Re Queued I wonder if you were thinking what i was thinking by adding multiple 'one way movers' and adding more logic into the counters Edit: Well not quite what i was thinking but it certainly gets the job done. At first glance its very intimidating and hard to follow. (You might try to add some notes to areas or items to better explain what they do. After all i cant use somthing unless i completely understand how it works .) But upon close inspection i think i get most of it. I'm still curious about two things. 1-wondering why the movers are set up like they are, yu know, with an on and off input as well as mover input. 2-why is there "And" and "Or" gates on the top middle and all over the bottom. I think i understand "Why" they're there, but its still a little vague and hard to follow. My theroy is that those control the number in the counters. Edit: I wonder if a hexagon "Border" would be easier to logic rather than make a square "Border", if so I'm going to use it.

2011-02-18 23:59:00 Author: TrinaryAtom Posts: 5

---

Re Queued I wonder if you were thinking what i was thinking by adding multiple 'one way movers' and adding more logic into the counters Edit: Well not quite what i was thinking but it certainly gets the job done. At first glance its very intimidating and hard to follow. (You might try to add some notes to areas or items to better explain what they do. After all i cant use somthing unless i completely understand how it works .) But upon close inspection i think i get most of it. I'm still curious about two things. 1-wondering why the movers are set up like they are, yu know, with an on and off input as well as mover input. 2-why is there "And" and "Or" gates on the top middle and all over the bottom. I think i understand "Why" they're there, but its still a little vague and hard to follow. My theroy is that those control the number in the counters. Yeah, I guess it's not easy to follow, I got pretty confused while wiring it up myself. I'll try to explain. 1- The problem when using more than a single mover on the same object is: For advanced movers: if the mover does not have an "off signal" input to it's on/off slot, it will influence the deceleration of the whole object with it's own setting. So if you try to activate a different mover while the other one is -not- turned off, it will move very slow or not at all if the deceleration of the other mover is set to 100%. Simple movers only have an on/off slot, so their deceleration won't affect other movers while they're not moving themself. But this also means that they won't decelerate their own movement after each pulse, so those can't be used. The big Nor-Gates are for turning off those decelerations of all other movers, so that the activated mover will move at all At first I thought I could connect the same input to the on/off that I connected to the vertical input of the same mover.. but that doesn't work because if activated, it will get the signal to move vertically, then be turned off, and so will be the deceleration. It'll just continue to move into the same direction without stopping. I also thought about just adding some delays that keep the mover active for a longer time than it's vertical input is active. That would use much less wires than all the Nor-Gate inputs, but I wasn't so sure about how adding extra delays would affect the controls. 2- The two left Or-Gates on the top middle are there for doing this: __ If: (moving down left) or (moving up left) then: decrement the counter for "left movement freedom", increment the counter for "right movement freedom" If: (moving down right) or (moving up right) then: increment the counter for "left movement freedom", decrement the counter for "right movement freedom" __ The right Or-Gate on the top is used for the part on the bottom, which is pretty hard to explain.. The problem here is that depending on which "column" of the grid you are, up movement can mean that you either "really moved up", or not (In a topological). Same for down movement. With "really moving up" I mean that the distance to the upper edge of the border gets shorter. If I count the columns from left to right as 1, 2, 3, .. then for example you are on column 1 and you can move upwards 3 more times. If you move up-right now, you can still move up 3 more times. If you now move up-right from column 2 to column 3 however, you can only move up 2 more times. (That's all assuming that columns 2, 4,.. are shifted up-right relative to columns 1, 3, ..). The same applies to down movement. So for each left or right movement (which is detected by the right Or-Gate on the top) I used that selector to switch between the status "on uneven column" or "on even column". The right part on the bottom (6 gates) is for checking when to decrement/increment the counter or when not to, depending on which column you are. The lower 3 gates do this for example: __ If: [(on uneven column) and {(moving down left) or (moving down right)}] or (moving down): then: decrement "down movement freedom", increment "up movement freedom". __ The 4 gates on the left handle the "can move" or "can not move" up/down status, which also depends on the column. Upper 2 Gates do this: __ If: (on uneven column) or [(on even column) and (up movement freedom > 0)] then: allow up left/right movement __ I hope that was understandable For setting the border size just place your object on the bottom left corner of the grid, and set both counters above each direction splitter to be on, and both below to be off. Target counts are (size - 1). If the second (counting from left) column is shifted to the upper right relative to your first column, set the initial selector state to 1. If the second columns is shifted to the lower right, set it to state 2. Edit: I wonder if a hexagon "Border" would be easier to logic rather than make a square "Border", if so I'm going to use it. I think that would need similar or a bit more logic compared to the square border. For square border, the counters are handled differently depending on which column the object is on; for hexagonal border it would depend on which part of the grid (left, right, middle) the object is on. (If I didn't miss anything) What you can do for any form of border though, is just use tag sensors and tags, as I mentioned before. That should be very easy to understand and is fast to set up. Here's an example for hexagonal border: Place "direction blocking" tags on each outer piece of your border: http://i3.lbp.me/img/ft/6b37fd0cee6e134d53760d5b78290e10c486a310.jpg And disallow the each movement, when the corresponding tag is detected, by connected the sensors to an extra And-Gate slot: http://id.lbp.me/img/ft/c8d3d2b2c7bf3071c47f2ed6816ff212001a0598.jpg0 It might be a bit ugly for big grid sizes, but tags are pretty harmless to the thermomenter and it's easy to understand and set up, so why not.

2011-02-19 11:39:00 Author: Shiwayari Posts: 167

---

The tags are GREAT! I'm defiantly going to be using those instead. It just seems to be better to follow than the counters. Although the counters can keep it all on one chip, you cant control keeping out the courser in certain locations (within boundaries), without the tags. It feels like I'd have more control with the tags. Not to mention its much easier on the eyes Stick a fork in it! It's Done! (for me) Great work Shiwayari! Now to go work on the rules and game play elements of an upcoming game. Later N Thx!

2011-02-19 18:59:00 Author: TrinaryAtom Posts: 5

---

Shiwayari - Just wanted to say THANKS for all the hard work getting this logic refined so nicely and taking the time to explain and share it all. Such an elegant solution to a potentially vexing challenge. Much obliged for saving the rest of us so much head scratching. All - I'm going to be using it for a square grid game at the moment, but I was wondering if anybody has released anything cool using the hex grid version? I'd love to check it out if anybody has a link to share.

2011-03-28 01:01:00 Author: LittleBigDave Posts: 324

---

Updated to V1.2. This morning I thought I'd try out some ways to get a faster grid movement, and was surprised when the first thing I tried actually worked. It took about 10 Minutes to think of the basics and put it together, I again wonder why I didn't think of something so obvious earlier xD. Only thing is, I only kind of know why it works, if I hadn't tried it, I would've thought it won't be accurate. After various tests however, it seems it's also 100% accurate. Soo; I now have a grid that with movement as fast as a feedback Not-Gate (the fastest recognizable pulse in the game) =D I also added a few extras and notes to the microchip, the actual logic is very small yet again. Time to update the first post. I'll add a few more explanation, so you might want to check back later. Feel free to again try out this new version

2011-04-09 17:07:00 Author: Shiwayari Posts: 167

---

Hi Shiwayari! Thanks for your contributions to the LBP community! It appears I had to re-discover some of the mentioned things here, after getting the required mover settings from tutorials here. Rest I made from scratch, but in the end, I made a similar chip. I use seperate signal blockers for avoiding too fast input and seperate signal repeaters, for example, and it is somewhat inefficient compared to this, but it lets me specifiy a different timer for each direction and different repeat patterns. What I'd like to suggest for the diagonal direction blocking, tho, is that you could be using a selector for diagonal direction blocking, this way, the player would still be traveling if the user was rotating the stick, and not stop at the diagonal directions, it somewhat makes it more user-friendly. I'm using this already and it works a treat.

2011-05-31 20:58:00 Author: hesido Posts: 166

---

Is there any way u could show me a setup of the tag/sensor setup inside a square grid mover. i see how u have it set up for the hexagonal arrangment but i need one for the square version. im trying to attempt Chip's challenge if u know wat that is. Lemme kno

2011-12-07 21:36:00 Author: DarkSeraphim666 Posts: 96

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.