Board Thread:General Mod Discussion/@comment-25101089-20170524114315/@comment-26428291-20170526232055

HighElvenDoge wrote:

LOTRMod wrote:

Campinator wrote: Speaking of coremods, I have a question about them. This may not be the appropriate place to ask, so forgive me if that is the case.

On one of your posts explaining coremods, you gave an example of nice healthy code and coremod code. Why is it that coremods have to have vastly different codes, when they are merely interacting with a different part of the modding process? If I understand correctly, which I may not, coremods edit the way Forge interacts with Java/Vanilla(?). If so, then why can't it just use "normal' Java syntax?

How much do you know about Java? There is Java source code, which may look confusing to someone who's not used to it, but hopefully you can at least recognise that it follows a logical structure, and includes things that make sense, like if, else, arithmetic operators, and so on. This is because the source code is designed to resemble natural human language (at least compared to bytecode.)

Then when you compile the source code, it becomes Java bytecode. This is quite different, and it's a long list of fundamental step-by-step instructions - which computers can interpret much more easily, though more confusing to a human mind. Java bytecode is what the computer actually runs. It's the 'final form' of the source code. That's why it's called source code. It's like the ingredients for a recipe.

You can see plenty of examples of what these two languages look like by image searching.

The mod is written in Java source code, and then compiled into bytecode. As is Minecraft itself. But the way a coremod works is that it makes alterations to the already-compiled program at run-time - i.e. when you start the game up - as opposed to a mod which is written and compiled on its own, and then runs at run-time. So say, for example, as the 'Player' class is loaded, the coremod will intercept it and say, well, here's the list of bytecode instructions which check if the player can eat, I'm going to clear those and insert a different instruction that always responds 'yes'.

So a mod is like buying a car, changing some parts, and then driving the modified car. A coremod is more like starting up the car and then taking the engine apart as it's running.

This of course raises the question: if a coremod interacts with compiled bytecode, how on earth do you write it in source code? The answer is that the coremod is written in source code, but that sourcecode uses a special library which mimics the way bytecode works. Instead of writing source code which the compiler automatically transforms for you, you write source code which has an explicit one-to-one correspondence with the workings of bytecode. (And that bytecode-mimicking source code is then compiled into bytecode itself, which will look even more different from the actual bytecode it's mimicking...)

To use another analogy: writing and compiling source code might be like speaking into a microphone, and relying on the software to translate those sound waves into a sound file format (which is entirely different from the sound waves, not to mention the words you spoke, and the ideas those words represent, and the physical brainwaves those ideas represent...) Writing a coremod is analogous to working out how your voice would look as a sound file format, and then constructing the file format directly without speaking and relying on the software. That's not a perfect analogy, and it might not mean much to anyone who hasn't actually written a coremod, but I'm not sure how else to explain it. This explains why my resource packs which I added to the mod don't work. The coremod intercepts the code and rewrites it. If you're only adding a resource pack then you must have done something completely wrong if the coremod is rewriting it..?