Ran into a little problem with the IC2 component. Worked to go to the Nether at our main base. We made a second base around 6000 meters away set up another IC2 power source and stargate, it lets us go to other gates in the overworld, but says it doesn't have enough energy to go to our Nether gate. The IC2 thing is fully charged and has plenty of power running to it. Is this due to the distance multiplier exceeding the storage capacity of the IC2 component?
I've been running 1.1.0 with forge 10.12.1.1060 with no issues, never experiencing the issue where all my blocks were deleted. It was set to generate stargates, too.
Since I wasn't having that issue, I didn't download the 1.1.1 update.
I did just update to the 1.2.0 version so that generated stargates would be the 9 chevron type, and now I am having the issue where the warning pops up that all the blocks are being deleted and then the world loads up empty.
Is there anyway I can continue using that save with the updated mod?
says it doesn't have enough energy to go to our Nether gate... Is this due to the distance multiplier exceeding the storage capacity of the IC2 component?
It could be. I just did some calculations, and it seems the energy requirement for very long range connections can exceed the capacity of a single power unit.
You're supposed to be able to connect multiple power units, but I just looked at the code for that and it appears to be buggy. I'll upload a fix soon.
In the meantime, you could try reducing interDimensionMultiplier in the config file.
I did just update to the 1.2.0 version so that generated stargates would be the 9 chevron type, and now I am having the issue where the warning pops up that all the blocks are being deleted and then the world loads up empty.
That's very strange. The only way I can think of that happening is if you upgraded to a new version of Forge. ran your world once and saved it, and then intalled SGCraft 1.2.0.
What happens if you create a new world with SGCraft 1.2.0? Does the issue still occur?
Is there anyway I can continue using that save with the updated mod?
No, once the world has been saved in that state it's permanently broken, I'm sorry to say. (It might be possible to repair it with a low-level tool such as NBTExplorer, but I have no experience with such tools and can't give you any help with that.)
That's very strange. The only way I can think of that happening is if you upgraded to a new version of Forge. ran your world once and saved it, and then intalled SGCraft 1.2.0.
What happens if you create a new world with SGCraft 1.2.0? Does the issue still occur?
I can create new worlds with no issues. I had upgraded to Forge 10.12.1.1060 a couple weeks ago and had been using that version of forge with SGCraft 1.1.0 since then (at least until yesterday) so I'm sure I've opened that save more than once with the Forge 10.12.1.1060/SGCraft 1.1.0 combo before I upgraded to SGCraft 2.1.0. I'm not sure if that really matters though, as I am illiterate in programming language.
Either way, I do have back-ups of that save that I can load if I downgrade back to 1.1.0. I can use schematica to save any structures that I want to keep and then update the mod and start a new world.
I do have back-ups of that save that I can load if I downgrade back to 1.1.0.
If you have a working backup, you should be able to load it using SGCraft 1.2.0 + Forge 1060 and re-save it, and things should be all right after that. I don't think you should have to start a new world.
Still enjoying the mod! A few friends and I have made it pretty permanent on our small private servers.
Just a suggestion and I have no idea how much trouble this would cause and I would hate for things to get ruined, but the Gate itself is a little small. I think a 7x7 gate would be the right size, and is close to the 6.7 meter diameter of the stargate from the series. In the show multiple people comment on how "it's bigger than I thought it would be" and I just don't get that feeling in game.
Again, small detail and if it is something that screws the whole mod up than I would rather it stay as is.
Also I know the Lanteacraft gate is 7x7 and I have tried it, and it does have nice textures and a good size, but yours just seems to run better in general and that is more important to me.
"Is this mod quite self contained? As in it should be comparable with pretty much anything?"
Versions earlier than 1.1.1 are known to be incompatible with Biomes 'o' Plenty, and potentially with other mods that hack world generation. There was supposed to be a config option to disable that feature, but it didn't work properly until recently.
I don't know of any other incompatibilities, but the only way to find out for sure is to try it.
The main problem with making the gate bigger is that a round ring of that size wouldn't match up very well with the collision boxes of a square pattern of ring blocks. There are probably ways of tackling that, but it would take a fair amount of work and it's not high on my list of priorities at the moment.
The main problem with making the gate bigger is that a round ring of that size wouldn't match up very well with the collision boxes of a square pattern of ring blocks. There are probably ways of tackling that, but it would take a fair amount of work and it's not high on my list of priorities at the moment.
I have a small sugestion for that. I thing you need to make some sort of pattern where sides of the blocks are touching each other, right?
So, lets make a pattern like this:
Well I have no idea, how exactly multiblock structures works, but this should be able to create structure like gate since all blocks are connected. Now, instead of green wool blocks, there will be some new blocks without collision boxes(or maybe stairs might work?). These blocks might represent for example some sort of support strats during a gate building, or scaffolding. (Chevron positions in this pattern match quite well with current gate model without chevron upgrade.)
But then again, I don't know if it is possible to make multiblock stractures where half of the blocks have collision boxes and the other half doesn't.
Sorry if this isn't helping in any way.
p.s.
Talking about scaffolding. Just to let you know, IC2 scaffold can't be placed on SG blocks for some reason. I don't know if you can do something about it, though.
Rollback Post to RevisionRollBack
"On the Internet, you can be anything you want. It is strange so many people choose to be stupid."
The Meaning of Life, the Universe, and Everything.
Join Date:
1/19/2014
Posts:
132
Member Details
Maybe I'm missing something, but it appears you've just taken the current number of blocks and added a few blocks to make gate construction unnecessarily complex. Your example doesn't make the gates larger it just makes them harder to assemble. Am I missing something?
Maybe I'm missing something, but it appears you've just taken the current number of blocks and added a few blocks to make gate construction unnecessarily complex. Your example doesn't make the gates larger it just makes them harder to assemble. Am I missing something?
Current size of the gate is 5x5, this is basically 7x7.
EDIT: Current gate uses 16 connected blocks, my pattern uses 24.
Turns out that it was my fault, but in a very subtle way that took ages to track down. I've now uploaded version 1.1.1, which should fix it.
I've tested regenerating a new world in the latest version (1.3) and saving/reloading the game, etc. Looks like it's working properly
This test was run both with and without Biomes o Plenty enabled, so it looks like compatibility with worldgen mods is OK too! I suspect the bug I reported earlier was merely an extension of the block Id issue which now appears fixed,
I'm an aspiring modder, and I was curious as to what caused the block ID issue in the first place so I can avoid doing something similar myself. If you don't mind sharing that is.
I'm an aspiring modder, and I was curious as to what caused the block ID issue in the first place so I can avoid doing something similar myself. If you don't mind sharing that is.
That's a long and interesting story! The short answer is: Never put any classes in your jar file whose package name is under the minecraft.* hierarchy.
If you're wondering why anyone would want to do such a thing, in my case it was because I needed to access some protected fields for some of the world generation stuff I was doing, and the easiest way to do that was to create a class in the same package as the class whose fields I wanted to access.
That used to work fine, but something changed in a recent Forge build concerning the way it figures out the names that things are registered under. When you register a block or item, the name you supply gets prefixed with the ID of your mod. The way it tells which mod is doing the registering is to look down the call stack to see where the call is coming from. So that it can do that, when it loads a mod it scans the jar file and records the package names of all the classes it finds as belonging to that mod.
If you have a class called "minecraft.something.MyClass" in your jar file, it gets the idea that all code in all classes in the minecraft.something package belongs to your mod. That in itself wouldn't necessarily cause a problem, but when it loads a world it re-registers all the blocks and items with the ID numbers appropriate for that world. The re-register call isn't made from inside any mod, so normally it doesn't add any extra prefixes. But if it's under the delusion that some of the base Minecraft code belongs to your mod, it ends up adding a spurious prefix, and hilarity ensues.
So, the moral is: Always put all your classes under a package name unique to your mod. This was always recommended, but now it seems to be mandatory. If you need to access protected fields, use reflection.
I'm having trouble getting IC2 to work with this. Which version is it that you used for SGcraft 1.3.0? I've had this problem before when I didn't have the right version of IC2 installed even if it was made for the proper minecraft version.
Rollback Post to RevisionRollBack
Read the latest pages before you ask something, you might save yourself some trouble.
I took down godzilla from the godzilla mod with vanilla gear and only lost ~17000 HP.
Turns out that it was my fault, but in a very subtle way that took ages to track down. I've now uploaded version 1.1.1, which should fix it.
I've been running 1.1.0 with forge 10.12.1.1060 with no issues, never experiencing the issue where all my blocks were deleted. It was set to generate stargates, too.
Since I wasn't having that issue, I didn't download the 1.1.1 update.
I did just update to the 1.2.0 version so that generated stargates would be the 9 chevron type, and now I am having the issue where the warning pops up that all the blocks are being deleted and then the world loads up empty.
Is there anyway I can continue using that save with the updated mod?
It could be. I just did some calculations, and it seems the energy requirement for very long range connections can exceed the capacity of a single power unit.
You're supposed to be able to connect multiple power units, but I just looked at the code for that and it appears to be buggy. I'll upload a fix soon.
In the meantime, you could try reducing interDimensionMultiplier in the config file.
That's very strange. The only way I can think of that happening is if you upgraded to a new version of Forge. ran your world once and saved it, and then intalled SGCraft 1.2.0.
What happens if you create a new world with SGCraft 1.2.0? Does the issue still occur?
No, once the world has been saved in that state it's permanently broken, I'm sorry to say. (It might be possible to repair it with a low-level tool such as NBTExplorer, but I have no experience with such tools and can't give you any help with that.)
I can create new worlds with no issues. I had upgraded to Forge 10.12.1.1060 a couple weeks ago and had been using that version of forge with SGCraft 1.1.0 since then (at least until yesterday) so I'm sure I've opened that save more than once with the Forge 10.12.1.1060/SGCraft 1.1.0 combo before I upgraded to SGCraft 2.1.0. I'm not sure if that really matters though, as I am illiterate in programming language.
Either way, I do have back-ups of that save that I can load if I downgrade back to 1.1.0. I can use schematica to save any structures that I want to keep and then update the mod and start a new world.
Thanks for the response!
If you have a working backup, you should be able to load it using SGCraft 1.2.0 + Forge 1060 and re-save it, and things should be all right after that. I don't think you should have to start a new world.
Just a suggestion and I have no idea how much trouble this would cause and I would hate for things to get ruined, but the Gate itself is a little small. I think a 7x7 gate would be the right size, and is close to the 6.7 meter diameter of the stargate from the series. In the show multiple people comment on how "it's bigger than I thought it would be" and I just don't get that feeling in game.
Again, small detail and if it is something that screws the whole mod up than I would rather it stay as is.
Also I know the Lanteacraft gate is 7x7 and I have tried it, and it does have nice textures and a good size, but yours just seems to run better in general and that is more important to me.
It seems a number of mod authors are waiting for 1.8 before they update and will just skip 1.7.
Versions earlier than 1.1.1 are known to be incompatible with Biomes 'o' Plenty, and potentially with other mods that hack world generation. There was supposed to be a config option to disable that feature, but it didn't work properly until recently.
I don't know of any other incompatibilities, but the only way to find out for sure is to try it.
The main problem with making the gate bigger is that a round ring of that size wouldn't match up very well with the collision boxes of a square pattern of ring blocks. There are probably ways of tackling that, but it would take a fair amount of work and it's not high on my list of priorities at the moment.
I have a small sugestion for that. I thing you need to make some sort of pattern where sides of the blocks are touching each other, right?
So, lets make a pattern like this: Well I have no idea, how exactly multiblock structures works, but this should be able to create structure like gate since all blocks are connected. Now, instead of green wool blocks, there will be some new blocks without collision boxes(or maybe stairs might work?). These blocks might represent for example some sort of support strats during a gate building, or scaffolding. (Chevron positions in this pattern match quite well with current gate model without chevron upgrade.)
But then again, I don't know if it is possible to make multiblock stractures where half of the blocks have collision boxes and the other half doesn't.
Sorry if this isn't helping in any way.
p.s.
Talking about scaffolding. Just to let you know, IC2 scaffold can't be placed on SG blocks for some reason. I don't know if you can do something about it, though.
Current size of the gate is 5x5, this is basically 7x7.
EDIT: Current gate uses 16 connected blocks, my pattern uses 24.
Oh...duh. Apparently I can't count.
I still don't like the more complex assembly, though. I'm guessing that's probably why LanteaCraft went with a 9x9 (?) layout for the bigger gates.
As a side note - although I like the bigger gates, I think the Ewing gates look more 'minecrafty'
I've tested regenerating a new world in the latest version (1.3) and saving/reloading the game, etc. Looks like it's working properly
This test was run both with and without Biomes o Plenty enabled, so it looks like compatibility with worldgen mods is OK too! I suspect the bug I reported earlier was merely an extension of the block Id issue which now appears fixed,
I'm an aspiring modder, and I was curious as to what caused the block ID issue in the first place so I can avoid doing something similar myself. If you don't mind sharing that is.
That's a long and interesting story! The short answer is: Never put any classes in your jar file whose package name is under the minecraft.* hierarchy.
If you're wondering why anyone would want to do such a thing, in my case it was because I needed to access some protected fields for some of the world generation stuff I was doing, and the easiest way to do that was to create a class in the same package as the class whose fields I wanted to access.
That used to work fine, but something changed in a recent Forge build concerning the way it figures out the names that things are registered under. When you register a block or item, the name you supply gets prefixed with the ID of your mod. The way it tells which mod is doing the registering is to look down the call stack to see where the call is coming from. So that it can do that, when it loads a mod it scans the jar file and records the package names of all the classes it finds as belonging to that mod.
If you have a class called "minecraft.something.MyClass" in your jar file, it gets the idea that all code in all classes in the minecraft.something package belongs to your mod. That in itself wouldn't necessarily cause a problem, but when it loads a world it re-registers all the blocks and items with the ID numbers appropriate for that world. The re-register call isn't made from inside any mod, so normally it doesn't add any extra prefixes. But if it's under the delusion that some of the base Minecraft code belongs to your mod, it ends up adding a spurious prefix, and hilarity ensues.
So, the moral is: Always put all your classes under a package name unique to your mod. This was always recommended, but now it seems to be mandatory. If you need to access protected fields, use reflection.
Read the latest pages before you ask something, you might save yourself some trouble.
I took down godzilla from the godzilla mod with vanilla gear and only lost ~17000 HP.
The one I've ben using is 2.1.425-experimental.
Ok thank you I recommend putting that in with your change log so people know which IC2 version to use.
Read the latest pages before you ask something, you might save yourself some trouble.
I took down godzilla from the godzilla mod with vanilla gear and only lost ~17000 HP.