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

[jakj]

That's an interesting idea: Unidirectional translocation. I'll give it some thought.

[TheBytemaster]

That's an interesting idea: Unidirectional translocation. I'll give it some thought.

If a player tried to trans-locate somewhere using this new drive where blocks already existed, would it just not let them or would Bad Things™ happen?

[Lethosos]

Would be best to do "nearest available space," so there's some problems with coding that.

[Neowulf]

If a player tried to trans-locate somewhere using this new drive where blocks already existed, would it just not let them or would Bad Things™ happen?

Teleport would fail. Basically all it would do is create a phantom translocator at (current position + drive distance) and do a normal translocate to it. Not much code would be needed and it could reuse the current CC integration.

[jakj]

Multiple ways to do it:

1) Translocate. If anything's there, tough titties, it's gone now, Star Trek episode where you phased through the floor. Easy to code; Quick to execute.

2) Try to translocate: Fail if you can't. Easy to code; Quick to execute.

3) Try to translocate: If you can't, pull back one block's distance and try again, repeating until you get back to the starting position, failing if you reach the starting position. Moderate to code; moderate to execute.

4) Try to translocate: Start checking spot-by-spot in the direction of travel (to a maximum of your "jump distance"), and translocate at that distance or just short of the first discovered obstruction. Moderate to code; Super fucking slow to execute.

[TheBytemaster]

Multiple ways to do it:

1) Translocate. If anything's there, tough titties, it's gone now, Star Trek episode where you phased through the floor. Easy to code; Quick to execute.

2) Try to translocate: Fail if you can't. Easy to code; Quick to execute.

3) Try to translocate: If you can't, pull back one block's distance and try again, repeating until you get back to the starting position, failing if you reach the starting position. Moderate to code; moderate to execute.

4) Try to translocate: Start checking spot-by-spot in the direction of travel (to a maximum of your "jump distance"), and translocate at that distance or just short of the first discovered obstruction. Moderate to code; Super fucking slow to execute.

I vote for/would prefer 3, because that would offer both the ability to trans-locate through obstacles as long as there is space, (like for secret underground bases), and the ability to guesstimate distances and have it auto-stop when it hits something as long as you are reasonably accurate and there isn't a space behind what you were aiming for, (like for the drop pods theprolo was talking about), all without being too super slow or frustrating. I can think of a few interesting builds for this mechanic already.

Wouldn't 4 essentially just be a faster-moving version of the existing carriage motor?

EDIT: I just realized that my first case, (being able to skip through obstacles), is already somewhat covered by the trans-locator, but you have to have traveled to the location first to place the other trans-locator in the pair... But this would allow you to do such without having visited the place already... and would still be handy for the situations solution number 4 covers without being too resource heavy... I guess I still vote for 3.

[jakj]

4 is in effect a faster version of a continuous-mode drive, yes, except it does not ever occupy the intervening space.

[Viktor_Berg]

This mod is great... I just used it to move a 9 x 6 chunk building (over 60k bricks!). Thing is... now I have to remove the carriage, lol.

It would be cool if we had a way to automatically "fold" an entire structure carriage (and maybe autobuild it by giving it x,y,z dimensions?).

You know, that's actually not a bad idea. I dunno how it would be implemented, but it'd be nice to have auto-buildable/auto-collapsible versions of every carriage. It could, for example, be done by a carriage controller (upgraded with, for example a chest and some ender pearls) that accepts input from a computer to build or collapse an adjacent AxB platform carriage, or an AxBxC structure carriage, or whatever. I know it sounds like laziness, but in your case, you had to deal with a structure carriage that involved placing and then removing at least 500-600 structure carriages. That's 9-10 stacks of blocks, goddamn.

[jakj]

There are plenty of ways to auto-build carriages. Hell, you can auto-build them with nothing but a turtle, and if it's something as simple as a structure carriage, you can write that program while asleep.

The only issue with breaking it back down is the method I have to use to generate drops requires access to the tile entity, and the normal Minecraft method of breaking blocks has destroyed the tile entity by the time it gets there. It works fine for normal play, but other-mod automation can't handle it, so instead the drops are just gone.

[Normal69]

Wow. And you are taking care of both 1.5.x and 1.6.x versions.

Brilliant, can't wait to try it out on my server - so I won't! Doing it right now!

[jakj]

Wow. And you are taking care of both 1.5.x and 1.6.x versions.

Brilliant, can't wait to try it out on my server - so I won't! Doing it right now!

Fortunately, because my mod is so small, the difference between the 1.5.x and 1.6.x branches is only about ten lines of code.

When 1.7.x hits...then will come the pain.

[Viktor_Berg]

Fortunately, because my mod is so small, the difference between the 1.5.x and 1.6.x branches is only about ten lines of code.

When 1.7.x hits...then will come the pain.

How so?

[jakj]

The Minecraft code base is undergoing a refactoring even bigger than the transition to the elimination of true single player, even to the point that cpw is concerned that many modders, even big ones, will be so daunted by the sudden major changes that they might even stop modding altogether. Cpw does overreact, but there's an element of truth to it in this case.

[Viktor_Berg]

What does that refactoring involve? Is it something beyond a render rewrite? Do you know what we will expect from the new version, in terms of performance/flexibility? I assume you've already taken some sneak peaks at the 1.7 snapshot source code.

[jakj]

What does that refactoring involve? Is it something beyond a render rewrite? Do you know what we will expect from the new version, in terms of performance/flexibility? I assume you've already taken some sneak peaks at the 1.7 snapshot source code.

For one thing, blocks will now be registered by name instead of by ID, which I anticipate might have a significant performance hit because, instead of simply referencing by array index, now it will at the least be querying a map by string hash. Do I think "significant performance hit" means "performance hit anyone will notice"? Eeeeeh...I'm kind of leaning toward not, simply because Minecraft is so efficient in so many other ways, that small additional inefficiencies are completely drowned in the process.

This is obviously affecting worldgen to a significant degree, too, and if you noticed the whole 1.6.3/4 thing, that was a "transitional" patch to alter some data structures in storage for the 1.7 transition, because otherwise worlds would be un-upgradeable, and that transitional patch already broke some mods (pretty much anything that did custom worldgen structures), and 1.7 isn't even here yet.

Let me try and put it in perspective this way: As one major developer has already said, "Even the dirt-to-diamonds mods will have to be rewritten.".

Do I think this is a catastrophe? No, I think we'll be fine. From what I've seen and heard, the transition to integrated servers was much more difficult, and this really isn't looking like a difficult upgrade process. What it looks like is really fucking annoying beyond anything that's ever come before, and it's going to be unimagineably tedious for the huge block-altering mods like Buildcraft, Ars Magica, and...well, 95% of all mods, quite honestly.

Is it a good change? If they don't fuck it up, yes: Getting rid of block IDs would be awesome. But when 1.7 hits, expect the whining and moaning to begin (from myself included), expect the majority of modders to be in "oh hell no" mode for at least the first week or two, and expect a few mods to announce that they're skipping 1.7 entirely.

But once the dust settles, and people realize (if nothing more changes between now and then) that it's not really difficult but just super-annoying, I think the majority will sit down and push out a 1.7 version before too terribly long.

[Dougman]

Interesting, if they are all registered by name, do you know how mod blocks with the same name will be handled, such as the many copper blocks that we have?

[jakj]

Interesting, if they are all registered by name, do you know how mod blocks with the same name will be handled, such as the many copper blocks that we have?

No idea, since I haven't looked at the code yet. Presumably the same way it does now, by saying "Hey moron, you're trying to register something that's already registered". For the most part, there will be no issues, because for the most part, mod authors have enough of a clue to at least put the name of their mod in their internal handles. If somebody registered it as "tile.copper", then they really are too dumb to be modding in the first place.

[Viktor_Berg]

If somebody registered it as "tile.copper", then they really are too dumb to be modding in the first place.

So that's almost every minecraft mod author out there.

[theprolo]

A lot of mods already use the modders name in stuff to prevent conflicts, so I guess for the most part it'll be stuff like "tile.Theprolo_Copper", which should be pretty foolproof (in the sense that people using it won't have their stuff broken by other mods, not that fools won't be able to use it, although I guess that's possible)

[jakj]

If anybody got a spam DM on twitter from my account, just delete and ignore it (and let me know if you get another one). Apparently some fuck got my password, and I changed it now, but Twitter's security is sketchy and it may allow cached logins to continue even after a password change.

[NightKev]

Well, from the snapshot you can spawn in items via naming them as, for example, "minecraft:stone", so mod authors will probably be forced to have a prefix of some sort for their mod, even if it can be omitted in the case of unique items... hopefully, anyway.

[jakj]

Oh, that would work, if it's namespaces by mod id.

[Normal69]

I just have one little problem with this perfect mod - the recipes are too easy.

I would prefer just a few huge moving structures, instead of a LOT on the server - and the motors and frames are too easily made.

Could it be made like the base crosspiece you make for the frames, and one necessary element for the 3 types of motors could be set, and changed in the configuration?

Also I have no computercraft mod installed, but that motor item is still craftable.

[TheBytemaster]

I just have one little problem with this perfect mod - the recipes are too easy.

I would prefer just a few huge moving structures, instead of a LOT on the server - and the motors and frames are too easily made.

The hard mode jakj has planned will resolve your concerns very quickly once released, rest assured.

[Jyzarc]

does this mean no more ID conflicts after 1.7? :D