Thanks! New boat controls should be ok to work with, but I can't get the Airship to spawn (I'm used to ML's spawnEntity so I'm not sure how to do it without it ) Looking forward to BL 1.7!
A good place to look for info on how to spawn a mob is the spawn egg class and TileEntityMobSpawner. I had to write a /spawn command for an older project and I was able to figure it out through that. It is a two step process I believe: You have to create the entity and configure it, and then call World.spawnEntityInWorld(entity). Or something like that. I will add a spawnEntity to the API, though.
I've been using that, but the problem is (when using it in items) that it only spawns clientsided, and I need to use packet23vehiclespawn to send the spawn (Modloader had some kind of function for it). I think it might have something to do with the render too, but I'll need to investigate. I understand the idea around Packets but I've never properly gotten them to work in Minecraft by myself lol. I've been playing around in 1.7 and apart from the new names instead of ids not much has noticeably changed, which is hopefully a good thing
Yeah if it is server side you have to send the packet. If you can show me your mod's ModLoader spawn code I can see what all ML does to make that happen.
I've been using that, but the problem is (when using it in items) that it only spawns clientsided, and I need to use packet23vehiclespawn to send the spawn (Modloader had some kind of function for it). I think it might have something to do with the render too, but I'll need to investigate. I understand the idea around Packets but I've never properly gotten them to work in Minecraft by myself lol. I've been playing around in 1.7 and apart from the new names instead of ids not much has noticeably changed, which is hopefully a good thing
If you only need it to work in singleplayer you could use this:
public static World getServerWorld() {
int dimension = Minecraft.getMinecraft().theWorld.provider.dimensionId;
MinecraftServer server = MinecraftServer.getServer();
if (server != null) {
WorldServer[] worlds = server.worldServers;
for (WorldServer i : worlds) {
if (i.provider.dimensionId == dimension) {
return i;
}
}
}
return Minecraft.getMinecraft().theWorld;
}
Then just spawn the entity like this:
World world = getServerWorld();
Entity entity = new Entity(world);
entity.setPositionAndRotation(x, y, z, yaw, pitch);
world.spawnEntityInWorld(entity);
It should then appear correctly for both the client and the internal server.
I'm not active on these forums, so forgive me if I don't respond!
If you want to contact me, try going through Discord or you can find me on GitHub where I am still updating the below mods (and more):
If you only need it to work in singleplayer you could use this:
public static World getServerWorld() {
int dimension = Minecraft.getMinecraft().theWorld.provider.dimensionId;
MinecraftServer server = MinecraftServer.getServer();
if (server != null) {
WorldServer[] worlds = server.worldServers;
for (WorldServer i : worlds) {
if (i.provider.dimensionId == dimension) {
return i;
}
}
}
return Minecraft.getMinecraft().theWorld;
}
Then just spawn the entity like this:
World world = getServerWorld();
Entity entity = new Entity(world);
entity.setPositionAndRotation(x, y, z, yaw, pitch);
world.spawnEntityInWorld(entity);
It should then appear correctly for both the client and the internal server.
Thanks! I have something really similar to this, but on closer inspection I think it might have something to do with the rendering too, so I'm going to poke around and see.
Edit: Looks like it was caused by a rendering issue. Sorry!
I believe this issue is at least partially caused by the fact that the network manager completely ignores the entity ID -> class table and uses an if-else block to determine the entity.
Will ASM be required to fix this issue without editing the jar? I don't want to make life too difficult for you in fixing it!
So far I have been able to fix it, but I am up to 6 new proxy classes and I am only 40% done. If this even works then there may be may be a greater impact further down. At some point I do plan to use the ASM provided by the tweaklauncher to replace the proxy system, but for now I will try to get this to work. Don't feel bad about me doing all this, after all if not me then modders would.
I'm not active on these forums, so forgive me if I don't respond!
If you want to contact me, try going through Discord or you can find me on GitHub where I am still updating the below mods (and more):
I'm not active on these forums, so forgive me if I don't respond!
If you want to contact me, try going through Discord or you can find me on GitHub where I am still updating the below mods (and more):
Ah, ok. Modloader just has a public method that forwards to that though.
Anyway it doesn't affect me. I switched to my own manager a while ago.
I just added a new class MinecraftPackageManager in the net.minecraft.src package specifically to access minecraft package-private crap. I also rewrote ApiRecipe to use it. I will push the commits soon.
Just tested the ASM launching in vanilla, obfuscated, normal minecraft and it worked great! Now all that is needed is to see if it works with forge and if not try and do something about it (aside from bytecode-editing ASM)!
I can't update until MCP is updated, and that is also what Forge is waiting for.
i heard there is a java decompiler(or something like that) and someone made a 1.7 mod in that
did i do this right(it isnt loading)also this mod worked if i put these in the minecraft.jar with risugami's modloader. didn't work without.didn't test if i put these in the minecraft.jar with blazemodloader but i wanted my mod to be without modification of the jar(except for the modloader[any{forge,risugami's modloader, blazeloader}]) so it can be uninstalled and because i want the least amout of modification of the minecraft.jar plus I ziped the mod
First of all, If you make modifications to base classes, you have to put the compiled classes in the minecraft.jar or make an ASM type deal to override the base classes on startup.
On the modloader part, if you just edited base classes you don't need a modloader (except if you use hooks from that loader) just paste the edited class files in the minecraft.jar.
No, no, no, never, what on earth are you thinking. You do not need to edit the jar, ever, any more,for any reason, at all. I recommend not giving advice to others if you don't know what you're talking about yourself.
Some things is would recommend: If you want to make a mod, learn how minecraft works, learn how mcp works, learn how modloaders work and more important, learn java before you start to mod.
i heard there is a java decompiler(or something like that) and someone made a 1.7 mod in that
The problem isn't the decompilation (or rather, it's to do with an aspect of decompilation that's the sticking point right now), it's the fact that deobfuscating the game is time consuming. It's perfectly possible to decompile the game and modify it without MCP, it's just a lot more of a nuisance to do so and unless your mod is very simple or if you have a lot of time on your hands then it will take a long time and is particularly error-prone to boot. Almost everyone now waits for MCP rather than duplicating the effort themselves, because it just makes everything a lot easier. As in, it's likely that even if I started updating my mods now in obf that I wouldn't have finished by the time MCP is released and therefore I would have wasted that intervening time.
At the moment there's a decompilation issue with MCP handling anonymous inner enums and it needs to be resolved, even though it wouldn't technically prevent a release it would prevent MCP from producing bytecode-compatible recompiles of the game and that's what the MCP team try to avoid.
No, you need to put your classes in a jar file. Also "mods" is only used by the mod loaders (modloader, fml, blazeloader, liteloader) and so just dumping classes in there is a - pretty pointless and messy and b - not going to work.
also this mod worked if i put these in the minecraft.jar with risugami's modloader. didn't work without.didn't test if i put these in the minecraft.jar with blazemodloader but i wanted my mod to be without modification of the jar(except for the modloader[any{forge,risugami's modloader, blazeloader}]) so it can be uninstalled and because i want the least amout of modification of the minecraft.jar
Ok, let me explain. As of 1.6, nothing needs to go in the jar, never ever, Risugami and everyone who told you otherwise is wrong. Do not touch the jar.
You have two choices, both of which work for the same reason. 1) use a loader of some kind, they don't modify the jar either (except risu's but we already established he was wrong), and are loaded as a library using mojang's LaunchWrapper (which allows external base class mods) or run as a library yourself, if you really are determined not to use a loader. However given your knowledge of modding this may be a little too advanced.
In a nutshell you can patch base classes from a library provided that you use LaunchWrapper (even without a tweak, but you will probably need one) and make sure that your library is higher in priority than the game jar - which all libraries implicitly are. I would recommend against it though since the installation method is a little more convoluted unless you want to provide an installer (which is what other tweak-based add-ons do) or intend to distribute the patched JSON with your mod file (which isn't particularly user-friendly).
None of which would be necessary if you used Forge or BlazeLoader, and quite honestly are going to give you a hard time being compatible with any other mods.
It seems that you're goals are upside-down. You say you want to "reduce the amount that the jar is modified", but as I explained using a loader means that the jar is not modified at all, yet you want to patch base classes which - quite frankly - don't need to be patched to achieve... well anything.
I have to repeat big_Xplosion's advice from above, go and learn more about java and especially MCP, and particularly about the role that loaders/API's play in making mods, and re-evaluate what your priorities are because they don't make sense at the moment.
No, no, no, never, what on earth are you thinking. You do not need to edit the jar, ever, any more,for any reason, at all. I recommend not giving advice to others if you don't know what you're talking about yourself.
This, at least, is sound advice.
The problem isn't the decompilation (or rather, it's to do with an aspect of decompilation that's the sticking point right now), it's the fact that deobfuscating the game is time consuming. It's perfectly possible to decompile the game and modify it without MCP, it's just a lot more of a nuisance to do so and unless your mod is very simple or if you have a lot of time on your hands then it will take a long time and is particularly error-prone to boot. Almost everyone now waits for MCP rather than duplicating the effort themselves, because it just makes everything a lot easier. As in, it's likely that even if I started updating my mods now in obf that I wouldn't have finished by the time MCP is released and therefore I would have wasted that intervening time.
At the moment there's a decompilation issue with MCP handling anonymous inner enums and it needs to be resolved, even though it wouldn't technically prevent a release it would prevent MCP from producing bytecode-compatible recompiles of the game and that's what the MCP team try to avoid.
No, you need to put your classes in a jar file. Also "mods" is only used by the mod loaders (modloader, fml, blazeloader, liteloader) and so just dumping classes in there is a - pretty pointless and messy and b - not going to work.
Ok, let me explain. As of 1.6, nothing needs to go in the jar, never ever, Risugami and everyone who told you otherwise is wrong. Do not touch the jar.
You have two choices, both of which work for the same reason. 1) use a loader of some kind, they don't modify the jar either (except risu's but we already established he was wrong), and are loaded as a library using mojang's LaunchWrapper (which allows external base class mods) or run as a library yourself, if you really are determined not to use a loader. However given your knowledge of modding this may be a little too advanced.
In a nutshell you can patch base classes from a library provided that you use LaunchWrapper (even without a tweak, but you will probably need one) and make sure that your library is higher in priority than the game jar - which all libraries implicitly are. I would recommend against it though since the installation method is a little more convoluted unless you want to provide an installer (which is what other tweak-based add-ons do) or intend to distribute the patched JSON with your mod file (which isn't particularly user-friendly).
None of which would be necessary if you used Forge or BlazeLoader, and quite honestly are going to give you a hard time being compatible with any other mods.
It seems that you're goals are upside-down. You say you want to "reduce the amount that the jar is modified", but as I explained using a loader means that the jar is not modified at all, yet you want to patch base classes which - quite frankly - don't need to be patched to achieve... well anything.
I have to repeat big_Xplosion's advice from above, go and learn more about java and especially MCP, and particularly about the role that loaders/API's play in making mods, and re-evaluate what your priorities are because they don't make sense at the moment.
A good place to look for info on how to spawn a mob is the spawn egg class and TileEntityMobSpawner. I had to write a /spawn command for an older project and I was able to figure it out through that. It is a two step process I believe: You have to create the entity and configure it, and then call World.spawnEntityInWorld(entity). Or something like that. I will add a spawnEntity to the API, though.
Currently I use MCP, although with the TweakLauncher and proxy system it may be possible to update without that.
Most likely.
Yeah if it is server side you have to send the packet. If you can show me your mod's ModLoader spawn code I can see what all ML does to make that happen.
If you only need it to work in singleplayer you could use this:
Then just spawn the entity like this:
It should then appear correctly for both the client and the internal server.
If you want to contact me, try going through Discord or you can find me on GitHub where I am still updating the below mods (and more):
PRESENCE FOOTSTEPS - (github)
VOID FOG - (github)
I believe this issue is at least partially caused by the fact that the network manager completely ignores the entity ID -> class table and uses an if-else block to determine the entity.
So far I have been able to fix it, but I am up to 6 new proxy classes and I am only 40% done. If this even works then there may be may be a greater impact further down. At some point I do plan to use the ASM provided by the tweaklauncher to replace the proxy system, but for now I will try to get this to work. Don't feel bad about me doing all this, after all if not me then modders would.
Actually this won't be possible without ASM, unfortunately. Too much mojang pointless crap. I guess I will start working on an ASM rewrite, then.
Yeah, and with that there are 3 crucial API features I could add with minimal trouble.
ASM loading is now functional! It only needs testing in the normal, obfuscated Minecraft environment and it will be complete!
That would not really work, as ASM works with compiled classes.
Uhm, am I missing something here?
If you want to contact me, try going through Discord or you can find me on GitHub where I am still updating the below mods (and more):
PRESENCE FOOTSTEPS - (github)
VOID FOG - (github)
That method is package private.
Ah, ok. Modloader just has a public method that forwards to that though.
Anyway it doesn't affect me. I switched to my own manager a while ago.
If you want to contact me, try going through Discord or you can find me on GitHub where I am still updating the below mods (and more):
PRESENCE FOOTSTEPS - (github)
VOID FOG - (github)
I just added a new class MinecraftPackageManager in the net.minecraft.src package specifically to access minecraft package-private crap. I also rewrote ApiRecipe to use it. I will push the commits soon.
I can't update until MCP is updated, and that is also what Forge is waiting for.
i heard there is a java decompiler(or something like that) and someone made a 1.7 mod in that
did i do this right(it isnt loading)also this mod worked if i put these in the minecraft.jar with risugami's modloader. didn't work without.didn't test if i put these in the minecraft.jar with blazemodloader but i wanted my mod to be without modification of the jar(except for the modloader[any{forge,risugami's modloader, blazeloader}]) so it can be uninstalled and because i want the least amout of modification of the minecraft.jar plus I ziped the mod
This is simply not true, where did you hear that?
No, no, no, never, what on earth are you thinking. You do not need to edit the jar, ever, any more,for any reason, at all. I recommend not giving advice to others if you don't know what you're talking about yourself.
This, at least, is sound advice.
The problem isn't the decompilation (or rather, it's to do with an aspect of decompilation that's the sticking point right now), it's the fact that deobfuscating the game is time consuming. It's perfectly possible to decompile the game and modify it without MCP, it's just a lot more of a nuisance to do so and unless your mod is very simple or if you have a lot of time on your hands then it will take a long time and is particularly error-prone to boot. Almost everyone now waits for MCP rather than duplicating the effort themselves, because it just makes everything a lot easier. As in, it's likely that even if I started updating my mods now in obf that I wouldn't have finished by the time MCP is released and therefore I would have wasted that intervening time.
At the moment there's a decompilation issue with MCP handling anonymous inner enums and it needs to be resolved, even though it wouldn't technically prevent a release it would prevent MCP from producing bytecode-compatible recompiles of the game and that's what the MCP team try to avoid.
No, you need to put your classes in a jar file. Also "mods" is only used by the mod loaders (modloader, fml, blazeloader, liteloader) and so just dumping classes in there is a - pretty pointless and messy and b - not going to work.
Ok, let me explain. As of 1.6, nothing needs to go in the jar, never ever, Risugami and everyone who told you otherwise is wrong. Do not touch the jar.
You have two choices, both of which work for the same reason. 1) use a loader of some kind, they don't modify the jar either (except risu's but we already established he was wrong), and are loaded as a library using mojang's LaunchWrapper (which allows external base class mods) or run as a library yourself, if you really are determined not to use a loader. However given your knowledge of modding this may be a little too advanced.
In a nutshell you can patch base classes from a library provided that you use LaunchWrapper (even without a tweak, but you will probably need one) and make sure that your library is higher in priority than the game jar - which all libraries implicitly are. I would recommend against it though since the installation method is a little more convoluted unless you want to provide an installer (which is what other tweak-based add-ons do) or intend to distribute the patched JSON with your mod file (which isn't particularly user-friendly).
Looking at your mod classes, you are patching:
None of which would be necessary if you used Forge or BlazeLoader, and quite honestly are going to give you a hard time being compatible with any other mods.
It seems that you're goals are upside-down. You say you want to "reduce the amount that the jar is modified", but as I explained using a loader means that the jar is not modified at all, yet you want to patch base classes which - quite frankly - don't need to be patched to achieve... well anything.
I have to repeat big_Xplosion's advice from above, go and learn more about java and especially MCP, and particularly about the role that loaders/API's play in making mods, and re-evaluate what your priorities are because they don't make sense at the moment.
Very good explanation!