[GregTech-5][1.7.10-FORGE-1355+][Unofficial but approved Port][Stable] Even GT5 Experimental is slowly getting stable.

Quote from Blood Asp

I'm still not sure if i really understand what you want.

For example: more better and faster loading million object in array lists.

can not handle millions of objects at the start to be a long, other projects and even more games load more quickly, and objects.

Quote

GT is allready as optimized and multithreaded as possible. It is just so much bigger than other mods

this is not enough. Looking at the result - we have to work on the code and work. Do not user should wait for 3 minutes or more to any processing of mod, he should not see them at all. Maincraft runs without forge much faster than this mod for example.

Quote from GregoriusT

Note that the GT Q/A explicitly states not to complain about loading times unless you have a probably working solution, or else you will get banned. And all you said is "OTHER STUFF LOADS FASTER MAKE IT LIKE THEM", where the truth is that those people, of who you say they make faster things, actually make much slower things, so using them would mean a massively increased loading time. GT does that many checks on things (and the 5900000 are the List alternative using 25 Minutes rather than 1 Minute, it is actually way less checks in real GT) because there are MANY THINGS. It is like saying "MAKE IT LESS CARS ON THE STREET" instead of "MAKE CARS FASTER"

I'm not complaining, I ask, knowing that it is a fast Java language, a natural question arises. Most of the problems in mods and in the game lies in the code, not the power of iron. When A majority of users with very different characteristics of the final device is about the same code is executed, and there is almost no device where the execution takes place not long on the eyes, the output of who to contact problem is obvious.
I analyze some of the mods is long the total download time and trying to understand why for a long time, if you can do faster? Your mod uses a lot of people around the world, you do not care that it does not run as fast as we would like?

I tell people that my modpack runs long and they want him to run for a large number of mods no more than 3-4 minutes(my modpack start ~12min now, and the newer versions of mods the longer the start time). And try to explained to them that I am not to blame that the processing of a large number of objects takes a lot of time and have to wait. Instead, they simply go play other games instead of playing the Mincraft modpack(s).

Simply put there is the loss of users or target(telic) group.

I understand that mod is good, interesting and fascinating, but it is necessary for each user are explained?

Quote from Bogdan-G

I'm not complaining, I ask, knowing that it is a fast Java language, a natural question arises. Most of the problems in mods and in the game lies in the code, not the power of iron. When A majority of users with very different characteristics of the final device is about the same code is executed, and there is almost no device where the execution takes place not long on the eyes, the output of who to contact problem is obvious.
I analyze some of the mods is long the total download time and trying to understand why for a long time, if you can do faster? Your mod uses a lot of people around the world, you do not care that it does not run as fast as we would like?

The thing you're missing is that the code isn't running slow. Its just doing a lot more work.

Thermal Expansion may seem to be running faster, but only because it has to setup a few mechanics. As a result it doesn't even have similar optimization code because there's so little work to do.

By way of contrast, GT has to set up millions of mechanics. There is far, far more work being done. If it used the TE logic to do it, it would take far longer.

The only way to get what you want the way you're suggesting it is to actually remove GT content. Maybe get rid of most of the materials or something. But that's not very fun for anybody.

Quote from Pyure

The thing you're missing is that the code isn't running slow. Its just doing a lot more work.

Thermal Expansion may seem to be running faster, but only because it has to setup a few mechanics. As a result it doesn't even have similar optimization code because there's so little work to do.

By way of contrast, GT has to set up millions of mechanics. There is far, far more work being done. If it used the TE logic to do it, it would take far longer.

The only way to get what you want the way you're suggesting it is to actually remove GT content. Maybe get rid of most of the materials or something. But that's not very fun for anybody.

Display More

Oh.. remove GT? not an option. Do a great job? Then yes it is true for a large mod needs a lot of work, but what to do.

Bogdan I still think that you are not so fluent in english so you maybe still do not see the point: GregTech adds 1000x more things than other mods...and yet it loads in 50x longer time. That means GT is 200x FASTER. (That is example, not exact numbers)

The code is efficient as it can be. If you want faster game, you should want optimized code at MOJANG side. Their code SUX, not modder's .
Another thing, that can fasten the loadup - removing PARTS of GT, not the whole GT (here you misunderstood Pyure) - but removing anything from GT - is NOT AN OPTION

[gregtech.common.GT_Proxy:registerRecipes:1849]: Thingy Name: ForciciumItem !!!Unknown 'Thingy' detected!!! This Object seems to probably not follow a valid OreDictionary Convention, or I missed a Convention. Please report to GregTech Intergalactical for additional compatiblity. This is not an Error, an Issue nor a Lag Source, it is just an Information, which you should pass to me.

[gregtech.common.GT_Proxy:registerRecipes:1849]: Thingy Name: slimeballPink !!!Unknown 'Thingy' detected!!! This Object seems to probably not follow a valid OreDictionary Convention, or I missed a Convention. Please report to GregTech Intergalactical for additional compatiblity. This is not an Error, an Issue nor a Lag Source, it is just an Information, which you should pass to me.



[gregtech.common.GT_Proxy:registerRecipes:1849]: Thingy Name: stringFluxed !!!Unknown 'Thingy' detected!!! This Object seems to probably not follow a valid OreDictionary Convention, or I missed a Convention. Please report to GregTech Intergalactical for additional compatiblity. This is not an Error, an Issue nor a Lag Source, it is just an Information, which you should pass to me.


With version 05.08.18

Quote from MauveCloud

There's a good chance a newer version of Railcraft will help. According to the Railcraft wiki, the latest version is 9.6.1.0, but I just tried version 9.5.0.7 with GT 5.08.18, and several of the Railcraft items that had no recipes with GT 5.07.07 showed recipes this time.

Mauve, I updated to Railcraft 9.5.x and all my problems with the recipes went away. I had issue with Railcraft 9.6 and a steam block ID conflict with another mod, but 9.5.x is fine with me.

THANKS !

For those concerned with the difficulty of obtaining Uranium-235 when using GregTech, I just noticed that GemBlocksForGreg has an option in its config file to help with that.

BLOOD ASP, THANK YOU A LOT FOR THE GRATE JOB!!!

Btw is there any energy storage for LuV, ZPM or UV? Or we need running Mark1 Fusion Reactor to have enough energy to supply Mark2 and so on?

There a Lapotronic Energy Orb Cluster for LuV and an Ultimate Battery for UV. I don't see a rechargeable battery for ZPM voltage.

Quote from MauveCloud

There a Lapotronic Energy Orb Cluster for LuV and an Ultimate Battery for UV.

Thx, didn't find them in wiki.

:Blood Asp
thank you for keeping GT 5 alive...

For recipe rebalancings, did you change any of Greg's old stuff? I'd check the code but I only see up to #18 on github.

Is casserite suppose to be smelted directly into 2 ingots?

Also, you can't use the steam macerater on casserite and iron ore? I don't remember these ever being a thing. bug?

Cassiterite and Iron ore work fine for me in the steam macerator.