Jump to content

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


jakj

Recommended Posts

Here is the crash with secret rooms gates, http://pastebin.com/Aczf9Fza

Yeah, that's not good enough, as it turns out. According to the error that you posted, somehow you are triggering a carriage to move, but at the time the carriage starts to move, the first carriage block (attached to the engine or motor) is not actually a carriage block, but is instead some block from that other mod. Almost like a last-second prestidigital swap. This, of course, makes no sense, so without further information (a full log, screenshots), I can't help you.

Link to comment
Share on other sites

I told you to post the log, not just clip out the error. But there's some useful information in there, so I'll see what I can do with it. I'll post again if I track down the issue.

I dont see how this helps but here is the full log: http://pastebin.com/yixM7emM I think that might be because I put a gate next to a frame, so it took the texture of the frame.

Edit: But the first carriage block is an actual carriage block

Link to comment
Share on other sites

I dont see how this helps but here is the full log: http://pastebin.com/yixM7emM I think that might be because I put a gate next to a frame, so it took the texture of the frame.

Edit: But the first carriage block is an actual carriage block

1) You are using version 1.2.0.0. Try version 1.2.0.1 and see if that helps.

2) The error log is called "ForgeModLoader-client-0.log", right after a crash. If you have since opened the game without crashing it again, you'll need to get it to crash for that file to be the proper error log.

3) Since I've never used the mod you're using, I have no idea what it does, and what effects it has. Can it somehow counterfeit a block, so my mod thinks a block is a carriage block but when it tries to actually treat it as one it fails? I don't even know what you're trying to do.

Link to comment
Share on other sites

1) You are using version 1.2.0.0. Try version 1.2.0.1 and see if that helps.

2) The error log is called "ForgeModLoader-client-0.log", right after a crash. If you have since opened the game without crashing it again, you'll need to get it to crash for that file to be the proper error log.

3) Since I've never used the mod you're using, I have no idea what it does, and what effects it has. Can it somehow counterfeit a block, so my mod thinks a block is a carriage block but when it tries to actually treat it as one it fails? I don't even know what you're trying to do.

well ummm... this is awkward, I updated and now it magically works

Link to comment
Share on other sites

To celebrate the one-month anniversary of no updates, have an update! (The changelog includes the 1.2.0.0->1.2.0.1 update as well as the current 1.2.0.1->1.2.1.0, because I was super-lazy and never officially released 1.2.0.1.)

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

1.2.0.1 -> 1.2.1.0

 -- added 16x Dynasty-based texture set by Lethosos

 -- added notes to tooltips that 'platform' and 'support' carriages will be swapping names in the future

 -- fixed bug that the pattern-holding block of a template carriage can overwrite other blocks in the world

 -- template carriages will now drop their pattern carriage blocks when the core template block is broken

 -- fixed bug that caused controllers to not recognize existing carriages when the world or chunk is loaded

 -- return codes overhauled for Carriage Controller

    ** (this needs testing because I don't know ComputerCraft or Lua)

    ** if motion is successful, returns "true" and nothing else (1 value)

    ** if motion is not successful because of obstruction, returns "false", then a plain-English error message, then the X/Y/Z coordinates of the obstruction (5 values)

    ** if motion is not successful because of something other than obstruction, returns "false", then a plain-English error message (2 values)

    ** the only time it will now throw an error and abort the running program is for a syntax error; a valid command that simply can't be carried out will no longer abort the running program



1.2.0.0 -> 1.2.0.1

 -- removed some vestigal server->client data transmission

 -- fixed buildcraft pipes not accepting items immediately after transit

 -- fixed items in buildcraft pipes stuttering/slowing after transit

 -- fixed ComputerCraft synchronization with Minecraft thread of execution to clear a bunch of crashes

 -- continuous-mode cooldown can now be changed back to 0, though the default for new configurations will still be 5

    ** note that with no cooldown, after the first step of transit, many tile entities will no longer render correctly until transit stops

       ## this is cosmetic only, and does not occur if there is a cooldown of at least a couple of ticks unless server->client transmission is super-slow


 


KNOWN ISSUES



Anything that already uses a display list to render (like the ghost blocks of a patterned template carriage) will not properly render in-transit.



Transparent blocks (like water) render in a bit of a wonky fashion in-transit.



----------



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.



Anything using Forge's "multipart" API (such as the newest ChickenBones wireless redstone) do not yet work on carriages.



----------



If you are using Optifine and get a crash 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



A mechanism for teleporting carriages between dimensions.



Redoing and simplifying the 'move' command to make it more intuitive and easy to use.



The ability to deactivate specific sides of engines and motors to allow for staged carriage structures with multiple carriage blocks in contact with drives.



A config option to specify whether in-transit rendering of a carriage continues or pauses when there is severe lag.



The ability to set block or item IDs to 0 to prevent their being registered.



Improving the behaviour of placeholder blocks.



Swapping the names of platform and support carriages to reduce confusion in the future.



The ability to remove bedrock from the blacklist if desired.



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.



The ability to set continuous-mode cooldown per drive instead of only system-wide.



An optional "hardcore" mode, for people who want this mod to be expensive to use.

Link to comment
Share on other sites

-- return codes overhauled for Carriage Controller

** (this needs testing because I don't know ComputerCraft or Lua)

** if motion is successful, returns "true" and nothing else (1 value)

** if motion is not successful because of obstruction, returns "false", then a plain-English error message, then the X/Y/Z coordinates of the obstruction (5 values)

** if motion is not successful because of something other than obstruction, returns "false", then a plain-English error message (2 values)

** the only time it will now throw an error and abort the running program is for a syntax error; a valid command that simply can't be carried out will no longer abort the running program

Thanks for that! I can confirm that it works. I uploaded the Lua program I used for testing to pastebin if anyone would like to verify.

Link to comment
Share on other sites

I'm also so thankful for that. Was coding something for a RiM hidden entrance door in the previous release and the move function aborting the program whenever it was obstructed made it a hellll of a pain in the ass to make (and i didn't even got it to work). I don't know how I've overseen that ... Well I need to give it a shot now ...

Link to comment
Share on other sites

Weird texture I found with Template Carriages.

  • RiM: 1.2.1.0
  • MFR: 2.6.4 (1.5.1R2.6.4)
  • No Optifine
  • Vanilla texture pack

http://youtu.be/7A4j9nqxoUw

BTW, I encourage the creation of a Redstone in Motion sub-reddit where we can discuss new features, show our builds and brainstorm for new ideas in an organized way.. That's what Redpower Frames missed. Sure there is this forum but IMHO reddit is way "cleaner" and allows you to look for what you want quickly ..

Link to comment
Share on other sites

For the texture issue, there's really no reason it should be doing that, but since it is, I have a workaround I can try.

For the subreddit, I have no interest in administrating such a thing, but if someone else makes one, I can give it a shot I guess.

Link to comment
Share on other sites

Weird texture I found with Template Carriages.

  • RiM: 1.2.1.0
  • MFR: 2.6.4 (1.5.1R2.6.4)
  • No Optifine
  • Vanilla texture pack

http://youtu.be/7A4j9nqxoUw

BTW, I encourage the creation of a Redstone in Motion sub-reddit where we can discuss new features, show our builds and brainstorm for new ideas in an organized way.. That's what Redpower Frames missed. Sure there is this forum but IMHO reddit is way "cleaner" and allows you to look for what you want quickly ..

That just happens when you are in the Template "Shadow" Mode. Don't worry because it works when the grey blocks are not visible, too.

Link to comment
Share on other sites

As long as it doesn't abort the program simply because it's stuck, it's fine. :))

What?

How are you going to do it then?

(Or is that a surprise for next update?)

First change, you will be able to use the strings "up","down","east","west","north","south" and the strings "posy","negy","posx","negx","posz","negz" in addition to the current digits of 0,1,2,3,4,5 for specifying direction.

Second, simplifying the commands:

move(0,false,false) becomes drive(0)

move(0,false,true) becomes move(0)

move(0,true,false) becomes drive_check(0)

move(0,true,true) becomes move_check(0)

So basically, "drive" is non-anchored mode like engine, and "move" is anchored mode like motor.

So the terms are intuitive, think of a car: If you drive the car, you're in the car and you go with it, whereas if you just move a car (like with a crane or tow truck), you don't go with the car.

Link to comment
Share on other sites

In the previous release 1.2.0.1, if you called the move function while something was blocking the frames' movement, the carriage controller would throw an error message AND abort the program you are running ... then in 1.2.1.0 the move function fixed that issue ... and now you're telling us that you "thought of a better way to do it." so I wanted to remind you not to make the move command work like in 1.2.0.1 ..

My message was very clear, IMHO.

I don't think the terms are intuitive because people will get mistaken. the DRIVE() will "MOVE" with the frames like the carriage engine does while the MOVE() will push the frames while staying put like the carriage DRIVE does ...

I dunno ..

Link to comment
Share on other sites

In the previous release 1.2.0.1, if you called the move function while something was blocking the frames' movement, the carriage controller would throw an error message AND abort the program you are running ... then in 1.2.1.0 the move function fixed that issue ... and now you're telling us that you "thought of a better way to do it." so I wanted to remind you not to make the move command work like in 1.2.0.1 ..

My message was very clear, IMHO.

I wasn't talking about that. I was talking about my comment that I was going to split the anchored and non-anchored into separate blocks, and then decided I won't. My edit wasn't clear.

I don't think the terms are intuitive because people will get mistaken. the DRIVE() will "MOVE" with the frames like the carriage engine does while the MOVE() will push the frames while staying put like the carriage DRIVE does ...

I dunno ..

Okay well, you guys try to think up something more intuitive, then. I'd rather not do something like move_anchored and move_unanchored but I guess I can. Or I can just leave the boolean parameter in there, but I think splitting the functions would make code much more readable.

Link to comment
Share on other sites

I don't really mind the move+drive combo, but while we're brainstorming alternatives: maybe you could do something like adding a... state to the controller? Similar to how one toggles continuous mode, just for motor/engine mode of the controller. So we could then change that state, instead of passing it as a parameter. A code example to make it more clear what I mean:

local controller = peripheral.wrap(side)

controller.setAnchored(true)

assert(controller.isAnchored())

controller.move("east")

controller.setAnchored(false)

if controller.check("west") then

  print("ok")

end

Just an idea, not sure if it's the best way to do it, but it would work well with the use cases I can think of - where you normally would work in one mode for multiple moves and not switch the modes all the time. Another consideration would then be what to make the default. I'd opt for unanchored mode. Also, the controller should probably forget this state when broken by the player, to avoid unexpected behavior - i.e. it should always be in the same starting state after being placed. Thoughts?

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...