[1.6.x/1.5.x] Redstone In Motion (Redpower Frames) 2.3.0.0 (October 8)

[jakj]

placed a motor on my smp test server and I got instant a kick with EndofStream and console says only:

15:01:17 CONSOLE: [information] java.lang.NullPointerException

15:01:17 CONSOLE: [information] at net.minecraft.network.packet.Packet.func_73281_k(Packet.java:129)

15:01:17 CONSOLE: [information] at net.minecraft.network.packet.Packet.func_73266_a(Packet.java:192)

15:01:17 CONSOLE: [information] at net.minecraft.network.TcpConnection.func_74459_h(TcpConnection.java:204)

15:01:17 CONSOLE: [information] at net.minecraft.network.TcpConnection.func_74451_d(TcpConnection.java:555)

15:01:17 CONSOLE: [information] at net.minecraft.network.TcpWriterThread.run(SourceFile:115)

so there is no crash or crashlog so :/

Interesting. I was able to track down what caused that, but now I'm confused as to why it works with the integrated server: Looking at the code, it *should* fail there too, but doesn't.

Anyway, it'll be fixed in the next release.

[jakj]

Between tonight and tomorrow I'm implementing entities like players being carried with the carriages. I have a method in mind already, but it would be helpful if you could describe redpower's glitches or flaws when it came to moving the player, so I can watch out for and test for that behavior.

[TheBytemaster]

So, one interesting quirk I found for moving players is that you slide if standing on top of a moving frame, (which is fine), but you move along with the frame platform if you are less than or equal to one block away from a block that is moving and is raised. So, like this.

X-*----

XXXXX

Where is a moving block, * is the player, and - is empty space. If this structure is moved to the right, the player will also move to the right. If the raised block is taken away, the player will remain in place until the platform is pulled out from under them. This also works with dropped blocks, mobs, etc.

[jakj]

That's about what I expected, and it will be in line with my method, except I'm just going to do a simple cuboid bounding box around the entire structure plus a margin instead of trying to figure out exactly what little bits should and should not be considered "on" the carriage. I don't really think that will be disruptive.

[TheBytemaster]

That's about what I expected, and it will be in line with my method, except I'm just going to do a simple cuboid bounding box around the entire structure plus a margin instead of trying to figure out exactly what little bits should and should not be considered "on" the carriage. I don't really think that will be disruptive.

So, entities inside of the moving structure will all stay in place relative to the structure?

That sounds much better than having all entities sliding into the walls when I move my base.

[jakj]

When the drive has determined the motion is valid and pulls the blocks out of the world, it will retrieve a list of all entities (players, mobs, floating items, carts...) in the cuboid region enclosing whatever shape the carriage happens to be (plus a small margin) and their current position. Each tick, it will manually reset the position of each entity 1/20 of a block in the motion direction, leaving its orientation untouched so it can still turn. At the end, the final tick will set all entities exactly one block from where they were.

[TheBytemaster]

When the drive has determined the motion is valid and pulls the blocks out of the world, it will retrieve a list of all entities (players, mobs, floating items, carts...) in the cuboid region enclosing whatever shape the carriage happens to be (plus a small margin) and their current position. Each tick, it will manually reset the position of each entity 1/20 of a block in the motion direction, leaving its orientation untouched so it can still turn. At the end, the final tick will set all entities exactly one block from where they were.

So, entities can't move on their own while the drive is going?

[jakj]

They can turn, use tools, attack, and do all the other normal things, but their position will be locked to the carriage for its one second of motion.

[TheBytemaster]

They can turn, use tools, attack, and do all the other normal things, but their position will be locked to the carriage for its one second of motion.

I see. Is there any way you could just increment the x/y/z coordinate of all entities once per tick in the same direction of the carriage to allow for movement?

[Spaceshipable]

why should the entity be locked to the carriage? Surely you will be adding 1/20 of a block to the correct ordinate every tick rather than teleporting them to a new co-ordinate?

So the loop would find the current position of the entity with each iteration and then add 1/20th of a block to that as opposed to finding the initial position and then adding 1/20th of a block 20 times.

[Spaceshipable]

you should make the loop find the entity position with every iteration and add 1/20 of a block to that instead of finding the initial position and then adding 1/20 of a block 20 times.

[TheBytemaster]

why should the entity be locked to the carriage? Surely you will be adding 1/20 of a block to the correct ordinate every tick rather than teleporting them to a new co-ordinate?

So the loop would find the current position of the entity with each iteration and then add 1/20th of a block to that as opposed to finding the initial position and then adding 1/20th of a block 20 times.

I suppose that depending on how he's assembling the list of entities to be moved, that would allow you to jump out of the structure while it's moving and still be moved sideways a block. Quirky, but not too bad.

Rebuilding the list every tick would probably be rather stupid though.

[TheBytemaster]

you should make the loop find the entity position with every iteration and add 1/20 of a block to that instead of finding the initial position and then adding 1/20 of a block 20 times.

I wonder how much overhead that would add. Probably not too much, but it might be noticeable with lots and lots of entities.

[jakj]

If I just apply a delta to current position per tick and a cow behind a fence decides to walk toward the fence in the direction of motion, it could put them in the fence and out the other side. The only alternative would be to use the builtin entity code for player or ai motion that checks for this stuff, which would add a lot of overhead with a lot of creatures present.

[TheBytemaster]

If I just apply a delta to current position per tick and a cow behind a fence decides to walk toward the fence in the direction of motion, it could put them in the fence and out the other side. The only alternative would be to use the builtin entity code for player or ai motion that checks for this stuff, which would add a lot of overhead with a lot of creatures present.

Ah. I see. Didn't think of that. ...Wouldn't your phantom blocks take care of that though? I'm not sure I understand what's going on anymore, could you give us a cronological list of what happens in a move?

[Spaceshipable]

ahh I understand. You would have to include a fail safe that prevents a delta (1/20 of a block?) movement pushing an entity into an occupied space.

[Spaceshipable]

Ah. I see. Didn't think of that. ...Wouldn't your phantom blocks take care of that though? I'm not sure I understand what's going on anymore, could you give us a cronological list of what happens in a move?

If the entity is moving 1/20 and also moving in the direction of motion then they could move more than 1/20 and end up inside a block unless their movement in just that direction was stopped.

[TheBytemaster]

If the entity is moving 1/20 and also moving in the direction of motion then they could move more than 1/20 and end up inside a block unless their movement in just that direction was stopped.

I know, but what I'm saying is that collision should kick them back the way they came if they only move 1/20th of a block into the block, kind of like how if you stand under falling sand, it kicks you into an open space if available when the entities turn back into blocks. I suppose you could avoid this entirely if you just prohibited movement in the same direction as the platform in some way.

A compromise between the two could be to set the position of only the axis that the carriage is moving on. That way you could still move sideways... right?

[jakj]

It's a little complicated for me to explain why the "pushes you out of blocks you're coincident with" effect wouldn't be sufficient in this case, so let me just put that idea out here. For the purpose of this, let there be two kinds of entities: Living and non-living.

Non-living entiies are easy: Either they're stationary, like floating items dropped on the ground, or they can simply be frozen to the ground, like minecarts. These I can just hold where they are and apply a delta. Minecarts cannot be allowed to keep moving along tracks during motion because those tracks do not exist during motion.

Living entities are players, monsters, animals, and such, that can move non-deterministically under their own power. For these, there exists a function already that effectively says "try to move by dX/dY/dZ but check for collision and other such stuff", which sounds like what we want, but then again, that function *also* takes into account things like the slowing effect of underwater. So if I use that function but the player activates the carriage while swimming, they are going to be moved too slowly and could end up embedded in a block opposite the direction of motion. If I simply increment the delta nd the player/animal/monster is moving in the same direction, they could get pushed too fast into a block.

Now, what I could do is rip code out of both functions, the simple position-setter and the full movement-handler, and make a custom one that only does the collision checking. This is an option.

But the thing I really want to ask is, would it even be necessary? That's even more processing occurring for motion that lasts for only one second, especially when you take into account the delay between client and server. Can you give me any exemplar scenarios of where being able to move around during one second of motion would be useful, keeping in mind that the only restriction being proposed is on the position, not the orientation or the action (so you can still turn around and do stuff, just not to the carriage because that's only a ghost)?

[TheBytemaster]

[but the thing I really want to ask is, would it even be necessary? That's even more processing occurring for motion that lasts for only one second, especially when you take into account the delay between client and server. Can you give me any exemplar scenarios of where being able to move around during one second of motion would be useful, keeping in mind that the only restriction being proposed is on the position, not the orientation or the action (so you can still turn around and do stuff, just not to the carriage because that's only a ghost)?

[jakj]

That keeps coming up, and I think I'm going to have to address it at some point. I may have to actually add some form of Ugocraft functionality eventually.

As it stands right now, though, it's true that you could put a drive in continuous mode and set the thing off on its way, but there's no way to control it after you do: You can't adjust it mid-transit because all the blocks are ghosts. If you're using ComputerCraft to control it (once CC is implemented, of course), then you're not going to be riding it for extended periods, because you can't interact with the computer while it's moving and the computer can't run while it's moving, so likely you wouldn't be riding it in the first place.

Right now, continuous mode is designed for the smooth motion of the carriage over a predetermined distance, or setting up loops, or whatever. If you really want to use it as an airship/ufo/whatever, you're going to want to control it step-by-step. And in that case, I just don't think free motion while riding would be useful.

If I ever were to include functionality like the old airships mod or ugocraft, then absolutely you would be able to move freely, but the amount of work that would take would be fucking insane. I could not even use placeholder blocks: It would have to be a free entity, and I would have to implement my own AABB collision detection transformed by the motion of the ship and apply it to present entities manually, and I would basically have to write an entire set of scripts for every single does-something-interesting mod block to reimplement its features during motion (because it would not exist in block+tileentity form during motion).

(In short, there's a very good reason that Ugocraft supports only vanilla. )

For right now, I'm going to implement the motion as described, such that it locks you to the motion of the carriage but leaves you free to turn and act. I'll let you guys test that and see how it feels, and if you still think that is not acceptable, I'll listen to your feedback and go to plan B.

I'm going to work on the next update a little bit tonight and more tomorrow; Hopefully it will be released before the end of tomorrow night if I don't have to stay late at work. I have another nice free weekend coming up, though, so it'll be a nice chunk of coding.

[TheBytemaster]

Right now, continuous mode is designed for the smooth motion of the carriage over a predetermined distance, or setting up loops, or whatever. If you really want to use it as an airship/ufo/whatever, you're going to want to control it step-by-step. And in that case, I just don't think free motion while riding would be useful.

Continuous mode? Well, that sounds interesting. How possible would it be to have some sort of plugin for computercraft that allows it to directly interface with adjacent carriage blocks and set up a continuous movement of X blocks?

For right now, I'm going to implement the motion as described, such that it locks you to the motion of the carriage but leaves you free to turn and act. I'll let you guys test that and see how it feels, and if you still think that is not acceptable, I'll listen to your feedback and go to plan B.

I'm just glad that you're still taking me seriously after all the stupid ideas I've had.

I should really get back into java and learn to mod so I can contribute more to the community.

[hoho]

Each tick, it will manually reset the position of each entity 1/20 of a block in the motion direction, leaving its orientation untouched so it can still turn.

What if server/world is running at other tick rate than 1/20?

[jakj]

Continuous mode? Well, that sounds interesting. How possible would it be to have some sort of plugin for computercraft that allows it to directly interface with adjacent carriage blocks and set up a continuous movement of X blocks?

That won't be a problem. Continuous mode is for normal redstone, meaning it keeps being activated by the same redstone signal instead of requiring pulses, so if you screw up, your creation will keep going off into the wild blue yonder until you either catch up to it and make a pillar in its way or it reaches the sky limit.

For computercraft, it'll most likely be a simple "move in direction X by Y blocks and tell me when done".

What if server/world is running at other tick rate than 1/20?

You can do that? Shit. Well, I guess I'll have to handle that eventually too. I can't give a rat's ass to actually play SMP, though, so you'll have to link me to some sort of documentation that tells me how the game can be configured to run at a different tickrate so I can start figuring out how it's handled.

[hoho]

You can do that? Shit. Well, I guess I'll have to handle that eventually too. I can't give a rat's ass to actually play SMP, though, so you'll have to link me to some sort of documentation that tells me how the game can be configured to run at a different tickrate so I can start figuring out how it's handled.

I don't have any documentation to give you but even in my SP world I've had times when my CPU is loaded enough to drop the tickrate to <20. I think there are mods out there that allow configuring tick rate as well but I've never used any of them.

But why not just use actual ticks instead of real-time? Instead of needing one second to move one block just require 20 ticks to pass. Though I'm not quite sure how it would work in SMP environment where rendering and world simulation is done in different machines and probably not synced every single tick. Perhaps just use floating average of tickrate over past few seconds for client-side animation?