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

[Pontiac_Firebird]

Darn to old of a version to work with the mods that use Multipart. Oh well, I shall wait.

Thanks for answering =)

If you get the Project Red source off of github you can change the build.xml file to say

    <property name="mc.version" value="1.6.2" />

    <property name="forge.version" value="9.10.1.871" />

    <property name="ccl.version" value="1.0.0.32" />

    <property name="ccobf.version" value="1.0.0.15" />

    <property name="ccc.version" value="0.9.0.5_d2" />

    <property name="fmp.version" value="1.0.0.166" />

    <property name="nei.version" value="1.6.1.4" />

    <property name="tcons.version" value="1.4.7d12" />

and build a version that works. mine had an issue downloading a few of the files so i had to download them myself. So far it has worked fine.

[jakj]

UPDATE ON MULTIPART SUPPORT

So, it turns out, it wasn't actually the change in Multipart at all. It was a change in Forge. So to get it working, you need to downgrade Forge, not Multipart. Derp. That was an hour-long debug session!

Anyway, I'll fix it. Bugfix patch will be out today, maybe with some small new features sprinkled in if I get time.

EDIT: Yeah, fixed it in 40 fucking seconds. Ugh, ChickenBones is right: I need to start using a proper debugger. One hour of debugging, one minute to fix bug...heh.

[jakj]

Multipart works fine now (other than the already-known issue with scheduled ticks for subparts) and some crashes gone.

2.3.0.0 - MC 1.6.x

https://www.dropbox.com/s/iriq2spgf4vblo8/RedstoneInMotion_2.3.0.0_mc1.6.zip

http://j-a-k-j.com/RedstoneInMotion/RedstoneInMotion_2.3.0.0_mc1.6.zip

2.3.0.0 - MC 1.5.x

https://www.dropbox.com/s/0tgr1vl7rsnwzxo/RedstoneInMotion_2.3.0.0_mc1.5.zip

http://j-a-k-j.com/RedstoneInMotion/RedstoneInMotion_2.3.0.0_mc1.5.zip

RECENT CHANGES (full list in "Changes.txt"):

2.2.0.0 -> 2.3.0.0

 -- fixed typo in config file ("BlockIds" -> "Block IDs")

    ** YOU NEED TO CHANGE THIS MANUALLY BEFORE RUNNING THIS UPDATE

       ## if you do not, the block IDs will reset to the default ones

       ## in your config file, look for the line that says this -->      BlockIds {

       ## change it to this -->      "Block IDs" {

    ** (sorry for the inconvenience, but I am way too anal-retentive to leave that wrong now that I noticed it)

 -- fixed bug with multipart blocks disappearing due to a change in Forge

    ** all version combinations of multipart/forge should work now

       ## subpart tick scheduling still isn't handled correctly though

 -- fixed bug with rendering template ghosts that span more than one chunk

 -- eliminated the caching of world objects for loaded translocators

 -- improved in-transit rendering of translucent things like liquids

 -- removed legacy conversion of item forms of decorated carriage blocks and labelled translocators

 -- redid the packet code to use tag compounds

 -- added slightly more redundancy to rendering code

KNOWN ISSUES

*-*-* THINGS THAT ARE BUGS THAT WILL DEFINITELY BE FIXED *-*-*



Multipart blocks that need scheduled world ticks (such as buttons that need a tick to pop back out) aren't receiving their ticks properly.



*-*-* THINGS THAT ARE FLAWS THAT WILL HOPEFULLY BE FIXED AT SOME POINT *-*-*



Anything that already uses a display list to render will not properly render in-transit.



When translocated, some entities (especially chest-carts) behave strangely, but nothing major (so far).



*-*-* THINGS THAT ARE NOT BUGS BUT HOPEFULLY WILL EVENTUALLY BE FIXED *-*-*



Portal spawners from iChun's "Portal Gun" mod do not yet work on carriages. Try finding some way (possibly using additional mods) to activate a portal gun directly instead.



"Billund" blocks have been reported to be wonky when moved by carriages.



Anything else that caches 'x/y/z' values for any reason (possibly some chunkloaders, likely anything that does teleportation) has a strong chance of misbehaving. These should be reported to me as bugs.



*-*-* THINGS THAT ARE NOT BUGS THAT PROBABLY WILL NEVER BE FIXED *-*-*



If you are using Optifine and get an error with the word "ConnectedTextures" in it, either disable connected textures in Optifine or disable/remove Optifine.



ComputerCraft programs that are carried by carriages and interact with the carriage's drive, need to have a delay added to their "startup" program to give time for things to settle before trying to interact again. Try "os.sleep(0.1)", and increase that number if it still doesn't work. (The more overloaded your machine or Minecraft is at the time, or the more computers or turtles you have on the same carriage, the higher this number will need to be. Making the number higher than it needs to be is fine: Too much won't hurt, but too little will.)



Computers on carriages that are running at the time of motion will reboot after motion, and run their 'startup' program. (Computers that are off at the time of motion will remain off.)



If a carriage is moving continuously, and the continuous-mode delay is set to 0, tile entities (like chests) will not render properly after the first motion until the carriage stops. This is purely cosmetic, and does no harm. To prevent this, make sure the continuous-mode delay is greater than zero. (The more Minecraft, your system, or the server is overloaded, or the longer delay there is between you and the server, the higher this number will need to be.)

PLANNED FEATURES

*-*-* THINGS HIGH ON THE PRIORITY LIST *-*-*



Redoing translocator labels and other things to use a GUI instead of trying to draw on the block.



An optional "hardcore" mode involving tiered crafting and power consumption, for people who want this mod to be expensive to use.



*_*_* THINGS TO BE WORKED ON LATER *-*-*



The ability to prevent individual blocks/items from being registered.



A config option to let a carriage treat blacklisted blocks as simple obstructions instead of completely aborting the motion.



The ability to selectively whitelist/blacklist blocks in-game for each drive, in addition to the overall config-file blacklist. These blocks will always be treated as simple obstructions instead of completely aborting the motion, regardless of the setting in the config file.



A form of "sticky carpeting" to allow finer control over where on a carriage entities are grabbed.



Different styles of controlling player position during carriage movement, to try to allow more freedom.

[ShutEye]

Cool! With this update I can now move my server to MC1.6.4

Thanks! :)

[jakj]

Cool! With this update I can now move my server to MC1.6.4

Thanks!

Remember to back things up and test them first. I never play on servers so SMP is the weakest part of the mod (though in theory it shouldn't be since singleplayer is basically local SMP).

[ShutEye]

Remember to back things up and test them first. I never play on servers so SMP is the weakest part of the mod (though in theory it shouldn't be since singleplayer is basically local SMP).

Thanks for the warning and don't worry. Backup runs every other hour and I make a special "pre-major-update"-backup before i start to update mods/MC itself.

So far no problems with this version ... :)

[Mon732]

Hi I am using a custom made modpack and have come across a problem with your carriages and a mod called Project Red (PR).

When any of PRs wires and logic gates are moved using a carriage they will vanish once the carriage settles. Relogging does not seem to make them reappear and blocks can be placed as normal with no crashes.

The only exception to this is the Timer and State Cell, when they are moved by a carriage I crash.

So far I have only tested with Frame Carriages and a Carriage Engine.

If you need anything else then please ask.

Crashlogs:

https://dl.dropboxusercontent.com/u/44022905/RSIMnPR/ForgeModLoader-client-0.log

https://dl.dropboxusercontent.com/u/44022905/RSIMnPR/crash-2013-10-08_20.03.09-client.txt

Project Red Thread: http://www.minecraftforum.net/topic/1885652-forge-multipart-164-project-red-an-rp2-replacement-v40310-9302013/

[jakj]

Try using today's update: I put in a fix for a change in Forge that was causing blocks to prematurely process after being put down but before being fully restored. It was causing Multipart blocks to disappear, so it could be the same problem.

[dwwojcik]

Project Red uses Forge Multipart, so that was likely the problem.

[Spaceshipable]

What about a "jump" motor? Give it a cc command with a direction and distance and it translocates itself and the carriage as if it had a pair the appropriate distance away. Limit it to 256 blocks per jump and it could do drops no problem and go NSEW without going outside the player loaded chunk range.

I really like this idea.

[jakj]

I really like this idea.

Oh yeah, I forgot to add that to the planned features. Thanks for reminding me.

[TheBytemaster]

I really like this idea.

Me too. I can think of many great builds for that, not least of which involves big-burly-bunker-busting-bombs for burning big-walled-bases.

Which of the 4 ways to do it do you think are best?

[jakj]

Me too. I can think of many great builds for that, not least of which involves big-burly-bunker-busting-bombs for burning big-walled-bases.

Which of the 4 ways to do it do you think are best?

I'm going to do it the simple way, where it is directed to teleport a particular distance along a particular axis, and it will check that exact spot as if there were a receiving translocator there. It won't "fudge it" to try and fit nearby, but it will teleport through walls.

Since I've changed my no-GUI policy, it will be easy enough to simply set an upper limit for the distance (a flat maximum in the config file for normal mode, or dependent upon tier for hard mode) and allow precise specification of any number of blocks up to that limit.

[TheBytemaster]

I'm going to do it the simple way, where it is directed to teleport a particular distance along a particular axis, and it will check that exact spot as if there were a receiving translocator there. It won't "fudge it" to try and fit nearby, but it will teleport through walls.

Now that I think about it, that's probably the most balanced/precise solution. If you're going to mess about with teleporting, I suppose precision should be required.

Like in programming, It's better to have an operation fail out and tell you rather than continue on in a messed-up state, right?

New question/brain dump time. Will teleportation using this drive be allowed in multiple axes at once or only one at a time?

To me, multiple at once seems like it could be more convenient, but only one at a time, (setting a direction and punching in a number via GUI, or setting both as arguments in a computercraft command), seems like it would be an interesting balance for the ability to teleport without a tether, and would make things way simpler overall. Maybe that should just be a limitation on lower-tier tele-drives? (Trans-drives? Warp drives? Line drives?)

Also, will they be controllable via computercraft ala carriage controller?

[jakj]

Joint-axial translation is a possibility; The coding would be fairly trivial. As long as it never involves actually rotating the blocks (either individually or as a set), then it's 3rd-grade mathematics. Computercraft control will be available for these and for translocators eventually; Got to decide how, since my code right now works well but is pretty frickin' twisted so a refactor would be good.

Really, I would have preferred to have computercraft baked into each block directly instead of as a separate block, but there are several complications with that. One option would have been to have two releases, one with CC and one without, but that would have been a massive pain in the ass, and I'm not even going to try. Another option would have been to have duplicate classes in the single mod that get selected between at runtime, but that's actually more annoying to code than separate releases, rather than less. The newest version of forge actually has a neat feature that can strip interfaces away at runtime that would do exactly what I want with no fuss, but that would mean dumping support for everything before 1.6.4 and pretty much every modpack on the planet, so...eh. It's unfortunately a limitation in the Java classloader that you can reflect fields and methods but not classes conditionally.

I'm probably going to just redo the whole thing for 1.7 anyway, since it's only about a 3% chance I'll be able to maintain it alongside the 1.5/1.6 version. (That doesn't mean I dump 1.5/1.6 when 1.7 comes out: It just means 1.7 will not be functionally-identical to 1.5/1.6. Since at that point the new forge feature will be guaranteed, I'll probably dump the Controller entirely and bake everything into the blocks. We'll see. 1.7 is still weeks away at best, and probably more like a month, since Grum/Dinnerbone are still fucking with the code to such an extreme degree that they even have to delay snapshots. I think it'll be great when it gets here, but it'll be a transition for sure.)

[Mon732]

Hi jakj I have tried 2.3.0.0 out and that has indeed fixed the problem.

I did notice that state cells like to emit a pulse when they have been moved, just something to look out for anyone making circuits using Project Red and Carriages.

Thank you for the quick response and for such a great mod. :D

[Blaster]

I'm sorry if this has already been suggested, but have you considered a motor that could turn frames 90 degrees per pulse?

Sorry, can someone delete this post

[planetguy]

I'm sorry if this has already been suggested, but have you considered a motor that could turn frames 90 degrees per pulse?

It would be very hard to check if a contraption has space to turn somewhere, and would require special handling for almost every block, vanilla or modded. Torches, buttons, repeaters, chests, furnaces, comparators, cocoa beans, Thermal Expansion machines, Buildcraft engines, and thousands more blocks are different depending which direction they face, and would all need special handling.

[jakj]

Yes, the problem is all the special code for pretty much every block, especially the ones that span multiple like extended pistons. Physically turning the set of blocks' positions is actually not hard at all, but the result would be scrambled eggs instead of an omelette. Useless to try for anything more complex than a dirt-and-cobblestone hut.

[Blaster]

That's fair enough.

[Demolishun]

@jakj,

I have a dual chunk loader bore setup and it keeps stopping. Everything is okay, but I keep finding the turtle controlling the two carriages is stopped working. It is just in lala land. I have delays, but maybe they are not where they need to be. Here is the code:

local running = true

local engineSide = "back"

local engine = peripheral.wrap(engineSide)

local direction = 3

local boreSide = "front"

local bore = nil

 

while running do

  -- is the other carriage in front

  if turtle.detect() == true then

    print("moving bore")

    sleep(2)

    bore = peripheral.wrap(boreSide)

   

    if bore ~= nil then

      bore.move(direction, false, false)

    end

  else

    print("moving self")

    sleep(2)

    engine.move(direction, false, false)               

  end

 

  sleep(0.5) 

end

Anyway, the setup is like this: http://imgur.com/a/sKJoi#0

The whole idea is the support carriage behind the main carriage is the controller with a turtle at the front. When it starts it checks for the controller from the other carriage. If it sees this then it waits a couple of seconds, then tells that carriage to move. Then it loops. If it does not see the carriage then the other carriage was able to move. So it waits 2 seconds and then moves itself. Both carriages have chunk loaders. The strategy is that only 1 chunkloader will be moving at any time. That way one will be in actual existence in the world keeping everything running.

So I remember seeing something in this forum about the computers having issues. So of course the code is designed to be rebootable. What is happening though is the computer is rebooting, but at some point it glitches. I find it in a state where it does not make to the point where it actually will print anything out.

My main question is: Do I need a big fat delay before everything in the program? That way things will settle and keep this out of lala land?

I am running 1.5.2 Unleashed 1.1.4. I have the latest version of RiM 2.3.0.

Thanks

[jakj]

Delays are always good: My mod breaks assumptions and rips into the laws of physics that Minecraft and its mods rely on. Carriages fuck with the game universe harder than a bored Q.

Also, I've always said that chunk loaders are an unknown entity and are incredibly hard to use and test in this way. If this problem you describe can be reliably reproduced, the first thing you need to do is reproduce it, except also have stationary chunk loaders too to guarantee everything stays loaded, and see if it happens again. This will tell you if the moving chunk loaders are even working right.

[Demolishun]

I think I may have solved this. I put in a 5 second startup delay before anything else happens. It seems to have perhaps fixed the issue with the turtle startup going into lala land.

Yeah, I have been fighting the chunk loading for a while. I know older frame mods had this same issue apparently. The solution was dual chunk loaders. Well, I will keep testing and let you know what I find. Thanks for getting back to me quickly. I kind of figured I was in uncharted territory using the Arcane bore, RiM, and chunk loaders. But it does work mostly. Once I figure out this computer boot thing.

When I get a chance I may do a small test setup that has 2 ender chests. Put an item in one chest and the carriage should pipe it to the other chest. This would allow for remote testing of the chunk loaders.

[Walter McCombs]

[Viktor_Berg]

You know, I am tempted to contact the CC forums and discuss the creation of a wireless peripherals addon for the computers. Being able to link a moving carriage controller to a stationary computer wirelessly would be of such great benefit to everyone.