Viktor_Berg

Could you elaborate on this new API, please? What are the planned features?

Which could be a while, since CB refuses to release his mod until RP2 is updated. Some people just can't let go...

There is a Wireless Redstone mod that is not by Chickenbones (and is also older than his mod). It doesn't appear to exist for 1.5.2, though, so I dunno.

I am now realizing that there really is not that much need for this feature, especially considering 3rd party deployers and breakers. However, one of the biggest reasons I'd have for using a stationary motor in such a situation would be precision control. Elevators are typically complex systems that have controls located at every floor (for calling the elevator), as well as on the elevator itself. If the master computer is situated on the elevator itself, it can lead to all sorts of complications if running the program and performing simultaneous actions across several computers (as can happen in SMP). Moreover, there's the issue of chunk load/unload and game reload. All sorts of issues can appear if reloading a save where the elevator was in mid-motion - and such issues are easier resolved if the motor controls are rooted firmly into the world. Then again, if this can be adequately solved with breakers and deployers from other mods, then this request is redundant. I just can't come up with any mods that actually have deployers... [EDIT]: how often does a continuous-mode carriage ENGINE check for redstone pulses? Since it moves together with the carriage itself, I assume it only writes to world once every movement, or once a second, for maybe a tick or two?

How about a feature to deploy or remove carriages as the structure moves along? Think block breakers and deployers from RP2. Sometimes one would want the carriage structure to have a variable shape, depending on how far out it is extended. This is particularly noticeable with elevators that use carriage motors - the "arm" that is interfacing against the motor has to become longer and longer as the elevator platform moves away from the motor. If your building is tall, hiding that arm would become a problem in and of itself. Of course, there's the possibility of using carriage engines instead, but sometimes a stationary control unit is preferred due to various reasons.

Don't forget that BC serves as an early-game item transport system, and is also a framework for Logistics Pipes.

I believe he'd have to go through Spacetoad to get the permission to close the source. I am not entirely sure on that, though.

So now CJ's fucking around with mods that weren't even his to begin with. I'm getting tired of this shit, we don't need any more fucking energy systems, stop that.

RedNet and white/blackstone by PowerCrystals, as well as glowstone illuminators by King Lemming. So pretty much everything except blutricity (which wasn't that good, let's be honest) has been replicated in other mods. As for modpack permissions:

Because one of the most popular frame contraption types are all forms of air- or spaceships. Then there are the mobile housing and workshop platforms. Such contraptions typically require player movement, and their nature usually involves long periods of continuous movement in one or different directions. By no means do I say that free movement is an absolute necessity, especially considering the amount of issues it brings. But you have to understand. People will invariably compare this mod to RP2 frames. It already has far more than RP2 ever provided. But sometimes small issues such as movement can completely deter people from using them, if they used these sorts of contraptions for something that necessitated movement while in transit. I simply do not wish for this mod to fall into obscurity after 5 people download it.

jakj, you've probably been bothered by many people about this, but is there any remote chance in the future to ever unchain the player movement on top of a moving carriage? I'm asking that because somehow, RP2 managed that. It didn't always work perfectly (sometimes embedding the player halfway in a block, or else just phasing him through it), but it still was better than absolute translational immobility. I understand your concern about non-player entities phasing through and causing all sorts of problems. But surely you can make an exception for players, with a small disclaimer on the mod page that you are no responsible for incidents if moving on top of moving carriages? This is especially important for your mod, considering the dangers of getting stuck in continuous mode, exactly how you explain it on your mod page.

Wonderful! Crystal cores behave extremely well when coupled with the carriages! I will be testing more of the Thaumcraft stuff and see how well it goes. [EDIT]: is there no spoiler tag on this forum? I wanted to hide the image in spoiler tags.

Oh, so the template is properly moved only when it's the one actually triggered by the engine. Alright, I see. I don't think there are many situations where you need to combine the different kinds of carriages anyway.

So the template carriage will be moved by the support carriage, and all the configured template blocks will move along with the carriage as a result? That should accomplish what is needed from that, thanks.

Will we be able to combine different types of carriages? Imagine a support carriage that also carries with it a template carriage (which has a custom template stored in it). I assume all it would take to implement would be to allow the carriages to be connected to other carriages for moving purposes, and not just engines. Also, would it be possible to interface Carriage Engines to CC, so that we'd avoid having to build worm drives to have CC-controlled vehicles?

The game reload and chunk load/unload has always been a thing, and the second one can be avoided by using 2 independently moving chunk loaders (which I have used previously, for my long-range Thaumcraft aura node moving machine). Speaking of which, I will have to do some testing with the TC3 crystal core. RP2 frames were very interesting in handling it. If the whole obelisk/core structure was encased in frames properly, it could move the core without disabling its tractor beam. Also, the core remained affixed to one single node, even after moving it with frames. It would not move any other node but the one it was originally set to move. Also, I suppose you have a point about using CC as a simple relay, but again, it could potentially lead to lag problems in the program execution. I dunno, I'll have to experiment with this, too.

On the part of CC, the only thing that needs to be figured out is avoiding the restart. It was done in RP2 somehow, and that's what saved the RP2 frames for me. I would never bother to learn stack-based programming to use RP2 computers with frames (I am way too lazy for that), and logic gates become increasingly irrelevant as the structure increases in complexity. Thus, a properly working CC (i.e. one that does not go into restart every time it's moved) is incredibly handy.

First of all, wow, you were on the very edge of necroing this thread, 2 weeks. You have good timing, sir. Second, I doubt anyone's willing to add Railcraft to their modpack, because of that retarded invisible block that CJ added, which breaks so much stuff. It can be disabled in configs, but is still pretty terrible, not least because CJ refuses to do anything about it.

I know complete CC integration is not your top priority, but considering how complex builds and machinery can become once you include frames/carriages, an advanced form of control like CC is almost a necessity. I mean, I could make a system where there is a rooted computer acting as an intermediate storage for all the variables in the moving one (using CC rednet to send and receive the set of variables to keep the program working), but honestly, it's an ad-hoc solution, and is definitely not quick/responsive enough for some builds. I do not, by any means, attempt to put pressure on you, but am just begging you to reconsider this matter. As for the ghost blocks, will they be visible any time a block is not present in the given position? Would be nice in case you want to repair your structure after it's been build and then blown up by TNT/creepers/whatever, or if you want to change the material of the structure. Finally, I just found an interesting contestant for the RP2 frame replacement: http://www.minecraftforum.net/topic/1852349-truss-mod-rp2-style-frames/ It's not NEARLY as functional as your delicious carriage system, but I think it looks pretty fancy anyway, and you might be able to pick up some tips there, I dunno.

jakj, this has been mentioned in this thread before, but I'll just repeat it here. Nobody knows how, but RP2 frames did not reset the CC computers when moving them. It might have changed since 1.4.7 (when I was able to do it on an SMP server), but somehow, I doubt it. Also, are you planning on implementing transparent ghost blocks for the template carriages?

The ME network is, indeed, an endgame storage alternative. It is a bit too pricey in terms of materials and energy to use early/mid-game. However, it is much more than just item storage and transport. I suggest you look at Direwolf's spotlight to learn the true potential of the mod. As for early-game item transport, you can use MFR conveyor belts. They are not as flexible (for instance, they cannot transport items vertically upwards, only at a slope), but are still pretty cool. Also, if I remember correctly, the new release candidate for Tekkit (1.1.5 I believe) includes Logistics Pipes, which are the mid-game smart routing system you might be looking for.

I've actually posed this very question to Algorithm on MCF. He told me that starting with v11, it becomes possible to feed items from an interface into another interface, thus enabling the use of AE subnetworks for more complex crafting setups. This is what he posted: And the description:

They are also affected by Fortune on the axe. Fortune 3 will get you on average about 2 rubber per log.

I respect your opinion, but humbly disagree. Thaumcraft has everything to do with magic, it's just not the magic type where you pew pew spells out of your hand.

Ah, right. Though, I personally dislike dimdoors because of how boring the inside of the dimensional pockets is. Now if someone invents something like the Star Trek holodecks, so that we can have nice panoramic sunny day windows inside our pockets (or underground), I'd be all over that thang.