Archive: 18 posts

---

How about a mover that we that we could use to move our element by desired amount of distance, relative to the objects initial location at the time of the activation of the "Relative Mover"? The relative mover would have an output, so when the destination is reached, it will activate its output, much like a movie camera, and disable it as soon as it receives another activate signal. This way, we could precisely know if the target is reached with simulation frame accuracy. This would have serious advantages over advanced mover solutions for ultra precise movement: 1) No falling out of grid, ever, even at high frequency inputs. 2) Smooth motion or very fast motion (as fast as the game allows) to the target, and there wouldn't be any need to use followers to adjust motion speed to go to a desired relative location. Not using tags and followers would allow us to use several emitted objects without breaking each other's movement because of tag name collisions (I also had a proposal to prevent tag name collisions a few days ago, tho!)

2011-06-23 22:52:00 Author: hesido Posts: 166

---

Aren't pistons work that way? thru they dont have output but you could sync it with timer or use tag

2011-06-23 23:06:00 Author: Shadowriver Posts: 3991

---

Aren't pistons work that way? thru they dont have output but you could sync it with timer or use tag Pistons need to be physically connected, would they allow unlimited movement within the level for emitted objects? For example, I want to go 30 units left, then another 30units left, and then 30 units down, and maybe based on elements around, I want to go 120 units upwards etc etc. And I want to be able to do this for hundred objects in level. edit: The above is already possible through emission of objects with tags, and have the object follow the emitted object. But we can't know if target is reached with frame accuracy (we don't know if the target is reached for sure within a frame, we can only make by relaxed timing, but it is not the same as precisely knowing if target is reached), and since we cannot create isolated tag/follower systems (https://lbpcentral.lbp-hub.com/index.php?t=58086-Dynamically-generated-tag-names-using-keywords), it is not possible to use this for multiple emitted objects without renaming each tag/follower by hand, which defeats the purpose.

2011-06-24 07:53:00 Author: hesido Posts: 166

---

Grid-like units and movement according to these units is a necessary feature that should be integrated into LBP 2. This way, speed of objects and the distance to be covered in a given amount of time can be calculated accurately. Additionally, this would eliminate all the problems with falling out of grid (at high speeds)...

2011-07-02 08:54:00 Author: terbas Posts: 93

---

The relative mover would have an output, so when the destination is reached, it will activate its output, much like a movie camera, and disable it as soon as it receives another activate signal. This way, we could precisely know if the target is reached with simulation frame accuracy. Sounds like you could do this with one of the existing movers, and a bit of logic, unless I'm misunderstanding. What's the intended application?

2011-07-02 23:33:00 Author: Aya042 Posts: 2870

---

@Aya: That was just an addition to the "relative mover" suggestion, and wasn't meant to be the main idea, that will be something possible through speed sensors or your really ingenious solution using followers. (Although, when using followers, you may have to deal with tag naming collisions that I'm quite obsessed about) The main idea is to be able to move to a relative destination precisely, slowly or instantly , without the limitations of advanced movers (which may overshoot at times of high thermo and local complexity, and for smoother movement, it should be coupled with followers: set target than move to it) and follower / tag combinations, which has naming collisions. I may be able to emit 100 objects that can set its own destination based on the decisions the object makes according to its surroundings, and move to that destination without having to use advanced movers or follower tag combos. The output thing was to make sure you don't give a new order until the movement is complete, which can be achieved using speed sensors (official, or your method), but it would be even more precise if the mover itself let us know. But that wasn't the main issue.

2011-07-03 00:48:00 Author: hesido Posts: 166

---

The main idea is to be able to move to a relative destination precisely, slowly or instantly , without the limitations of advanced movers (which may overshoot at times of high thermo and local complexity Strange. I've had no problems with using timed pulses on Advanced Movers to move an object by a fixed distance every time.

2011-07-03 01:26:00 Author: Aya042 Posts: 2870

---

My experience with current movers is that you can't depend on their accuracy. Do a hundred iterations back and forth, and you'll see that the object has slightly drifted, which is a game breaker if you require precision. At least that's what I've seen. Also, setting a time / mover strength combination is not intuitive to begin with (go at 14.4 kilometers / hour for 100 seconds to stop at the candy shop or go 400 meters to stop at the candy shop) For a set target like a candy shop, the best way would be to set a tag. But if you want arbitrary locations (200 units to the left of the object) etc etc, you could set targets by emitting the tag to be followed, but since every object has its own "200 units to the left", you could run into problems. A mover that takes the object to a set units to any direction upon activation, with respected to the position at time of activation, would solve so many problems, and would be so easy to use, that the idea is hard to pass.

2011-07-03 09:38:00 Author: hesido Posts: 166

---

This sounds like a good idea. One problem, though, is being able to determine the starting point when editing the Mover. How do you keep it fixed within a specific range in the level? If you activate it a second time, it might just move that set distance again. I think this idea needs an added element, an anchoring point to use as reference. You set the range of the anchor point and the Mover cannot move outside its range. The object itself can extend beyond the range of the anchor, but you can work around that by placing the Mover on the edge of the object. Or, maybe the object's edges can also be restricted to the anchor range?

2011-07-03 20:31:00 Author: Brandon Posts: 106

---

My experience with current movers is that you can't depend on their accuracy. Do a hundred iterations back and forth, and you'll see that the object has slightly drifted, which is a game breaker if you require precision. Confirmed, although that's almost certainly due to cumulative error in floating point arithmetic. The same problem would occur with your "Relative Mover" idea. An "Absolute Mover" where you could specify absolute coordinates might work better. You could probably fake something up with a Tag Sensor and a feedback loop, akin to the example in this post (https://lbpcentral.lbp-hub.com/index.php?t=52710-need-a-solution-for-analouge-movement-of-geometry&p=803614&viewfull=1#post803614). You'd effectively end up with a chip which you can input analog X and Y coordinates, and the attached object will move to those coordinates. By limiting your mathematical operations on those signals to numbers which can be precisely expressed in IEEE754 (http://en.wikipedia.org/wiki/IEEE_754-1985), you can completely avoid the cumulative error which you get with a typical mover setup. ...in theory.

2011-07-03 21:11:00 Author: Aya042 Posts: 2870

---

I think a Grid Mover would be a more useful tool. Similar to the principle described above, in the options of the mover you could set the following: 1) movement Domain (-infinite to +infinite) 2) movement Range (-infinite to +infinite) (The above two would effectively determine an object's movement distance along the x and y axis) 3) movement speed 4) grid units (small, medium, large) -the same as the grid used every day in create mode 5) on/off, one shot, and speed outputs 6) if set to one-shot, you can set a frequency delay between movement, like you can for emitters 7) local space option

2011-07-03 21:32:00 Author: synchronizer Posts: 287

---

@Brandon: The end result of this mover would be the same as this, but without the actual tags: *You have an emitter that emits a tag, say, 5 big grids away. *The tag is emitted. The object has a follower that follows the tag. *The object reaches the destination. During the motion, the mover doesn't receive new input, much like you cannot have 2 advanced movers active on the same object. You would be able to have multiple relative movers on the same object, but no two of them could be handling the motion at any given time. It would be the authors responsibility to keep the object within game area, much like current movers. But all this will be done using without tags. I just want to get rid of having to use tags. @Ayneh: If when active on an object, our relative mover positions the object so that there's no rounding errors, and if the unit it uses also adhere to this, would we still have problems? I mean, 30 units could mean one big grid. We could tell it to go 1 units, but not 0.56 units. The input of mover could just be on-off, to prevent rounding errors, or it can internally use only "rounded" units, and it could snap the object to the nearest position units when it gets activated.. It would be the same as, like I mentioned earlier in this post, emitting an object 5 grids away from initial position, and reaching there, like we have moved the object by hand using a grid. Since only one such mover could be active at any time, the second input to the mover or a different mover for a different direction could only be given after the prior move has ended, thereby avoiding cumulative errors. Only the grid this mover uses would be more precise (A big grid could consist of 30 units, for example. Whatever scheme that doesn't cause rounding problems.) My single peeve is avoiding the use of tags for the job. But I'll try a solution that tries to reduce the naming collision problems when several emitted objects are involved. The system works in my mind, but it is untested, and it could be very thermo intensive. Or maybe you already have a solution for it

2011-07-03 21:48:00 Author: hesido Posts: 166

---

If when active on an object, our relative mover positions the object so that there's no rounding errors, and if the unit it uses also adhere to this, would we still have problems? Depends on LBP's internals - couldn't say without reading the source code. TBH, the drift is pretty marginal - I really can't imagine it being problematic in most cases. Are you sure your problem isn't a timing issue? How are you generating your pulses, and what are you doing to avoid pulse overlap?

2011-07-03 22:19:00 Author: Aya042 Posts: 2870

---

@Aya On my end, the drift wasn't so marginal, so I'll do more tests to make sure it is not a timing issue, and let you know here.

2011-07-04 06:03:00 Author: hesido Posts: 166

---

as soon as i saw this i thought: " hay, what if we could plot connected points along the screen a lot like dot to dot and then the object with the mover on moves along the line" this would be brilliant. slightly off your idea.

2011-07-04 21:32:00 Author: nerzdadestroyer Posts: 1527

---

I think Rails would be a cool new connector that instead of bolting objects to each other or tying them together, you place rails on one object and another object in front of it can follow the rail. Combined with Hologram, you can create fixed paths for objectes to follow.

2011-07-04 21:41:00 Author: Brandon Posts: 106

---

Technically that can already be done. Except instead of a rail it's just controlled by the two points it supposed to go to. You can change directions by tag and a selector.

2011-07-04 22:15:00 Author: Phazerz123 Posts: 440

---

as soon as i saw this i thought: " hay, what if we could plot connected points along the screen a lot like dot to dot and then the object with the mover on moves along the line" this would be brilliant. slightly off your idea. Actually, similar to your idea has been mentioned on getsatisfaction.com: http://getsatisfaction.com/littlebigplanet/topics/path_tool_and_pathfinder He suggests using path finder to snap to paths, but my suggestion on that particular thread involves a "path emitter" so an emitted path we have earlier drawn could be emitted relative to the object position, and only that particular object would follow it. If such a tool was added, the relative mover suggestion becomes almost unnecessary. However, adding a relative mover would be much easier, IMHO.

2011-07-04 22:21:00 Author: hesido Posts: 166

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.