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

[jakj]

You need to have an os.sleep of at least 0.1 (maybe a bit more) to allow the computer to reconfigure itself after each motion.

[Spaceshipable]

Oh, guys... that is the issue?

Try something like this. You'll get the normal return value of move in 'status', and a string containing the error in 'err'

local status, err = pcall(p.move(0, false, true))

Oh awesome. Will have to play with this at some point. Seems to solve the issue completely.

[Spaceshipable]

This is what I have come up with so far for my program in case anyone is interested. It's nice and simple thus far.

[Ember2528]

I have crash from this mining machine when I open the world it has moved. But I do have quite a few mods installed with it. Other than that I've enjoyed the mod. Also I'm at max world height because I don't want it to run into the highlands biomes mountains or natura clouds http://imgur.com/gw2lYmr&XrfFDz5#0 http://pastebin.com/z4qfCYH8

[theprolo]

Looks like your ultimate solar panels are bugging out - does it work if you remove them?

[jakj]

I have crash from this mining machine when I open the world it has moved. But I do have quite a few mods installed with it. Other than that I've enjoyed the mod. Also I'm at max world height because I don't want it to run into the highlands biomes mountains or natura clouds http://imgur.com/gw2lYmr&XrfFDz5#0 http://pastebin.com/z4qfCYH8

You'll have to give more detail than that sketchy report. Are you saying the only time it crashes is if you close and reopen the world after you have moved the carriage, but not at any other time?

[Garloth]

I think he meant that it crashes when moving but after reopening the world the movement is complete. Just a comma or two missing.

BTW: Feature request - block blacklist.

BTW^2 Can it move bedrock?

[Lethosos]

The last I can tell you easy enough, he hardcoded the inability to move bedrock right into his code.

In fact, try doing so in Creative mode--drop down some platform carriages, pop a bedrock on top, and move it with a motor/engine.

[Ember2528]

It still crashes without solar panels. and what I mean is that when I apply a redstone signal it crashes but when I open up the world the movement is complete.

Edit did more testing it looks like its moving power converters that causes a crash

[jakj]

I'll take a look at it later.

[masterzh]

Small suggestion, can you make somehow possible that decorative blocks can be combined? With RP frames you could add different types of microblocks on 1 frame. Love your mod and thanks for all you done so far :)

[jakj]

Small suggestion, can you make somehow possible that decorative blocks can be combined? With RP frames you could add different types of microblocks on 1 frame. Love your mod and thanks for all you done so far

I suggest using Immibis's microblocks for putting up complex decorations. Making each side of a carriage block have a different texture would add a huge amount of complexity (both for me and for the players), and would probably just be followed by requests to change the carriage block's shape and size too. Let's keep it simple.

[Sangar]

I know I'm a little late, but I'd just like to add my 2 cents to the discussion about the Lua API real quick.

Sorry in advance for the lengthy post... for the tl;dr skip to the list below.

It has already been mentioned that the call can be wrapped with pcall to avoid an error blowing up your whole program, but I'd like to make a small distinction: while Java loves to throw exceptions to indicate whether some operation was successful or not (say, read from a file or stream), as to my knowledge this not very... "Lua-esque" (and bad style IMO, but that's just me disliking Java). In Lua, an error normally means you have a bug in your program, and unless you write something pretty special, it should be fatal. It is an error, not an exception, in Java terms. For example, throwing on invalid parameters, as is done, is a perfect application of this. You should really know what arguments you're passing along, and if they come from some dynamic source (user input) you better validate them!

However, what should not throw errors are things that may or may not fail, in this case: all the errors based on where the carriage is in relation to the controller and such things, so basically the ones in Move() and GeneratePackage(), as far as I can tell. Instead, the Lua way is to have a function return a tuple of which the first value indicates whether the operation was performed successfully or not, and the rest represents optional output (results on success, error messages on failure). That tuple is the array of objects you return on the Java side of things.

So, in short, I propose the following behavior:

• throw an exception if the input arguments are invalid, no change here.
  
• return new Object[] { true } on success, no change here, either.
  
• return new Object[] { false, errorMessage } if the command cannot be executed as desired (so instead of the if (Error != null) throw Error; part something like if (Error != null) return new Object[] {false, Error.toString() }; I guess?).
  
• I personally don't feel this would be necessary, but it may be possible to specialize this in case there's an obstruction to return new Object[] { false, errorMessage, x, y, z } to include the coordinates of whatever is blocking the carriage based on the exception type?
  

This would be very consistent with how one writes most other Lua code, for example even something as low-level as pcall does this: it returns (true, retval1, retval2, ...) on success and (false, errorMessage) if the wrapped function threw an error (pcall in Lua is, put simply, what try-catch is in Java).

So on the Lua side you'd then write:

local drive = peripheral.wrap(side)

local success, reason = drive.move(...)

if not success then

    print(reason) -- or whatever

end

As I said, this is just my humble opinion on this matter, I'm not trying to tell anyone what to do, just hoping it is taken into consideration. Thanks!

Long as this post already is... while on the topic of the Lua API, I'd like to bring up just a few tiny ideas

• The first is probably a matter of preference, but still, I'd regret not mentioning it: I personally think it would be clearer to split the exposed move() function into move() and simulate(), instead of passing that as a parameter. It'd just make the code so much more readable. One can obviously write small wrapper functions for this, but it'd be nice if it were... official.
  
• The second is also just a matter of convenience: how about a way of querying the number of blocks a controller is connected to? So you could do peripheral.call(side, "count") or whatever you choose to name it. That would be very helpful when building large "ships", to know how much more you can add (in particular in multiplayer when working with other players). It could return some magical string constant (e.g. "uncountable") when there's too many for the controller to move the frame, to guarantee it never throws (similar to ComputerCraft's turtle.getFuelLevel()).
  

Whether or not these ideas make it in, thanks again for your brilliant (open source ) work!

[jakj]

Sangar, your suggestion has elegance, but I'm a bit flabbergasted. Are you telling me that you can specify any number of variables as return values, and the trailers get populated with nil if nothing is present? So if you say successflag,errormessage,obstructionx,obstructiony,obstructionz = drive.move(...), and I return just {true}, you get {true,nil,nil,nil,nil}, and if I return {false,"foo"}, you get {false,"foo",nil,nil,nil}, and if I return {false,"bar",1,2,3}, you get {false,"bar",1,2,3}?

[Sangar]

Are you telling me that you can specify any number of variables as return values, and the trailers get populated with nil if nothing is present? So if you say successflag,errormessage,obstructionx,obstructiony,obstructionz = drive.move(...), and I return just {true}, you get {true,nil,nil,nil,nil}, and if I return {false,"foo"}, you get {false,"foo",nil,nil,nil}, and if I return {false,"bar",1,2,3}, you get {false,"bar",1,2,3}?

That's exactly how it is To grab multiple result values in Lua you just write

a, b, c, d = f()

which would try to receive 4 return values. If there are more they are discarded, if there are less, the rest of the variables will be set to 'nil'.

To avoid others who are only slightly familiar with Lua getting confused, I'd like to clarify that you get the result "without the curly braces" in Lua (those indicate a table in Lua, which is a mix of an array and a map - it has numeric indices for array behavior and arbitrary typed keys for map behavior at the same time). Tuples are not an actual datatype in Lua, they're just a convenient... concept for returning, passing and assigning multiple values at once (you can also write stuff like a, b = b, a for example).

[jakj]

Damn, I desperately wish Java had that feature. Anyway, that solves it, then: I'll change it to abort only on syntax error, and I'll split the functions for readability.

[Sangar]

Awesome, thanks a bunch!

[Spaceshipable]

what does this mean in laymans terms?

[Lethosos]

Can't Java do a similar function through the use of an Object container? Just build an empty class, add variables of your choice, set the constructor to fill in null by default, and bob's your uncle.

[jakj]

Can't Java do a similar function through the use of an Object container? Just build an empty class, add variables of your choice, set the constructor to fill in null by default, and bob's your uncle.

Well no shit. I mean a language construct. For example:

public static int , int DetermineRange ( int ... Values )

min , max = DetermineRange ( 8 , 14 , 97 , 3 , 1 )

[Sangar]

@Spaceshipable: in short, it means you won't have to worry about move() throwing errors (unless you input bad variables, say wrong types or values, which is something you can control/check before calling the function). Plus it sounds like we'll get an extra function for the movement simulation. So instead of

local drive = peripheral.wrap(side)

local canMove, whyNot = pcall(drive.move, 0, true, true)

you would then write something along these lines

local drive = peripheral.wrap(side)

local canMove, whyNot = drive.simulate(0, true)

which is a lot clearer when reading the code. Note that I don't know what that function will be called, it might well be something else like drive.test (which in hindsight I think would be nicer) or drive.check or whatever.

[Lethosos]

Ah. Carry on, then. Figuring out things like this is half the fun.

[jirok769]

How about this? (you can duplicate items stored in any ic2 block)

.

and burning process in generators after motion restores to full (full time of resource burning)

And can you make player grab like in UgoCraft (player can walk on moving part)?

(sorry for bad english, i'm just studing this language)

[jakj]

How about this? (you can duplicate items stored in any ic2 block)

.

and burning process in generators after motion restores to full (full time of resource burning)

And can you make player grab like in UgoCraft (player can walk on moving part)?

(sorry for bad english, i'm just studing this language)

That's not a bug in my mod: That's a bug in the other mod, or rather, it's a flaw in design. What's happening is 1) the GUI opens, and you have stuff in it, 2) the block moves, taking the stuff with it, but leaving the GUI open, 3) you move stuff out of the GUI into your inventory, and the GUI client-side puts it in your inventory without first checking server-side to make sure it's valid. As it stands, the other mod is just "trusting" the player to not be cheating, and also is assuming (stupidly) that nothing on the server side can change state while the GUI is open.

To fix this, the author of the other mod needs to make sure that all client-side GUI actions pass through the server to check their validity. Right now, this is an open dupe exploit in the mod that can be leveraged by anyone with coding knowledge, without even using my mod.

Better player motion options while on carriages is planned for a future release.

[Viktor_Berg]

I presume this would be replicable with vanilla pistols, too.

As for better player movement, did you actually manage to figure out a way to bypass the issue of moving entities on top of moving carriages? Could you enlighten us?