warriordog / blazeloader Goto Github PK

Registering an Entity with createSpawnPacket and addEntityToTracker does not register the Entity in NetClientHandler's handleVehicleSpawn, making it so that in order to get the Entity to spawn you need to edit NetClientHandler (Base Edits D:)

MCP install instructions need to be written, since the new system is a bit complex to install.

bl_at.cfg has been partially converted to a new format, this needs to be finished.

ReflectiveOperationException does not exist in java se 6 witch could cause a problem for a lot of mac users and some people that haven't updated yet to java 7.

Currently BL is compatible with the server version of LL, but uses client classes. This needs to be tested on a server and rewritten as neccessary.

When running the AccessTransformer (via apply_at.py) an NPE is thrown:

Exception in thread "main" java.lang.NullPointerException
at net.acomputerdog.BlazeLoader.asm.AccessTransformer.readRules(AccessTransformer.java:60)
at net.acomputerdog.BlazeLoader.asm.AccessTransformer.(AccessTransformer.java:42)
at net.acomputerdog.BlazeLoader.asm.AccessTransformer.main(AccessTransformer.java:205)

All pre-LL API needs to be ported over using the BLEventInjectionTransformer. The Minecraft.loadWorld event is provided as a functioning example. All event methods in EventHandler need to be implemented.

The AccessTransformer is throwing an IllegalArgumentException when when being used with the new changes what is causing it to not run at all and causes it the completely fail on the BlazeLoader installation in MCP. This is because all the lines in the bl_at.cfg with the blocks and items has a static modifier applied which will NOT work with the AccessTransformer.

The AccessTransformer isn't ment for making methods/fields/class static and it will never like that as it would cause a load of instability issues. The AccessTransformer is only ment to be used when changing a method/field/class to public/private/protected etc and in some rare occasions you can change it to be final or not final. All these changes shouldn't cause instability in 95% of the cases. I just wrote this to remember everybody that you should only use the AccessTransformer in very rare occasions.

And please, @Sollace, test your stuff before submitting them as a PR and btw, I don't really get why the initBlocks() and InitItems() are even needed. I would fix this myself, but I don't have the time at the moment and because (as said before) I don't get the use for these methods

I'm not sure what it is but the apply_at script can't apply the access transformer any more.

It looks like it's meant to run from the main mcp folder but it can't find the python script if I run it from anywhere other than than "mcp/BlazeLoader/util/" folder. Even if I move the script with it.

I added 'pause' to the end of the script and got the output.

Output when run from "mcp/Blazeloader/util/"

Copying 1.7.2.json...
C:\Users\Christopher\AppData\Roaming\.minecraft\versions\1.7.2\1.7.2.json
1 File(s) copied
done.

Copying 1.7.2.jar...
C:\Users\Christopher\AppData\Roaming\.minecraft\versions\1.7.2\1.7.2.jar
1 File(s) copied
done.

Copying launchwrapper-1.9.jar...
C:\Users\Christopher\AppData\Roaming\.minecraft\libraries\net\minecraft\launchwrapper\1.9\launchwrapper-1.9.jar
1 File(s) copied
done.

Copying asm-debug-all-4.1.jar...
asm-debug-all-4.1.jar not found!
The system cannot find the path specified.
The system cannot find the path specified.
Press any key to continue . . .

Output when run from "mcp/" with the python script in any of the following locations:

• "mcp/BlazeLoader/util/"
• "mcp/"
• "mcp/util/"

..\runtime\bin\python\python_mcp: can't open file '\util\apply_at.py': [Errno 2]
No such file or directory
Press any key to continue . . .

It would be handy to have an automated build script that outputted the normal obfuscated/compile BlazeLoader and a normal source output that is used for the installer.

Create a version of BlazeLoader based off of forge classes to provide compatibility.

Currently the tweak launcher simply replaces entire classes with BL classes at runtime, but that means that it overwrites forge's tweaks. The tweaklauncher will need to be re-written to detect forge and load an alternate set of classes if it is installed.

VersionUtils checks for the presence of Forge or obfuscation by using Class.forName() with the names of the a couple classes. This is unsafe, as it can cause early class initialization. These should instead use Class.forName() on enums, which have no code and no references to other types.

as stated above

This should only be used in very rare occasions but it would be really useful for some (core/base) mods if they could change access levels or hook in to the minecraft launching.