Forge one-time injection

[MGlolenstine]

Why doesnt' FML inject mods once and then only re-injects if there are changes in mods?

It'd be easier and faster to play bigger modpacks.

[MGlolenstine]

4 minutes ago, diesieben07 said:

Please clarify what you mean by "injection".

Well.. Isn't Forge injecting minecraft.jar at every start?

 

[MGlolenstine]

1 minute ago, diesieben07 said:

Forge is not "injecting minecraft.jar". The game code is transformed on the fly as it is loaded from disk. That is not the slow part of starting up Minecraft. The slow part is (among other things) the model creating, which just takes a long time with a lot of mods.

Oh, ok so I misunderstood the whole concept of forge  

But why is it creating models at every launch?

Couldn't you just store them?

Edited June 28, 2017 by MGlolenstine

[MGlolenstine]

4 minutes ago, diesieben07 said:

Not necessarily. There is no easy way for Forge to know whether something in a mod has changed that would change the generated model to change. Has this config file you changed caused the Model to change? We don't know. Is this Model download from an URL which has a different model every time? We don't know.

All this prevents from Forge "just storing models". As very often in Computer Science the obvious "just do X" answer is sadly not correct.

Ok, I was wrong and I'm sorry.  

[GameGlitz]

Actually, you are not wrong. I know this is a necropost, but the reason this is not wrong, is because instead of loading all the mods into the RAM, using up CPU power (older machines don't have a lot, so it takes a long time to load mods sometimes), Forge can do a 1 time load onto the hard drive, and leave it like that, and keep an MD5 checksum of every mod, and recheck the MD5 checksum every launch, and if it remains the same, just allow the game to load as NORMAL. This is the only way I can really think of, (yes, I know you can also do an SHA256 and SHA1 checksum, but MD5 is faster to calculate) and if anyone has more idea's of ways, or a way to prove me wrong, please reply to this thread. Thank you, goodbye.

[MGlolenstine]

3 minutes ago, GameGlitz said:

Actually, you are not wrong. I know this is a necropost, but the reason this is not wrong, is because instead of loading all the mods into the RAM, using up CPU power (older machines don't have a lot, so it takes a long time to load mods sometimes), Forge can do a 1 time load onto the hard drive, and leave it like that, and keep an MD5 checksum of every mod, and recheck the MD5 checksum every launch, and if it remains the same, just allow the game to load as NORMAL. This is the only way I can really think of, (yes, I know you can also do an SHA256 and SHA1 checksum, but MD5 is faster to calculate) and if anyone has more idea's of ways, or a way to prove me wrong, please reply to this thread. Thank you, goodbye.

First of all, thank you for replying to this post ?. I was thinking of the same thing, with the hashing and storing everything on the HDD, but I think that the problem with mod updates isa great one, I know you could only rebuild it when mods updare, but still... Thing that I think would be the most trouble, would have to be the different mod distinction, as some mods inject directly into the code and it's hard for Forge to determine which mod the change is coming from.

 

Thanks again, and I hope that we get something along these lines in the future ?

[Busti]

I think your best shot at skipping the loading screen would be to load Minecraft in a Virtual Machine and saving it's state to disk without quitting Minecraft, instead of shutting it down.

Edited January 27, 2019 by Busti

[loordgek]

1.13 will be loading faster, mods will load parallel

[GameGlitz]

On 1/27/2019 at 3:08 PM, Busti said:

 

"I think your best shot at skipping the loading screen would be to load Minecraft in a Virtual Machine and saving it's state to disk without quitting Minecraft, instead of shutting it down." - Busti

 

This makes sense, as Java uses it's own Virtual Machine, called the JVM. Running another JVM inside the main JVM via the framework itself will allow us to run Minecraft once, and then save the state. Then we can launch that machine every time the game starts, but check the MD5 hash of mods and files before starting. This speeds up a LOT.

 

On 1/22/2019 at 7:10 PM, diesieben07 said:

Have you looked at how mod loading works? Probably not, because this is not feasible.

RUDE.

[GameGlitz]

1. Forge one-time injection

   diesieben07 replied to MGlolenstine's topic in General Discussion

   Please clarify how I was rude?

   •  1 minute ago
   •  
   •  13 replies
2. 

   Ore Variant Textures Not Working Properly

   diesieben07 replied to Viking 2481's topic in Modder Support

   That is literally how any programming language works...

   •  3 hours ago
   •  
   •  4 replies
3. 

   Access transformers doesn't work with forge classes

   diesieben07 replied to hohserg's topic in Modder Support

   No! Don't do this. You must not be accessing the world in your model, since the model may be rendered on a different thread, so you will cause random and seemingly inexplicable crashes. Any information necessary for the model to render must be stored in the IBlockState.

   •  3 hours ago
   •  
   •  7 replies
4. 

   Access transformers doesn't work with forge classes

   diesieben07 replied to hohserg's topic in Modder Support

   What are you trying to achieve? Why do you need access to this class?

   •  4 hours ago
   •  
   •  7 replies
5. 

   The game crashed whilst exception in server tick loop Error: java.lang.IllegalArgumentException: Duplicate id value for 23!

   diesieben07 replied to betaninja's topic in Support & Bug Reports

   1.7.10 and older are no longer supported on this forum due to their age. Update to a modern version of Minecraft to receive support. You have been told this already, consider this a warning.

 

This is a paste of all the rude things you have said, PLEASE take it down. It is very selfish.

[GameGlitz]

You are joking. They are all very rude.

Edited January 28, 2019 by GameGlitz

[GameGlitz]

Okay. Lets get back on topic. With a VM it is possible however.

[GameGlitz]

When the creator of this thread comes back online, I'm going to start up Eclipse and try out my thoughts.

[GameGlitz]

Updates are not required, as what I am talking about is different. If you intergrate a VM for forge to load mods, and then pass the session over to the JVM on the host computer, it is possible. I have started to experiment in Eclipse, and I have to say I am VERY close to getting this core-mod to work.

[GameGlitz]

I have actually done it. This core-mod still isn't ready for production, but it works PERFECTLY for me. What I have done is created a Linux distro that contains a very simple architecture (just Java on Arch Linux) which will boot up at Minecraft's start, and then reload mods to the drive if the MD5 hash of any files have changed (apart from the Minecraft settings and Optifine settings). Then, it will hibernate the VM, and then put the session onto a container on the main PC, which will put you on a loading screen overlaying the title screen, which will then take the session out of the container, and close Minecraft, replacing it with the loaded modded version. Then it will close the container, and leave the VM hibernated. This is a very complicated method, and if you manually delete the VM files from the .minecraft\config\GameGlitzVM\ folder, it will have to load each mod again, resulting in no difference of load times. However, when you close the game, shutdown your computer, leave it for 2 mins, and boot it back up, then launch Minecraft, it will automatically restore the session into a container, then onto the host computer.

I am now working on a re-auth system to auth you to the official Minecraft servers again, so that you can play on servers (else what is the use). I have seen a mod called ReAuth that does what I need, but it requires you to enter your account details, so I will find a way to use the account that the launcher used to start the game. Please reply with any way to help me reauth.