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

[lukeb28]

Maybe you could have it probe for gravel/sand in the area and provide place holder blocks in those locations only?

[jakj]

Maybe you could have it probe for gravel/sand in the area and provide place holder blocks in those locations only?

That's another option.

Yet another option is to put placeholders only in the final positions but still put air where blocks are vacating, which would reduce the extra block-access count to half. That would mean a properly-roofed mining machine would have the sand just slide along the roof until the machine is past it, and then fall. It would appear to fall through the carriage if things update quickly enough, but it couldn't fall into a position that'd be occupied by a new block.

Checking specifically for gravel/sand sounds like a good idea, until you think about also having liquids flow downard during transit, as well as having to add every mod block that also is a liquid or falls. I'm thinking placeholder blocks is the only solution that can (in theory) handle every contingency without having to maintain yet another list of exceptions.

[lukeb28]

Place holders where they are going to be sounds like better option. Also sounds like it would be less computer resource intensive.

[jakj]

Place holders where they are going to be sounds like better option. Also sounds like it would be less computer resource intensive.

Yes: The only added block accesses from the current method would be putting the placeholders in the spots the carriage is moving to, that previously were air. Right now, it leaves them as air (does nothing) and then sets them when the carriage is finished moving.

Actually, wait...sand/gravel couldn't fall in those situations anyway, because it already would have fallen through the air. And we don't care if it falls through places where the carriage is leaving behind air. So...I can put placeholder blocks anywhere the carriage is going to move -to- that wasn't already air? That would add no extra block accesses at all.

Then again...adding the extra placeholder blocks -would- allow better collision detection, especially if the player is standing at the very leading edge of the platform as it moves. Placeholder blocks would allow there to be a steady floor there. Hmm........... Then again again, let's say the player is standing on the carriage, and instructs it to move upward. Adding leading placeholder blocks would actually embed the player in one to the waist.

I'm going to let this percolate in my mind for a while. If you think up any additional points, I can factor them in.

[TheBytemaster]

So wait, did Redpower do something other than just placeholder blocks when it came to moving up/down? My Idea would be to create some kind of entity to move the player/any other entity up or down gradually, but this would probably create a lot of unneeded overhead, wouldn't it?

(DISCLAMER: I am not anything even approaching a modder, so this may be the worst idea ever.)

[Lethosos]

Well, what Elo did (AFAIK) in her code, she read the location of all connected blocks, created an entity with all those blocks, removed the old blocks, moved, then copied all the blocks in the entity into their new locations and removed the entity. And that's not taking into consideration of collision code, of which I honestly have no idea how she did it.

[Tahg]

I think as Bytemaster said, creating an entity you can parent to players might be the best way to go, as I'm not sure what kind of sync issues you might get if you just tried to move them. Other entities in the collision area I think should be able to be moved fine. For Tile Entites, are you saving them, and changing their position, or serializing to NBT and then reconstructing them?

[Neowulf]

The couple times I messed with redpower frames and physics blocks I noticed they acted weird, but that was awhile ago and I can't remember what exactly was weird about it. I suspect the redpower way bypassed block updates, so sand stayed floating just like when a gen error created a pool or cavern through sandstone and leaves a sand ceiling.

If you mean world collision. You've got a list of all the block you're moving and the direction, not that hard to cycle through and find the leading edge blocks.

As for entity collision, there's already the code for pistons pushing a player up. Or if you want a solution from another game, snag any entity that is within a small distance above your moving blocks and apply a move transform synchronized with your block movements.

It was an interesting trick someone posted for the torque game engine. One feature of the engine was simple mounting of one object to another, so the parent object transforms would be translated onto the mounted object. He created a system to soft mount any movable object that touched a movingPlatform derived object, so transforms would be applied without actually affecting move vectors. So the player could walk and do small jumps without triggering high speed collisions.

Man that was awhile ago...

[Spaceshipable]

why not add a chair that works like a mountable entity that moves the player when the ship moves?

[jakj]

I'm using a tile entity instead of a regular entity, which provides easier and simpler sync. I am serializing TE data during motion. I am bypassing block updates until all blocks in the group are set, then running them all at once.

The first thing I am going to try is to read the positions of connected entities at the start and set them once per tick to their new positions. If sync becomes an issue, I will begin to examine the minecart code. The first way is better, though, if it ends up working.

I can't mark the player entity as a child since I'm not making an entity. I could create a fake entity though if needed.

Prefer to not make a chair since it restricts mobility and changes the player's pose.

Do note that I'm not trying to recreate that Ugocraft thing: That is more a combination of airships and hangar doors. I'm thinking about eventually allowing you to use the structure carriages to package up a block of the world as an item, take it somewhere else, and redeploy it, but I'm not going to make it like actual rideable airships with motion controls. Someone else is free to take my code and do that if they wish, but it would have to be refactored to be a regular entity instead of a tile entity.

[temotodochi]

Can you provide some sort of list how this compares to redpower frames? I'm mostly interested in the stick/non-stick features when flying close to solid objects.

I'm also interested in moving single frame blocks or frame blocks attached to spawners etc. This is still possible?

Because RP2 engines don't need to be in the structure, you can build all kinds of nifty gadgets like this folding door:

While opening:

And opened:

Those rows of RP2 frame blocks are all independent and they're moved with stationary frame engines.

This is still possible with your new system?

[jakj]

There are two types of drives: "Carriage Engine" which moves with the structure, and "Carriage Motor" which stays where it is but cannot push blocks away from or toward itself. In your example, Carriage Motor would work fine because it's to the side and moving them up/down.

If you want to replicate Redpower frame behaviour, you want to use Frame Carriage: They will connect to single blocks on their sides, and not beyond that. Using a screwdriver on their sides will open/close that side: This is exactly like putting covers on Redpower frames. In your example, you'd just use a screwdriver on all those sides (which will be a lot of clicking, but still easier than placing covers was by a margin). A closed side will not connect to anything, although an Engine/Motor can still move it just fine even if the side touching the drive is closed.

I actually never used RP frames: I just saw them used in videos. Since you have experience with them, I reocmmend just trying to use Carriage Motor and Frame Carriage and seeing if it works. I intend that combination to be 100% accurate to the old RP frames, so if it's not, report it as a bug.

The other types of carriage and drive give functionality beyond what RP offered.

[jakj]

Version 0.0.1.0 now available.

http://j-a-k-j.com/RedstoneInMotion_0.0.1.0.zip

Known issues:

Blocks that schedule updates for themselves (like buttons) do not receive those updates after being moved.

 

Forge information file (mcmod.info) not yet implemented.

 

Blocks drop in creative mode.

 

Some blocks in-transit are not yet rendered.

 

Drives will not work on structure carriages when placed on an edge instead of a corner.

 

Native-resolution texture option not yet implemented.

 

ComputerCraft support not yet implemented.

 

Omni-Wrench support not yet implemented.

 

Recent changes (full list in "Changes.txt"):

 

0.0.0.0 -> 0.0.1.0

-- fixed a crash in WorldUtil . SneakySetBlock

-- drives now indicate when they are active

-- fixed some crashes related to missing tile entities

-- improved shading during rendering of in-transit blocks

-- added in-transit rendering for the following blocks

-- (note: transparency (like for ice) will not be implemented)

-- *) carriages

-- *) carriage drives

-- *) stone

-- *) dirt

-- *) cobblestone

-- *) planks

-- *) sand

-- *) gravel

-- *) gold ore

-- *) iron ore

-- *) coal ore

-- *) logs

-- *) sponge

-- *) glass

-- *) lapis ore

-- *) lapis block

-- *) dispenser

-- *) sandstone

-- *) note block

-- *) wool

-- *) gold block

-- *) iron block

-- *) brick block

-- *) TNT

-- *) bookshelf

-- *) mossy cobblestone

-- *) obsidian

-- *) diamond ore

-- *) diamond block

-- *) crafting table

-- *) farmland

-- *) idle/burning furnaces

-- *) redstone ore

-- *) ice (no transparency)

-- *) snow block

-- *) clay block

-- *) jukebox

-- *) pumpkin (without stem)

-- *) netherrack

-- *) soul sand

-- *) glowstone

-- *) jack 'o th' lantern

-- *) stone brick

-- *) melon (without stem)

-- *) nether brick

-- *) end stone

-- *) unlit/lit redstone lamps

-- *) wooden double-slabs

-- *) emerald ore

-- *) emerald block

-- *) command block

-- *) redstone block

-- *) nether quartz ore

-- *) nether quartz block

-- *) regular torches

[Tahg]

Do you plan to add any (perhaps configurable) power requirement to your motors in the future? This looks really cool but looks like it could be quite overpowering currently.

[jakj]

Do you plan to add any (perhaps configurable) power requirement to your motors in the future? This looks really cool but looks like it could be quite overpowering currently.

Adding a "hardcore" mode is on the table for the future, but only after the rest of the mod is fleshed out. Overpowered-ness is subjective, after all, and there's no way (that I know of) to use this mod to break blocks or otherwise automatically mine without the appropriate tools or other mods present. All this mod really does is move the blocks.

The recipes might be super-cheap compared to a lot of stuff, but just wait until you decide to use a structure carriage to move your entire house, and realize how many trees you have to chop down to make the frame. In vanilla without any additional mods, that's a lot o' fuckin' wood.

[Spaceshipable]

I really like the idea of a hardcore mode with power and more difficult recipes. Certainly the most popular mods all have inter-connectivity.

[jakj]

I really like the idea of a hardcore mode with power and more difficult recipes. Certainly the most popular mods all have inter-connectivity.

Yes, Thermal Expansion (Induction Smelter, Magma Crucible, and Liquid Transposer) is my favourite, followed closedly by IndustrialCraft (Extractor, Compressor, and Macerator).

People really don't take full advantage of these machines. So many people haven't even thought about the fact that the Liquid Transposer works on any combination of items, and it's not just for getting liquid in and out of containers. I have all kinds of recipes in my head, where you craft things together, then transpose liquid into them, smelt them (essentially boiling them), then transpose them back out to make a whole new liquid. Some day I'm going to work on a mod called "Emulsion", which basically lets you make liquids out of a lot of filler blocks like dirt, stone (no, not lava: a cool liquid), clay, and such, pour it into holes, and cure it, thus filling in the holes. Kind of like the BC filler except easier to setup and a whole lot cooler.

(That's the future, though. Yes, there's a 90% chance that the hardcore mode will require other mods. If things keep going at the rate they're going, I figure I'll work on that mode in a few weeks to a month.)

[hoho]

(That's the future, though. Yes, there's a 90% chance that the hardcore mode will require other mods. If things keep going at the rate they're going, I figure I'll work on that mode in a few weeks to a month.)

Looking at your history with Gregtech am I correct to assume you won't likely provide a special hardcore version of the mod using his stuff? I've seen several other mods having their "uldra-hardcore" config use those things, it would be somewhat consistent :)

[jakj]

Looking at your history with Gregtech am I correct to assume you won't likely provide a special hardcore version of the mod using his stuff? I've seen several other mods having their "uldra-hardcore" config use those things, it would be somewhat consistent

History with GregTech? I have nothing against the mod: I just use it as a touchstone for "holy shit hardcore" from what I've heard about it. If enough people are using GregTech and want a hardcore version using it, then I'll take a look.

[hoho]

Ok then, good to know.

I just assumed that him having anti-tekkit code in the mod and you removing it might have caused some friction. If there is none (from your side, at least) it's great.

Do you have any plans on adding not just moving in 6 directions but rotations as well? It'll likely be far harder, especially for stuff like TE machines where each side of the block could have special setup (IO).

[jakj]

Wait wait, what? Anti-tekkit code? The only anti-DRM code I've done was v. Sengir's forestry. Are you thinking of that, or is this new?

Rotations have been mentioned, but I'm iffy about it. The two main issues:

1) Collision detection: Making sure the carriage sweeping across an arc won't impact anything. Technically this is only visual, and can be ignored if visuals are not important.

2) Changing the facing of the blocks. This is a whole giant fucking ball of wax. Think about pistons, doublechests, every single machine in any mod (or even vanilla): I'd have to write code to rotate every one of them. Forge's new rotation code is barely supported by anything yet, and even in that case, it wouldn't handle the situation of something being flipped over vertically.

So I'd say the chance of me doing rotation is farily low. I think Ugocraft does rotation for vanilla blocks, though. And I suppose I could add a -very- limited form of rotation using only the subset of blocks that don't have a facing, but I think all that would get me is a bunch of people yelling about how they want to rotate block X too.

[hoho]

Hm, I'm almost certain I saw a post here on forums where someone had removed the "protection" from GT that checks if install path contains "tekkit". It was months ago so I might very well be mis-attributing that. Sorry for confusion.

The old Zeppelin mod did rotation as well but I'm quite sure it only supported vanilla blocks with it. It also had the "fun" side effect of being able to push non-solid things around like the activated red BC landmark "lasers".

[jakj]

Seems you were right.

http://forums.technicpack.net/threads/gregtech.35411/

I have to say, just wow at that, considering GregTech rips into the internals of all kinds of other mods to rebalance things and then has the audacity to block usage in a pack that didn't even include it in the first place? That actually exceeds Eloraam's hypocrisy, which I didn't think possible. Still doesn't quite piss me off as much as Sengir, though, because at least this was a deliberate and clear message rather than being sneaky and destroying players' worlds.

Fuck him, then. I might still use GregTech for an ultra-hardcore mode eventually, but if I do, I'll be sure to include an obnoxious startup message (that can be disabled in the config, of course) tweaking in return.

EDIT: I just read through the rest of that thread, and my reaction was (and I quote) "pfffffffhahaha". I'm not going to touch that sodding mess with a ten-foot pole, and now I'm glad I never even tried it. I'll stick to non-bullshit mods like TE and IC2.

-----------

Once I get the entity-moving code in, its likely this mod will also be able to move activated BC landmarks and their lasers. I haven't looked at the code, though, so it might break down if there are any assumptions builtin about the location or if the X/Y/Z are cached anywhere instead of always pulled directly from the tile entity.

[Lethosos]

Do what I'm planning on doing and add code to mess with the player's heads whenever GregTech is detected. Me, I'm gonna go the Jesus route and turn all the natural world-genned water sources into wine. :D

[hoho]

@greg, he kind of seems to be an attention seeker to me. It's as if he desperately wants to be included in Tekkit and hopes someone would pay attention to him. It's kind of sad to see that but the mod itself is, to be honest, one of the best tech mods I've used in MC both in terms of huge amount of content and near bug-freeness. It's also nowhere near as difficult as people make it out to be, it even makes several vanilla-IC2 stuff cheaper to get than they are without the mod.

As for the BC landmark moving I think you misunderstood. Zeppelin only moved the lasers beams themselves, not the landmark "torches". At some point I had the laser beams sitting in the sky at 45 degree angle with nothing touching them :)