jakj Posted November 18, 2013 Author Posted November 18, 2013 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.
Jyzarc Posted November 18, 2013 Posted November 18, 2013 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.
jakj Posted November 18, 2013 Author Posted November 18, 2013 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.
Jyzarc Posted November 18, 2013 Posted November 18, 2013 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.
jakj Posted November 18, 2013 Author Posted November 18, 2013 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.
Jyzarc Posted November 18, 2013 Posted November 18, 2013 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?
planetguy Posted November 19, 2013 Posted November 19, 2013 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.
Lethosos Posted November 19, 2013 Posted November 19, 2013 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.
Paintpauller Posted November 19, 2013 Posted November 19, 2013 not tested yet but you should be able to use http://www.computercraft.info/forums2/index.php?/topic/6634-cc-155mc-162-gophers-peripherals-v21-biolock-new-keypad-locks/ and the PRBs that come with it as a kind of wireless redstone till multipart support comes back!
jakj Posted November 21, 2013 Author Posted November 21, 2013 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.
Viktor_Berg Posted November 21, 2013 Posted November 21, 2013 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.
jakj Posted November 21, 2013 Author Posted November 21, 2013 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.
Jyzarc Posted November 22, 2013 Posted November 22, 2013 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.
Panzer04 Posted November 22, 2013 Posted November 22, 2013 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
Viktor_Berg Posted November 22, 2013 Posted November 22, 2013 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/
jakj Posted November 22, 2013 Author Posted November 22, 2013 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 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".
Hobo Joe Posted November 23, 2013 Posted November 23, 2013 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.
jakj Posted November 23, 2013 Author Posted November 23, 2013 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.
Viktor_Berg Posted November 25, 2013 Posted November 25, 2013 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.
jakj Posted November 25, 2013 Author Posted November 25, 2013 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.
Hobo Joe Posted November 26, 2013 Posted November 26, 2013 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?
jakj Posted November 26, 2013 Author Posted November 26, 2013 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".
Viktor_Berg Posted November 26, 2013 Posted November 26, 2013 Whatever do you mean? Is the official mod API finally coming?
jakj Posted November 26, 2013 Author Posted November 26, 2013 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.
Sangar Posted November 26, 2013 Posted November 26, 2013 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.
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now