I would love to be able to edit chests, but as Hey0 already said they are really annoying. I am trying to keep the edited classes to a minimum so when this Halloween update comes out, the API can be up and running within a few hours. Maybe after that I will look into chest and player inventories.
I am using this API in conjunction with my server wrapper (SimpleServer) to create a tightly bound warp mod. I will also be generalizing the classes used at some point in the future so that others can make plugins/mods for SimpleServer
hey I think i've got a bug for you.
my server has been crashing with a NullPointerException every now and again (haven't figured out what is causing it)
But the stack trace leads to
bg.<init>
line 26
Should be an easy fix, based on what i saw from your decompiled class file.
EDIT: Actually, I might be using 0.6 instead of 0.7.
hey I think i've got a bug for you.
my server has been crashing with a NullPointerException every now and again (haven't figured out what is causing it)
But the stack trace leads to
bg.<init>
line 26
Should be an easy fix, based on what i saw from your decompiled class file.
EDIT: Actually, I might be using 0.6 instead of 0.7.
Looks like the weird java packaging is giving me hell of a headache right now. If I have my class file OUTSIDE the jar, just lying around in the folder, it's getting loaded and it's running. If it's inside my JAR (top level), it's not loaded. What am I doing wrong here?
This is why I prefer C++ over Java.. no overcomplicated packaging format..
First of all you are using 'JarName.ClassName' format in addons.cfg (excluding the quotes) , right?
If so, then I'll make a video tutorial on how to make mods in about 7 hours when I get out of school..
If not, then see if that works. Also, there shouldn't be spaces in addons.cfg
Hi there. API 0.7 works fine for me but 0.8 and 0.8_2 crash immediately after preparing the spawn area. There's at least one other person on the Simple Server thread ( viewtopic.php?f=1012&t=27756&p=818905#p818905 ) who is having the same issue. Anything I can provide to help identify the issue?
Hi there. API 0.7 works fine for me but 0.8 and 0.8_2 crash immediately after preparing the spawn area. There's at least one other person on the Simple Server thread ( viewtopic.php?f=1012&t=27756&p=818905#p818905 ) who is having the same issue. Anything I can provide to help identify the issue?
0.8 wasn't thoroughly playtested because it was 3 am at it's release. I'll look into it when I get home.
Hi there. API 0.7 works fine for me but 0.8 and 0.8_2 crash immediately after preparing the spawn area. There's at least one other person on the Simple Server thread ( viewtopic.php?f=1012&t=27756&p=818905#p818905 ) who is having the same issue. Anything I can provide to help identify the issue?
0.8 wasn't thoroughly playtested because it was 3 am at it's release. I'll look into it when I get home.
NP, sounds like a late night! So it looks like 0.8x only crashes when I include an addition to the addons.cfg file. In this case, I'm setting it up as:
addons=SSWarpMod.SSWarpMod
which is the name of SSWarpMod.SSWarpMod.jar in the addons directory. If I remove this line from the addons.txt file or if I roll back to SMP API 0.7, it works fine.
I actually have a small request.. could you make the whole starting routine less implicit and more explicit? Currently starting the API.jar makes it look for "minecraft_server.jar" and complain when that file is not there. Can you make it so that I can actually provide the file to be started myself?
Something like "java -Xmx... -Xms... API.jar nogui minecraft_server_mod.jar"?
Leaving the last argument out will look for minecraft_server.jar and including it will make it look for whatever you provide.. deal?
Hi there. API 0.7 works fine for me but 0.8 and 0.8_2 crash immediately after preparing the spawn area. There's at least one other person on the Simple Server thread ( viewtopic.php?f=1012&t=27756&p=818905#p818905 ) who is having the same issue. Anything I can provide to help identify the issue?
0.8 wasn't thoroughly playtested because it was 3 am at it's release. I'll look into it when I get home.
NP, sounds like a late night! So it looks like 0.8x only crashes when I include an addition to the addons.cfg file. In this case, I'm setting it up as:
addons=SSWarpMod.SSWarpMod
which is the name of SSWarpMod.SSWarpMod.jar in the addons directory. If I remove this line from the addons.txt file or if I roll back to SMP API 0.7, it works fine.
EXAMPLE: Lets say that you have a jar named 'MyAddon.jar'. In the jar there is a class that implements Mod named 'MyTestMod'. Place 'MyAddon.jar' into '/addons'. In addons.cfg add 'MyAddon.MyTestMod'.
Hi there. API 0.7 works fine for me but 0.8 and 0.8_2 crash immediately after preparing the spawn area. There's at least one other person on the Simple Server thread ( viewtopic.php?f=1012&t=27756&p=818905#p818905 ) who is having the same issue. Anything I can provide to help identify the issue?
Everytime the API is updated and a new callback was added, then the mod will have to be recompiled in the new API version before it can be used again.
Everytime the API is updated and a new callback was added, then the mod will have to be recompiled in the new API version before it can be used again.
I see. So most likely the mod I'm trying to use hasn't been recompiled for 0.8x and I'll just need to be mindful of this whenever a new version of the API comes out. Simple enough, thanks!
Something to consider would be implementing Mod as an abstract class rather than an interface. Then mods can override only the functions they need to, and other functions can execute default code. It would be slightly more work on your part to implement this, but it ends up being easier on the mod creators.
Also, I'm not 100% sure, but if you update the abstract class, the extending classes do not have to be updated unless one of their functions changes in the update. IE a parameter/return value is added or changed.
Something to consider would be implementing Mod as an abstract class rather than an interface. Then mods can override only the functions they need to, and other functions can execute default code. It would be slightly more work on your part to implement this, but it ends up being easier on the mod creators.
Also, I'm not 100% sure, but if you update the abstract class, the extending classes do not have to be updated unless one of their functions changes in the update. IE a parameter/return value is added or changed.
It's getting late, but I will look into that tomorrow.
I actually have a small request.. could you make the whole starting routine less implicit and more explicit? Currently starting the API.jar makes it look for "minecraft_server.jar" and complain when that file is not there. Can you make it so that I can actually provide the file to be started myself?
Something like "java -Xmx... -Xms... API.jar nogui minecraft_server_mod.jar"?
Leaving the last argument out will look for minecraft_server.jar and including it will make it look for whatever you provide.. deal?
Sounds great! I'll add it ASAP.
I had forgotten that that this is not possible right now. If this mod were to be loaded with say Hey0's mod, then this API would be overriding some of the same files on the server that Hey0 does and the admin mod would fail to work & crash.
I will begin example mods tonight since I'm running out of features to add.
Now with even more burst dragons and autokickbans plugin rpg!
my server has been crashing with a NullPointerException every now and again (haven't figured out what is causing it)
But the stack trace leads to
bg.<init>
line 26
Should be an easy fix, based on what i saw from your decompiled class file.
EDIT: Actually, I might be using 0.6 instead of 0.7.
Now with even more burst dragons and autokickbans plugin rpg!
Yea, I'll release 0.8 after that's fixed.
EDIT: Fixed it. 0.8 should be out momentarily.
IE When something is typed into the console.
Now with even more burst dragons and autokickbans plugin rpg!
Sure, I'll add that in 0.9
First of all you are using 'JarName.ClassName' format in addons.cfg (excluding the quotes) , right?
If so, then I'll make a video tutorial on how to make mods in about 7 hours when I get out of school..
If not, then see if that works. Also, there shouldn't be spaces in addons.cfg
0.8 wasn't thoroughly playtested because it was 3 am at it's release. I'll look into it when I get home.
NP, sounds like a late night! So it looks like 0.8x only crashes when I include an addition to the addons.cfg file. In this case, I'm setting it up as:
which is the name of SSWarpMod.SSWarpMod.jar in the addons directory. If I remove this line from the addons.txt file or if I roll back to SMP API 0.7, it works fine.
Sounds great! I'll add it ASAP.
EXAMPLE: Lets say that you have a jar named 'MyAddon.jar'. In the jar there is a class that implements Mod named 'MyTestMod'. Place 'MyAddon.jar' into '/addons'. In addons.cfg add 'MyAddon.MyTestMod'.
Hope that clears things up. :smile.gif:
Everytime the API is updated and a new callback was added, then the mod will have to be recompiled in the new API version before it can be used again.
I see. So most likely the mod I'm trying to use hasn't been recompiled for 0.8x and I'll just need to be mindful of this whenever a new version of the API comes out. Simple enough, thanks!
Also, I'm not 100% sure, but if you update the abstract class, the extending classes do not have to be updated unless one of their functions changes in the update. IE a parameter/return value is added or changed.
Now with even more burst dragons and autokickbans plugin rpg!
It's getting late, but I will look into that tomorrow.
I had forgotten that that this is not possible right now. If this mod were to be loaded with say Hey0's mod, then this API would be overriding some of the same files on the server that Hey0 does and the admin mod would fail to work & crash.