From what i saw on the modlist of beyond reality it isnt a ultimate like modpack. I dont like it because it looks too easy to progress and that is not accepteble in my opinion.
I will need to load up the pack "beyond Reality" I believe they made changes to remove the GT ores a few versions ago. I will look to see if its still like that. Most of GT new ores are but ores that have by products that make iron, copper, tin...ect. I belive the ore Gen is only when GT is on Hard mode.... or there even might be a way to disable in the configs. Sadly Resurrection was configured to be the way it is... not sure if it would break that pack[DOUBLEPOST=1421691917,1421691698][/DOUBLEPOST] It has been tweaked heavily like TDT was. Download it and test it.
I believe their is a server side fix for ore gen and gregtech, but it would require a complete map reset. I'll post the link and info when I get home
I'm in favor of the following in order of preference: 1. Axxxon's idea about trasitioning to an ore-less build world. I already do all my mining in the farm world anyhow. 2. Whitelisting. As long as it's easy to draw in fresh players and the whitelist is frequently updated, this would be a nice compromise. 3. Leave it be. Works okay for me, most days and I don't mind the pain the few times it doesn't.
Well a system was mentioned above that could over time select differn't region files /chunks and remove blocks, if it can do that you can replace the GT block ids with ic2 ones. Potential problem is it selecting GT machines, so it would have to specify target IDs
May have to keep them. However the ores that ic2 does not have are much more rare and smaller veins so it would make a good impact but not remove the whole problem. edit- fixed typos, wrote the original on a iPhone.
Would someone be so nice and create an id list e.g.: Code: | Ore | GT ID | IC2 ID | |------------------|-------|--------| | Iron | 533 | 943 | | GT only ore name | 544 | x |
Whoever makes the item list be sure to list the GT ores that ic2 doesn't replace like naquadah etc. If nobody wants to I might be able to.
I'm curious if this is compounded by a default chunk loading radius? I don't know how MyM servers are set up, but to memory, vanilla Minecraft's default radius is 10, so 20x20 or 400 chunks loaded around each player. Last I had read, it was possible to reduce this radius. Any chance this would help?
the thing is that it is the loading/unloading, while reducing might help a bit due to less chunks getting loaded/unloaded when traveling the change might not even be noticeable. I'll check on what the setting is and when it is high I'll reduce it to 4 chunks, which is more or less the default value on most "bigger" servers.
I don't know about 4 chunks thats only 64 blocks either direction, id say at least 6 chunks minimum (64% decrease in chunks visible).[DOUBLEPOST=1422310130,1422310079][/DOUBLEPOST]Ill also go ahead and make the item list to replace GT ores.[DOUBLEPOST=1422499643][/DOUBLEPOST]i'll have the item replacement list done this weekend, busy with work and the game itself lol.
today i came across neat mod. Maybe give it a try? make a lag test for hour or something (aka mass test) to see if that works or not, or how could it affect gt stuff.. Stjerncraft - Tick Dynamic - Home
cauldron support requested by us, tested on direwolf. Not useable atm for us. Why? Server is on 10 tps, enabling the mod puts it back on 12-14 tps. But all machines are useless as tile Ents get ticked down to only tick every 80th tick. (0,25tps for machines) Our issue is not the tile ents them self, it is more the amount of tile ents causing long tick times with chunk unloads(tileEnts being removed from the tileEnt list). We did also try to setup it up in manner where machines are still useable (at least 5 tps on machines), but the performance difference was not noticeable and a few things like magnetic dynamos didn't work anymore.
I'll have that item replacement list done in a day or so, if we are able to replace GT ores with ic2 ores which shouldn't be tile entities it may help significantly.
