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

[TurBeau]

I cant get this mod working on a server, even on a clean server with nothing but forge and the mod,

Server log:

http://pastebin.com/Nk8huSew

Client log:

http://pastebin.com/it8vasWa

Ive tried multiple forge versions, that doesnt seem to fix the problem. Am I doing something wrong?

[jakj]

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?

I am using real ticks, though. I use a function called updateEntity that is called in the tile entity exactly once per physical game tick pass, and I increment a counter; On the server, when the counter reaches 20, it re-emits all the blocks it had absorbed, and on the client, it uses the counter to say "draw everything ticksExisted/20 blocks offset from their starting position". The rendering function is provided a "partial tick" argument, to make things smooth when the visual framerate is faster than the actual tickrate.

I thought you were saying that the game could be designed to actually run at more or fewer than 20 ticks per second at full speed. If a server is supposed to run at 20 ticks per second but it can't keep up, then the process will take more than one real-world second.

The issue comes at if the server is configured so that at full speed it's only doing, say, 10 ticks per real-world second, and could never get up to 20. In that case, at full speed, every single motion would take 2 seconds instead of 1. If that's the case, I'll have to add a configuration option to say "how many ticks per second is your server configured to run". And I will hate doing that, because I hate how shitty Minecraft is in a server environment, but I won't have a choice really.

[jakj]

I cant get this mod working on a server, even on a clean server with nothing but forge and the mod,

Ive tried multiple forge versions, that doesnt seem to fix the problem. Am I doing something wrong?

No, that's a bug in the current version of my mod. I've already got it fixed and it will work in a server on the next update, which (hopefully) will be before the end of tonight.

[hoho]

I thought you were saying that the game could be designed to actually run at more or fewer than 20 ticks per second at full speed. If a server is supposed to run at 20 ticks per second but it can't keep up, then the process will take more than one real-world second.

Ah, my bad

Though I think mystcraft accelerated ages will still be a source of headace:

"Adds extra random ticks to the world, causing things that occur on random ticks to occur more rapidly."

[jakj]

Ah, my bad

Though I think mystcraft accelerated ages will still be a source of headace:

"Adds extra random ticks to the world, causing things that occur on random ticks to occur more rapidly."

No, that calls updateTick on the block, not updateEntity on the tile entity. Won't be a problem.

Accelerated worlds make happen faster things like leaf decay, fire spread, and grass growth.

[TurBeau]

No, that's a bug in the current version of my mod. I've already got it fixed and it will work in a server on the next update, which (hopefully) will be before the end of tonight.

Ah, that makes sense, Ill be looking forward to that then.

I have some blueprints lying around from 1.4.7 for a flying base. They are drawn based on redpower frames restrictions, but now I can make it look much better. Expect screenshots soon. :)

[Markarthian]

Jakj, have you thought about a replacement for covers or panels? I know about the micro blocks mod, but I liked the way you could disguise a frame with panels/covers: they don't take up a block, they, in a way, retexture a side of the frame.

[jakj]

Jakj, have you thought about a replacement for covers or panels? I know about the micro blocks mod, but I liked the way you could disguise a frame with panels/covers: they don't take up a block, they, in a way, retexture a side of the frame.

Hmm. I could allow you to craft a carriage block with another block, and when it's drawing a closed side, it draws it as the side of that block instead of the normal carriage texture. Open sides would continue to render normally.

[Lethosos]

Might want some means of changing that texture as well. Perhaps re-craft it with an another block to change the closed texture?

[jakj]

Might want some means of changing that texture as well. Perhaps re-craft it with an another block to change the closed texture?

Yeah, all I would do is make a custom crafting handler that says "carriage block + decoration block = carriage block with decoration" and "carriage block with decoration = carriage block without decoration". Easy peasy.

[hoho]

@ covers, IC2 had a recent commit saying "implement forge block coloring api for painters, hardened cf and cables". Assuming "coloring" really means "apply a random texture" then this could perhaps be a better solution

[jakj]

@ covers, IC2 had a recent commit saying "implement forge block coloring api for painters, hardened cf and cables".Assuming "coloring" really means "apply a random texture" then this could perhaps be a better solution

I just looked through the IC2 code, and I don't see any reference to any Forge API, nor is there any Forge commit referencing one. If there is an API forthcoming, it's not in the builds yet. I do see that IC2 is generating some arrays that hold block Id/Meta combinations for retexturing, but it's skeletal, and it's no different than what I would do anyway.

If something good pops up in the future, I can switch to that, but in the mean time, I'm not going to chase after some phantom scent coming out of the "elite inner circle" of developers.

[jakj]

Version 0.1.0.0 is now available (should work on all of local SSP, LAN SMP, and remote/dedicated SMP):

http://j-a-k-j.com/RedstoneInMotion_0.1.0.0.zip

Recent changes (full list in "Changes.txt"):

0.0.2.0 -> 0.1.0.0

 -- fixed a crash on dedicated servers relating to packet classes

 -- all entities (e.g., players, animals, monsters, minecarts, items on the ground) now move with the carriage

 

 

Known issues:

 

A carriage being driven by an engine cannot be moved downward if the block providing the downward redstone signal is part of the carriage.



Blocks affected by gravity (e.g., sand and gravel) that are not part of a carriage fall through that carriage even if that carriage in its new position would support them.



Some modded blocks (like ComputerCraft computers) do not retain their state after motion.



Forge information file (mcmod.info) not yet implemented.



Some blocks in-transit are not yet rendered.



Drives will not work on structure carriages when placed on an edge instead of a corner.

 

Planned features:

 

Crafting carriage blocks with decoration blocks to turn closed sides of those carriage blocks into facades of those decoration blocks.



Native-resolution (i.e., 16x) texture pack.



ComputerCraft support, including carriage drives as peripherals for wired and wireless control.



Omni-Wrench support.

[jakj]

Version 0.2.0.0 now available: Accounted for a bit of lag, added carriage-block disguise functionality, added mcmod.info, fixed an oversight, and added in-transit rendering for almost every vanilla block.

http://j-a-k-j.com/RedstoneInMotion_0.2.0.0.zip

Recent changes (full list in "Changes.txt"):

0.1.0.0 -> 0.2.0.0

 -- entities being moved by carriages should behave a bit better when there is a lot of server-to-client lag

 -- carriage blocks can now be disguised to look like other blocks

 -- ** craft a carriage block with any regular block to set it as the disguise

 -- ** it will let you craft things that look silly, such as with torches, so test first before throwing away a stack of them

 -- ** craft a disguised carriage block by itself to remove the disguise

 -- ** only closed sides will be disguised

 -- ** being disguised will not change the function of the carriage block in any way

 -- ** most of the time, disguised carriage blocks will not stack; this is a vanilla issue and cannot be fixed without a coremod

 -- all vanilla blocks are now rendered in-transit EXCEPT the following:

 -- *) regular, locked, trapped, and ender chests

 -- *) regular signs and signs on walls

 -- *) enchantment tables

 -- *) ender portals and frames of ender portals

 -- *) beacons

 -- *) mob/player skulls

 -- mcmod.info now present

 -- suddenly remembered the need to keep the in-mod version string up-to-date

 

Known issues:

 

Blocks affected by gravity (e.g., sand and gravel) that are not part of a carriage fall through that carriage even if that carriage in its new position would support them.



Some modded blocks (like ComputerCraft computers) do not retain their state after motion.



Fire does not render correctly.



Some blocks in-transit are not yet rendered.



Drives will not work on structure carriages when placed on an edge instead of a corner.



Recipes do not use the Forge material dictionary.

 

Planned features:

 

Native-resolution (i.e., 16x) texture pack.



ComputerCraft support, including carriage drives as peripherals for wired and wireless control.



Omni-Wrench support.

[jakj]

Regarding ComputerCraft compatibility:

As I say, I'm not very familiar with ComputerCraft, so I'm relying on detailed bug reports from all of you, but so far in my testing and looking through decompiled CC, the only thing I can see that is caused by my mod is that the computers/turtles reboot after the carriage is moved. Everything is still in the right place: Turtles still have their inventories and names, their programs are intact, and so forth. If they were off, they stay off, and if they were on, they reboot.

Looking at the code, he has really set up a rather instanced system that is reliant upon the computer rebooting like this: For the same reason, it's designed to reboot if the chunk unloads and is reloaded. It might be possible, with surgical dedication, to reflect my way in there and restore every single variable of state, but that would be so much work and I really think it works better this way anyway.

All you have to do, if you want to have a computer-controlled carriage while the computer is actually on the carriage, is design your startup program to begin with each movement, putting the appropriate control flow in the "startup" program. You could even be crafty and use the fact that you rebooted as a signal that the carriage just moved.

Thoughts? Again, if anyone finds any instance of something in ComputerCraft actually getting corrupted/destroyed by my mod, I really want to know, but if the only issue is computers/turtles rebooting after movement, I think that's alright how it is. (I am open to feedback, though, from people who actually use the CC mod.)

In the mean time, I'm going to begin researching peripheral support.

[Function]

Hey jakj, I'm not sure if your aware or not but I'll state a bug I've found anyways, if you put a Carriage Engine into Continuous mode while standing on the carriage frame your are unable to escape from the frame unless your brake the engine or the lever, but when you break them the carriage frames and the engine disappear. Just thought I'd give a heads up to that one because I didn't see it located in the known issues.

Using version 0.2.0.0

[jakj]

Hey jakj, I'm not sure if your aware or not but I'll state a bug I've found anyways, if you put a Carriage Engine into Continuous mode while standing on the carriage frame your are unable to escape from the frame unless your brake the engine or the lever, but when you break them the carriage frames and the engine disappear. Just thought I'd give a heads up to that one because I didn't see it located in the known issues.

Using version 0.2.0.0

That's because you were still in creative mode: In normal (survival) mode, the block that represents the moving carriage is unbreakable. And yes, if you trigger a continuous-mode engine while you're standing on it and you haven't set up anything to make it stop, it will keep going and trap you. During transit, none of the blocks actually exist, meaning you can't flip levers, you can't break the engine, you can't do anything. This is why you have to explicitly put an engine into continuous mode: It is dangerous.

If you are experimenting with continuous mode, always make sure to put up at least a few dirt pillars around you to stop you if you trigger it prematurely, or even better, try it with continuous-mode motors first, because the motors stay put, and eventually they will run out of carriage to move and will stop.

[Sibbis]

I've started to play with this. It looks really great!

Of course, the first thing I tried to create was a bore.

The main issue I'm having is getting power to the "block breakers" while still having the frame be intact. Is there no way to do this currently?

I'm using the latest version of Applied Energistics, which adds a type of block breaker. The problem is that I need a complete "wall" of frames to attach to the block breakers, but I also need to somehow connect a cable to the block breakers.

So, either AE works, or the Frame works, but I can't figure out a way to get both to work.

AE works:

Frame works:

If there were a Frame Carriage block that made any block immediately above it act like a Frame Carriage block, this would work.

My current workaround plan is to have a ComputerCraft turtle break / place the AE cables and Frame Carriage block as needed, but that's sub-optimal.

So, is there any way to make this work currently? If not, are there any plans in the future that could make this work?

Thanks, keep up the great work!

[Haruspex]

I got a feeling im missing out something really obvious since no one in this thread has occured this issue yet.

The frames/engines/motors just work absolutely randomly. In very rare cases I can move frames once, generally I'm unable to get the frames moving.

The Screenshots show one of many set-ups I tried.

Screenshot 1

Screenshot 2

Why won't the motor switch on?

(Btw: Using Version 0.2.0.0)

Update:

Interesting... After switching it on and off a billion times it suddenly worked. Now I broke it down and rebuild it. Again it doesn't work...

Update 2:

Haha, never mind. For no obvious reason my frames started to work as they're supposed to. Sorry about that. I still wonder why it didn't use to work though.

Great work you're doing there

[jakj]

The main issue I'm having is getting power to the "block breakers" while still having the frame be intact. Is there no way to do this currently?

If there were a Frame Carriage block that made any block immediately above it act like a Frame Carriage block, this would work.

Try using support carriages instead:

Support carriages will treat everything above them but not to the sides as part of the carriage. Notice how I have one extra row of block breakers facing up instead of forward, so it can break the ceiling too. What you'll want to do is a stutter-step pattern: Activate it once, and it will break in front of it and above it. Then, you will need to move the carriage up one block and break again, which will clear the blocks that would otherwise block from moving the upward-pointing block breakers. Then, move it down one block again and move forward.

The only issue you'll have to deal with is falling sand/gravel: You'll need to keep activating the block breakers as sand/gravel fall on them until no more falls on them. You'll also have to deal with water/lava falling on you somehow.

[jakj]

The frames/engines/motors just work absolutely randomly. In very rare cases I can move frames once, generally I'm unable to get the frames moving.

From the screenshots you posted, I don't see anything that is going wrong. Maybe more detailed screenshots or a video?

Common conditions which can prevent carriages from moving:

• The signal isn't direct. Sometimes, simple redstone won't work like you might think: Try a redstone block and see if that does, and if so, you'll need to move your redstone.
  
• Trying to move carriages directly toward or away from a motor.
  
• Forgetting to close the sides of carriages that are touching walls, ceiling, or the ground.
  
• Having more than one carriage touching the drive, or having more than one side of the drive getting a redstone signal, at the same time.
  

[Haruspex]

Thanks for the ideas so far. I believe I obey the rules so far.

Here is a video of my issue.

[jakj]

Thanks for the ideas so far. I believe I obey the rules so far.

Here is a video of my issue.

Thank you for the video: It really helped me to understand what you're doing. However.......what you did works for me. I even tried it while facing different directions in the world, and with different carriage faces open and closed, with redstone blocks and with levers, and it all worked.

The only thing I can suggest now is maybe there's a conflict or corruption somehow? If you try it with a brand-new world, does it still fail? If you try it with no other mods installed except Forge, does it still fail? Which version of Forge are you using? Does your log file ("ForgeModLoader-client-0.log") have any errors in it? (Sometimes it prints out errors that don't actually crash Minecraft.)

[Haruspex]

The Logs don't contain anything interesting.

A new, empty world did not bring any advantages. However on maincraft without any mods it seemed to be working fine.

I manually added railcraft to my tekkit. I removed that mod now and there we go - your mod seems to be working perfectly fine on a new map on tekkit. So apparently there is a conflict with railcraft - tough decision i have to make now ;)

[theprolo]

Could be those buggy, useless trail blocks which break *Everything*.

They're probably connecting your frames to the ground in their eternal useless crappiness.