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

[Spaceshipable]

I would like to, but right now that would be a whole lot of effort to get working and would add a good bit of overhead and extra block changes to the process that make it completely not worth it.

okay just a thought, maybe I'll re-mention it when everything's more stable and the to-do list is looking less long :P

[jakj]

okay just a thought, maybe I'll re-mention it when everything's more stable and the to-do list is looking less long

As it stands now, things like torches do cast a limited amount of light (easiest to see in the middle of the night): They just don't properly propagate that light to all the blocks around them. Hopefully this will get better in the future, but for right now, rendering is pretty decent.

[Lethosos]

Best way I can think of doing it is to throw a second light source a block ahead, move, then remove the first light source.

[jakj]

In case anyone's curious when the next update will be coming, expect it Sunday.

[Lethosos]

Okay, I can hold off putting out a new TTP update. Gives me some time to look over what mods I have already to build the Adventurer's Pack. If Planetguy has any suggestions for that, feel free to shoot me the suggestions in an IM, I don't want to clog this thread up with anything but RiM.

[Spaceshipable]

In case anyone's curious when the next update will be coming, expect it Sunday.

what will the next update include

[jakj]

what will the next update include

Further improvements to mod compatibility, further improvements to in-transit rendering, template carriages showing their pattern, a few bugfixes, decorated carriage blocks stacking properly, and whatever other random little things I throw in there before the end of the day.

[Spaceshipable]

could the decorated carriages somehow show what they're being disguised as when in an inventory? not sure if you could do it in a similar way to how enderchests mod shows the colour assignmet?

[Spaceshipable]

could the decorated carriages somehow show what they're being disguised as when in an inventory? not sure if you could do it in a similar way to how enderchests mod shows the colour assignmet?

[jakj]

could the decorated carriages somehow show what they're being disguised as when in an inventory? not sure if you could do it in a similar way to how enderchests mod shows the colour assignmet?

Yeah, I forgot to mention that: They show their disguise in the inventory, and they also retain their disguise when broken and returning to the inventory.

[Spaceshipable]

Yeah, I forgot to mention that: They show their disguise in the inventory, and they also retain their disguise when broken and returning to the inventory.

Will a disguised carriage be discernible from the block it is disguised as? Maybe the inventory texture could have one face of the block with the carriage block texture and the other two with the disguise block texture?

[Spaceshipable]

like this:

[jakj]

Yes, like that, except it's the top face that's undecorated.

Also, I have just discovered a massive bug with continuous-mode carriages and buildcraft pipes resulting in frequent deletion of items passing through the pipes. I am disabling continuous mode for carriages completely for now, but I will include a configuration option to turn continuous mode back on if you accept the risk or you aren't using buildcraft pipes. (This will default to off, so upon update, all carriages already in continuous mode will immediately stop functioning until the configuraiton option is set to true.)

EDIT: I have discovered the source of this behaviour: Buildcraft adds a deliberate delay to the processing of items after a pipe has been placed down in the world, and if the pipe is moved again before the delay is up, the items in the pipe are lost. I am re-enabling continuous mode, but I am going to impose a minimum of 5 ticks (1/4 of one second) on movement in continuous mode, or as high as 10 ticks (1/2 of one second) if that isn't enough.

[jakj]

You wanted better rendering? Here, have some better rendering. 99% perfect rendering, even.

Shows off the template displaying its pattern, as well as the new-new rendering method.

[Lethosos]

Wow. Sexy work, I'd say it's very close to ready for inclusion in any major modpack.

[jakj]

Wow. Sexy work, I'd say it's very close to ready for inclusion in any major modpack.

It's stupid how easy it was to do, and I was massively overthinking it this entire time. Forest for the trees.

[jakj]

Major update! Rendering is frickin' awesome now, and pretty much everything behaves better. There is a small breaking change (with auto-upgrade, if I did it right), so check the changelog and backup your worlds. In theory, you should be able to run the update and have everything "just work".

New video posted on the front of the thread showing off the new rendering method.

Also, 16x texture sets are in.

http://j-a-k-j.com/RedstoneInMotion_1.2.0.0_mc1.5.zip

https://www.dropbox.com/s/aazxj9dzubz9r6v/RedstoneInMotion_1.2.0.0_mc1.5.zip

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

1.1.1.1 -> 1.2.0.0

-- as usual, do not have any carriages in-transit when you update or you might be sent into a crash loop

-- BREAKING CHANGE -- BACKUP YOUR WORLDS

    ** decorated carriages now internally have a different representation

      ## decorated carriages should now stack properly in inventories in all cases

    ** decorated carriages should automatically and safely convert themselves to the new representation in most cases

      ## this is not guaranteed

      ## the safest place for decorated carriages to be is in the world as blocks

      ## if for whatever reason they fail to convert, they will simply lose their decoration but otherwise be fine

      ## all of this depends on me not having screwed up the conversion code

    ** the conversion code will be removed in a future release, at which point all unconverted decorated carriages will become undecorated

-- unpatterned template carriages will no longer absorb already-patterned template carriages

-- restructured and reordered the removal, simulation, and replacement of blocks and tile entities to improve compatibility and reduce crashing

-- accounted for a crash if a carriage's motor or anchored controller is removed while the carriage is in-transit

-- decorated carriages now render their decoration on all except their top face when in an inventory

-- removed calls to onBlockAdded post-transit to stop vanilla chests from resetting their orientation

    ** this may cause odd behaviours with mods that depend upon onBlockAdded being called

    ** really, though, mods shouldn't depend upon onBlockAdded being called except when the block is being placed by a player or deployer

-- redid rendering again

    ** rendering is now 99.999999999% perfect

      ## transparent blocks draw a tiny bit funny, but they draw!

      ## occasionally there will be a slight variance in light level, but again it's super-close to perfect, including light from torches/lamps/redstone

    ** if the carriages are moving super-fast and the client is super laggy, rendering might bug out after the first motion

      ## this is cosmetic, so just don't worry about it: Not much I can realistically do when Minecraft is already bogged down

-- continuous mode now has a mandatory minimum of 5 ticks of cooldown (1/4 of a second at normal speed)

    ** this is due to rendering and Buildcraft issues, and in case those issues are shared by other mods

    ** this also gives the foolish a chance to escape a carriage in-transit without destroying it in creative mode

    ** WARNING

      ## the issue remains: this is only a workaround

      ## I cannot fix the issue: this is simply how Buildcraft is designed

      ## if you use other means (timers, ComputerCraft, etc.) to move carriages super-quickly, you may trigger the issue and start losing items

-- eliminated error-log spam about missing continuous-mode textures for carriage controllers

-- added 16x texture packs (some of which support colourblindness) provided by various authors - check the textures directories for attribution and redistribution

    ** provide feedback if the textures for colourblindness need tweaking for the purpose

    ** if you want your textures included in the mod, license them openly (WTFPL, CC, GPL, public domain, or compatible) and message me on the Technic site

-- recipes now use the Forge ore dictionary for wooden sticks and for dyes

KNOWN ISSUES

[None at this time.]

PLANNED FEATURES

A config option to let a carriage treat blacklisted blocks as simple obstructions instead of completely aborting the motion.

 

(Possibly) OpenPeripherals support.

 

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.

[daphee]

I cant get the ComputerCraft thingy working. I wrote a program which writes the direction and steps to move in a file then moves one step. In the startup file I read and decrement the counter and again move one step. If I run the program which inits the file my airship moves 2 steps. The init program moves one step. The computer reboots, the startup script moves the platform again but no second reboot. I have to manually click the computer. This is more a CC question then a problem in Redstone In Motion. Somehow CC doesn't recognize a computer running the startup script as "running". If I put another Computer on the same platform it restarts every time.

[jakj]

I cant get the ComputerCraft thingy working. I wrote a program which writes the direction and steps to move in a file then moves one step. In the startup file I read and decrement the counter and again move one step. If I run the program which inits the file my airship moves 2 steps. The init program moves one step. The computer reboots, the startup script moves the platform again but no second reboot. I have to manually click the computer. This is more a CC question then a problem in Redstone In Motion. Somehow CC doesn't recognize a computer running the startup script as "running". If I put another Computer on the same platform it restarts every time.

You'll need to provide a screenshot of your setup, because I can't understand exactly what you're doing just from your description.

[Spaceshipable]

[jakj]

That's Optifine, actually; You can tell because its classes are not in any package but just out bare, in this case, the ConnectedTextures class. Optifine makes all kinds of inappropriate assumptions that break down in a modded environment, especially one like mine that calls rendering functions outside of their normal environment, and I've just learned to have Optifine's connected textures permanently turned off.

[Spaceshipable]

That's Optifine, actually; You can tell because its classes are not in any package but just out bare, in this case, the ConnectedTextures class. Optifine makes all kinds of inappropriate assumptions that break down in a modded environment, especially one like mine that calls rendering functions outside of their normal environment, and I've just learned to have Optifine's connected textures permanently turned off.

On closer inspection I was just about to blame optifine. Would turning connected textures off help possibly?

[jakj]

On closer inspection I was just about to blame optifine. Would turning connected textures off help possibly?

Any time Optifine crashes for me on connected textures, having connected textures off always fixes the crash.

[Spaceshipable]

Would turning connected textures off help possibly?

- solves it

[jakj]

- solves it

Yep, it's a long-standing bug in Optifine, because Optifine makes the assumption that the rendering functions will never be called except by Minecraft itself during the normal rendering cycle.