It's niggling me that Packers and Unpackers are running a little too quickly. Due to an oversight in the original code, they combine their inputs immediately, rather than - as with other components - waiting until the click after the cargo has arrived in an input square (so that the cargo is actually visible for one click). This can make it quite hard to follow what's happening in a level with lots of adders, and it starts to get visibly ridiculous with machines like jymoveg.

It's trivial enough to change the code so that Packers wait for a click before combining their inputs - this will break loads of existing levels, though, and also render some bits of people's "toolboxes" obsolete. I can sort out something so that older levels can still be run the way they used to be (by looking at the timestamp of the save file, and alerting the user to the fact that it'll be running under the old physics model), but people are going to have to heavily rethink their usage of adders.

I think it's a bad idea to change how any part work, it will break too many existing puzzles. In another thread you talked about implementing a way for the author of a puzzle to choose the laws of the world, that might be a good way of introducing this change.

That seems more confusing, if new levels are going to have to say "hello, this level uses slow packers" or "this one uses fast packers" each time, with players having to continually shift mindsets to be able to solve them. It'd be cleaner to just say that they'll all use slow packers from now on, with fast packers being a rare and heralded exception whenever a player loads in an old level (or old solution).

I vote to leave them as they are. There are other interesting differences in timing between components. For example, some components will take the input away before the furnace consumes it, such as copiers, and some won't, such as winches. Put a furnace right next to the input of a downward copier, and also of a downward winch and drop a barrel on them. You'll see the copier copies before the barrel is burned, but the winch stays perfectly still and misses the barrel. IMHO, that's fine, and I've come to depend on such subtle differences in behavior when constructing complicated sequences.

I dont see why you couldnt change it, the game IS in beta still right? It WOULD mess up older levels, but that is part of playing beta versions of games, right? But here is MY suggestion: give us 2 different types of packers! Slow packer AND Fast packer!

I've put up a version of Rubicon that uses slow packers at http://kevan.org/rubicon/beta/game.html - you can load in any existing level, and mess around in the sandbox as normal. I agree that the timing nuances don't really matter and people will get used to anything, but running them like this does make it a lot clearer to the viewer what's going on (and makes jymoveg a lot nicer to watch, even if it completely fails to do its job now).

And hm, it looks like copiers are also running too quickly, in the same way - it's certainly unintuitive that chains of copiers can cross furnaces in a way that pipes can't, and that pushing crates into copiers and pipes at the same time gives you a copied crate one click before a piped one. (Examples at zagykav.)

And hm, it looks like copiers are also running too quickly, in the same way - it's certainly unintuitive that chains of copiers can cross furnaces in a way that pipes can't, and that pushing crates into copiers and pipes at the same time gives you a copied crate one click before a piped one. (Examples at zagykav.)

Well, that's why one usually uses long pipes to bypass furnaces instead of a series of short ones.

One major difference will be how it handles moving cargo, for example: gugofyv. When F and E are under the packer, it combines them on the next tick. However, E and D will be on the inputs on the next tick, and on top of that F will be in the way of the output. Will it be able to handle that properly?

Obviously the whole purpose of jymoveg was to take advantage of the fact that information could be communicated instantaneously using the packers. However, even if they are slowed down, they would still be twice as fast as dozers/coveyors (like keys), and certainly nicer to look at.I think the only real downside to slowing them down is compatibility. If you can have a timestamp on the saved levels that triggers the use of fast packers (and warns the player this was created using an old version...), I would be happy to have them changed.As for what Hand-E-Food said, I disagree, as simply putting a girder instead of a conveyor just below the packer fixes the result in the slowed down version.[edit]Only half speed timers (or much more complicated ones) though, argh! Oh well...[/edit]

However, in the same idea, even if it is not as obvious as packers, the speed behaviour of components, in particular copiers, is not always consistent (people certainly know that and take advantage of it but still):lakosol. Also, as jf said, I think furnaces should also always come last, or something.In general, I think the order of precedence of components should be documented.

Also, why is it possible to move instantly vertically (with pipes) and not horizontally? As useful as it is useful for timing purposes, it seems quite unfair , maybe we could have horizontal pipes, or vertical girders.

Oh, and could it be possible to have a "play slow"/"step by step" option for debug/understanding what the hell is going on on other peoples machines?

Yeah, the pipes is something I've been thinking about. Not too sure about side-to-side pipes though, if you start doing that, why shouldn't everything be in all directions. Side-winches, packers and unpackers going left instead of right, left and right duplicators?

Yeah, you're probably right, as frustrating as it is, it's part of the fun to have to handle gravity and assymetrical components. But there is currently no way to go up at normal (or slower) speed, which would seem logical.