Jump to content

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


Recommended Posts

Posted

Ok, but it appears some other mods have gotten around this, capaciters from Ender IO for example, keep their energy when broken by a turtle

Oho, that's interesting: I didn't think of them doing that. Apparently, ComputerCraft is calling the "what does this block drop when broken" function *before* actually breaking the block, storing that value, and *then* breaking the block. At least, looking at enderio's code, that's the only possibility I can see. Enderio's capacitor block does an instanceof check (which is also a builtin null check), so if the TE exists, it uses it, and if it doesn't, it continues on.

Okay, I can work with that. I'll make a note to copy enderio's style the next time I do a release. I'm glad you pointed this out to me.

Posted

Oho, that's interesting: I didn't think of them doing that. Apparently, ComputerCraft is calling the "what does this block drop when broken" function *before* actually breaking the block, storing that value, and *then* breaking the block. At least, looking at enderio's code, that's the only possibility I can see. Enderio's capacitor block does an instanceof check (which is also a builtin null check), so if the TE exists, it uses it, and if it doesn't, it continues on.

Okay, I can work with that. I'll make a note to copy enderio's style the next time I do a release. I'm glad you pointed this out to me.

No problem, and also, do you think the multiparts on frames not updating bug will be fixed soon? Most of my frame designs use wireless redstone so this is sort of a huge problem for me, and I assume most users.

Posted

No problem, and also, do you think the multiparts on frames not updating bug will be fixed soon? Most of my frame designs use wireless redstone so this is sort of a huge problem for me, and I assume most users.

Not particularly soon, no: His code is not at all straightforward and it's going to take quite a lot of work to wade through it, hampered by the fact that I'm having to learn Scala on the fly as well as reflect into it from Java. Unfortunately, the amount of work required to get multipart updates working is an order of magnitude greater than that of vanilla updates (which is as simple as looking through a list, pulling out the bits I need and storing them, and then putting them back into the list later).

It's kind of annoying he made it reliant on multipart anyway: It could absolutely have been done without it, with more work on rendering and collision detection and such. Oh well.

Posted

Not particularly soon, no: His code is not at all straightforward and it's going to take quite a lot of work to wade through it, hampered by the fact that I'm having to learn Scala on the fly as well as reflect into it from Java. Unfortunately, the amount of work required to get multipart updates working is an order of magnitude greater than that of vanilla updates (which is as simple as looking through a list, pulling out the bits I need and storing them, and then putting them back into the list later).

It's kind of annoying he made it reliant on multipart anyway: It could absolutely have been done without it, with more work on rendering and collision detection and such. Oh well.

Do you think CB would be willing to help you with this? You mentioned a while ago you were working with him to have multipart support, then you got everything working, including updates, which later got broken.

Posted

Do you think CB would be willing to help you with this? You mentioned a while ago you were working with him to have multipart support, then you got everything working, including updates, which later got broken.

I never had updates working: They were just never an issue before. I don't know exactly which version of his changed the way his blocks worked, but he internalized the updates which meant they weren't passing through vanilla anymore. When I (and CB) were implementing support for multipart originally, it worked without issue.

CB's already helped me enough, and I doubt he'd want to be bothered yet again. It would be awfully nice if he would implement a function that would spit out the updates for me in a nice list, but he's likely got other things to worry about right now. I'll keep messing with it here and there.

Posted

I never had updates working: They were just never an issue before. I don't know exactly which version of his changed the way his blocks worked, but he internalized the updates which meant they weren't passing through vanilla anymore. When I (and CB) were implementing support for multipart originally, it worked without issue.

CB's already helped me enough, and I doubt he'd want to be bothered yet again. It would be awfully nice if he would implement a function that would spit out the updates for me in a nice list, but he's likely got other things to worry about right now. I'll keep messing with it here and there.

OK, do you know any good substitutes for the wireless redstone?

Posted

OK, do you know any good substitutes for the wireless redstone?

There's one by SlimeVoid that might work with Redstone in Motion, but I haven't tested it extensively.

Posted

Slimevoid's worked in the past, but I'm not sure about how stable it is. Netherless, it operates the same with with it being solid blocks instead of multi-part models.

Posted

Looks like the first glimpses of 1.7 are on the horizon, and the new build system is coming out with a full head of steam. I'm starting to take a look at it this weekend, to see how much of a change this will mean in my build scripts.

And in case anyone is wondering, yes, 1.5 will still be supported until people stop playing it: My mod really isn't that complex, and with my new build scripts, it's trivial to support all three at the same time.

Posted

Just a question. I've not been following the development of RiM for a good while now. Does it work with WRCBE? If yes, you do not even need a remote computer on the carriage structure. Just place 2 carriage engines (if you need 6 degrees of freedom), or 1 (if you need 5 or less DOF), and attach their sides to wireless receivers that receive remote signals from a stationary computer. Problem solved. The issue of computercraft's interaction with RiM is only an issue when there are no compatible wireless redstone mods, really.

Posted

Just a question. I've not been following the development of RiM for a good while now. Does it work with WRCBE? If yes, you do not even need a remote computer on the carriage structure. Just place 2 carriage engines (if you need 6 degrees of freedom), or 1 (if you need 5 or less DOF), and attach their sides to wireless receivers that receive remote signals from a stationary computer. Problem solved. The issue of computercraft's interaction with RiM is only an issue when there are no compatible wireless redstone mods, really.

Old versions of WR-CBE work with it, but not new ones. (Basically, versions from about the same time as when I first added multipart support.) New versions do more-complicated things with block updates that I don't support yet.

SlimeVoid's might or might not work; I have no idea.

You are correct about moving computers being unnecessary with a working WR mod.

Posted

Old versions of WR-CBE work with it, but not new ones. (Basically, versions from about the same time as when I first added multipart support.) New versions do more-complicated things with block updates that I don't support yet.

SlimeVoid's might or might not work; I have no idea.

You are correct about moving computers being unnecessary with a working WR mod.

I could even find an updated download for slimevoids. You can create a ghetto wireless redstone setup with enderchests, comparators, and things of the sort. I am gonna try to get into modding in 1.7, I know a bit of java but I have never used forge before so I have no idea how hard it will be. But I am going to try to add some none multipart wireless redstone, that will possibly be able to hold more then one signal.

Posted

I could even find an updated download for slimevoids. You can create a ghetto wireless redstone setup with enderchests, comparators, and things of the sort. I am gonna try to get into modding in 1.7, I know a bit of java but I have never used forge before so I have no idea how hard it will be. But I am going to try to add some none multipart wireless redstone, that will possibly be able to hold more then one signal.

There's a 1.6.4 version of Slimevoid's WR: http://slimevoid.net/downloads/

Posted

The server im playing on is having problems with log spam and such due to your frames, and according to the admin, conduits from TE3. heres the error logs-

http://pastebin.com/xVfhyviw

hopefully you can fix it, your mod is awesome, and i want it back on our server :D

That's the Buildcraft reflection code erroring out. It's harmless: It just means Buildcraft pipes behave strangely and don't re-initialize immediately (takes a quarter of a second) after motion, which is a problem only if you're trying to shove things into them immediately after motion.

Go in your config on the server:

"Dirty Hacks" {

    B:"Attempt to hyper-reinitialize Buildcraft pipes after motion"=true

}

Change that to "false".

Posted

Is it out of reasonable technical possibility to make it possible to attach template carriages to other types? I have no doubt that would be very complex, but template carriages are the most flexible for making strange or compact shapes, but are also significantly more complex to move in more than one direction.

Posted

Is it out of reasonable technical possibility to make it possible to attach template carriages to other types? I have no doubt that would be very complex, but

Possible, but a massive amount of work, not proportional to the amount of benefit gained by the effort.

template carriages are the most flexible for making strange or compact shapes, but are also significantly more complex to move in more than one direction.

Explain.

Posted

I think he means that you only have one block to work with, as opposed to other carriage types, where you can attach a second or a third engine/motor/controller to any other carriage in the contraption. However, I don't really think it's a problem unless you design REALLY small stuff, and even then, a template carriage is more compact than any other one in almost every circumstance.

Posted

I think he means that you only have one block to work with, as opposed to other carriage types, where you can attach a second or a third engine/motor/controller to any other carriage in the contraption. However, I don't really think it's a problem unless you design REALLY small stuff, and even then, a template carriage is more compact than any other one in almost every circumstance.

So have multiple templates that overlap so you can have as many anchors as you need. Each anchor can include the other anchors to move them. You can assemble them all with a slight separation so you can establish the full patterns, then use a single-block secondary carriage to push them into place so they move without being triggered or losing their pattern.

I think they are plenty powerful enough to justify a little extra effort for such a limited application.

Posted

Yeah, pretty much what Viktor said. After messing with it further though, I think having wireless redstone working with it would mitigate basically all of the problems I was having, and would open up a lot of other possibilities as well. Is renewed compatibility on the road map or is it waiting on changes from FMP/WR?

Posted

Yeah, pretty much what Viktor said. After messing with it further though, I think having wireless redstone working with it would mitigate basically all of the problems I was having, and would open up a lot of other possibilities as well. Is renewed compatibility on the road map or is it waiting on changes from FMP/WR?

I'll get it going at some point: I'm just being lazy right now. Mostly waiting on the first prereleases of MCP/Forge/Gradle/Whateverthefuck for 1.7 to come out, most likely within a week, to see what we're up against. With Lex/CPW being on a "this is the right way to do things, deal with it" kick and Searge becoming a Mojang employee, 1.6 was the last "modding as we know it".

Posted

Whatever do you mean? Is the official mod API finally coming?

No, Forge is switching to the Gradle build system and working on dumping MCP because Searge will no longer be developing MCP after the current version because he's working for Mojang and they're (slowly) working on the official API (for whatever that will be worth) which will change the way deobfuscation does at all. Searge has refused to discuss it publicly, working directly with Forge instead.

It's good in a way, because only an idiot could expect Searge to still be allowed to develop what is in effect a hacking tool for the software made by the company of his own employ, so we were going to lose MCP anyway unless somebody forked it, but the Gradle transitiion and AbrarSyed's stuff *should* make that not necessary. It's kind of...absorbing MCP, almost like the converse of Borg assimilation.

Posted

No, Forge is [...] working on dumping MCP because Searge will no longer be developing MCP after the current version because he's working for Mojang

Do you have a source for that, or might you be mixing up MCP with ModLoader? Because the last newspost on the MCP site says:

And for those of you who are worried about the future of MCP, I can assure you that it won't be abandoned or stopped anytime soon. As long as we have a need for MCP, it will be updated for new Minecraft releases. Me joining Mojang as a fulltime developer on Minecraft does not change anything for MCP

And the last release news on the forge forums says:

This is the last supported build for 1.6.4 with ModLoader compatibility.

But makes no mention of MCP going away.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...