I do not forbid people from removing APIs from the DragonAPI jar, so those three edits are a non-issue. As for the equals() override, I am not going to ask you to revert the changes. However, I am going to say that this modified version cannot be used outside of your server. Also, I believe the crash is purely serverside (not clientside), and if I am correct, I am also going to ask that you not distribute it to the clients either, and keep it purely for your serverside copy.
This is the best reconciliation I can see between the rules as they are and reasonable flexibility.
An NEI derp I added a workaround for in v3.
This is reasonable and I will make sure on the next update of the pack (soon) that the TileEntityBase class is reverted back to it's default on the client's end. I request that you make it more known that API removal is allowed as I had previously understood it as being prohibited.
I will post any and all future changes here and we can discuss a solution assuming the changes are clientside, of which I have not yet encountered.
I would prefer to do it publicly. The reasons I make the decisions I do are and should remain public, as should any arguments to the contrary, in addition to any counterpoints I may make.
Here's the thing, I've got a server and a modpack and I've worked on it for a while now. I've got a decent playerbase and from how I interpreted the agreement that I had agreed to at the time, I was allowed to make modifications to your set of mods as I saw fit assuming it doesn't have an affect on actual gameplay. I understand that you do not want to appear to the public as showing a favoritism nor do you have the time to spend checking every modification (as in change) to your mods. You do not want those shitheads who call themselves admins disabling parts of your mod to create a 'pay-to-play' environment and I support your attempts at disallowing them the ability to do so. I would do the same in your case.
In the case of people like me, who don't beg for donations, provide donation perks, disable any aspects of any mods, and simply want a nice and stable pack to play on, we're stuck working with outdated mods or crashing servers, which is clearly an issue.
Now, as said above, in this very window (intended to be posted as a private message), there were 5 rules regarding the use of your mods in the modpack. Now I'm not going to be a **** about this, nor am I going to step on your toes about something so small, so I'm going to be blunt.
The modpack I currently host has very few modifications to the DragonAPI, all with the intent of stability and compatibility. The jar is currently being distributed in the modpack and will not cease doing so as the rules I had agreed to above had not disallowed it. Here are the modifications as of 11/23/14 but they may change as server crashes are the only things that reveal instability and compatibility issues:
- DragonAPI 'thaumcraft' API removed (Outdated API, causes crashes)
- DragonAPI 'buildcraft' API removed (Outdated API, does not start)
- DragonAPI 'micdoodle8' API removed (Outdated API, causes crashes when entering space)
- DragonAPI TileEntityBase.class Equals() function patched:
The opcode range 00000003A to 0000003C was added, as well as an exception handler as seen in the image above. This is a simple try {} catch {} block if converted back to java code which prevents a crash when certain people join.
In no way am I going to revert these changes nor will I remove the current version of your mods from my pack. If you do not want me to modify your minecraft mods from here on out, I would be more than happy to follow your updated agreement and will consequently not update your mods from here on out.
As I am a developer myself, I believe this to be the most understandable and reasonable way of going about things, and I hope you see the same yourself.
I was inquiring about the reasons behind it, not the actual agreement. Changing it now doesn't clarify anything, it only changes the original agreement and doesn't answer my question.
Quote from Reika» Already fixed in v3, but I believe a temporary fix is to downgrade CoFH.
This exact issue was the crash I had when you told me it wasn't an issue with your mods. I did mislabel it as being a matchCoords issue but if I had looked more at the actual stack trace, I would have known it was that function. That one's on me, but I was still told I was unable to fix and distribute it.
I'd rather you just let people fix it themselves rather than having them downgrade other mods (which means other mods are more unstable) just to ensure your mod goes untouched.
I'm not trying to start anything here, but what I would like to know is why you have a strong urge to ensure that your mod is not tampered with in any way? Even something as simple as deleting an API folder in a jar of yours seems to have some issue associated with it, and I'm not sure how it would be a problem. I've done some small development projects in the past and if someone had some crash or issue with anything I've developed, I'd be more than happy to allow them to modify it (even in the case of strict enforcement of functionality change prohibition) simply for stability purposes. I understand you want your mod to be -just how it it's shipped- and I totally get why you'd want it to be so. You've put a large amount of work into every aspect of it, but not allowing someone to change something technical like throwing a try-catch into some crashing code is just going to squash the population of people who want to play it, assuming we're talking about semi-private packs here.
I assume the agreement you have on the OP is all intentional because it states that semi-private packs are denied all ability to do any form of editing.
Modifications must be done by using commonly-accepted tools such as WorldGuard. Under no circumstances may you modify any mod's source code, including with ASM or bytecode edits.
Yet this only applies to semi private packs. Public packs are not explicitly denied the ability to do bytecode patching, source code editing, or otherwise, and from the guidelines,
The pack must not use external mods to significantly change the way my mods work, such that a guide for the default setup would be misleading or useless for the pack (or vice versa), or that the mods' techtrees, if applicable, are radically altered, or that features are missing. This includes the use of MineTweaker and other similar tools to remove recipes or items! Config options native to the mod are of course free to be modified. they are allowed to make changes assuming those changes are not radically altering. To get to the point, why do you allow public modpack edits, but not private ones?
On another note, the buildcraft, thaumcraft, and galacticraft api are out of date in V2, but I'm sure you already are aware of that.
If I only modify the DragonAPI jar for compatibility/stability purposes, changing no recipes, features, or game mechanics, and only to improve performance on my modpack, as well as distributing the jar exclusively in my pack and nowhere else, would it be OK if I made those changes?
It's running on a server with players and the actual crashes don't seem to be consistent. It's kind of a nightmare of a crash because there are no logs other than what I've given to you, and as much as I'd love not to come to you with this problem (because it's not your fault), I'd rather come to you than to disregard what you said about custom build distribution.
Otherwise I'd add in the code I wrote already and would have this (hopefully) fixed.
Easier would be to find the actual cause of the crash. Most people, myself included, are running my mods with no issues.
I would have to disagree. While it's inherently better to find the root cause of the issue, it's not in any way easier, especially when no logs indicate that it's an issue and only ever give out the exception I pasted above. I could spend hours of my time searching through dumps and whatnot to figure out why a certain value is what it is, but a simple null check on your part would be a lot easier to fix the issue anyways, especially considering it's in the DragonAPI source that it crashes. I hope this makes sense.
Then can I at least get a workaround build that just returns false if each entry is null? I'm looking to keep this server as stable as possible.
Something even trivial like
private boolean matchCoords(TileEntity te)
{
if (te == null) return false;
if (te.field_145851_c == null) return false;
if (this.field_145851_c== null) return false;
if (te.field_145848_d == null) return false;
if (this.field_145848_d == null) return false;
if (te.field_145849_e == null) return false;
if (this.field_145849_e == null) return false;
return te.field_145851_c == field_145851_c && te.field_145848_d == field_145848_d && te.field_145849_e == field_145849_e;
}
would make my life so much easier, if you don't mind either building me a copy or allowing me to change it myself for my modpack.
I'm getting an error, so I'm attempting to build from source in hopes that the error goes away.
---- Minecraft Crash Report ----
// I'm sorry, Dave.
Time: 11/17/14 6:07 PM
Description: Exception ticking world entities
java.lang.NullPointerException: Exception ticking world entities
at Reika.DragonAPI.Base.TileEntityBase.equals(TileEntityBase.java:454)
at java.util.ArrayList.indexOf(ArrayList.java:269)
at java.util.ArrayList.contains(ArrayList.java:252)
at java.util.ArrayList.batchRemove(ArrayList.java:669)
at java.util.ArrayList.removeAll(ArrayList.java:640)
at net.minecraft.world.World.func_72939_s(World.java:2450)
at net.minecraft.world.WorldServer.func_72939_s(WorldServer.java:669)
at net.minecraft.server.MinecraftServer.func_71190_q(MinecraftServer.java:943)
at net.minecraft.server.dedicated.DedicatedServer.func_71190_q(DedicatedServer.java:423)
at net.minecraft.server.MinecraftServer.func_71217_p(MinecraftServer.java:798)
at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:658)
at java.lang.Thread.run(Thread.java:722)
A detailed walkthrough of the error, its code path and all known details is as follows:
---------------------------------------------------------------------------------------
-- Head --
Stacktrace:
at Reika.DragonAPI.Base.TileEntityBase.equals(TileEntityBase.java:454)
at java.util.ArrayList.indexOf(ArrayList.java:269)
at java.util.ArrayList.contains(ArrayList.java:252)
at java.util.ArrayList.batchRemove(ArrayList.java:669)
at java.util.ArrayList.removeAll(ArrayList.java:640)
at net.minecraft.world.World.func_72939_s(World.java:2450)
at net.minecraft.world.WorldServer.func_72939_s(WorldServer.java:669)
After some detective work, it looks like you need to update the BuildCraft API in your DragonAPI to the latest version. If it's not updated, it'll crash because of a function mismatch in the RefineryRecipeManager interface (not sure if there's anything more than that, but probably. It'll just crash)
0
http://pastebin.com/avCQjwaL
http://pastebin.com/ZhG2jWW8
0
2. Open it with DirtyJOE, go to the methods tab
3. Find the equals function
4. Copy what I had in my screenshot
http://i.imgur.com/JUyMVgr.png
Literally adding 4C 03 AC to the function. Hell, you can edit the last opcode in the function and just type in those bytes and it'll append them.
5. Add an exception handler starting at 0000 and ending at 003A, the exception being of type java/lang/Exception
Make sure the max locals matches with the one in my pic
6. Save and put back into jar, overwriting old one
It's pretty simple when I literally screenshot'ed the code that was needed to fix it.
0
This is reasonable and I will make sure on the next update of the pack (soon) that the TileEntityBase class is reverted back to it's default on the client's end. I request that you make it more known that API removal is allowed as I had previously understood it as being prohibited.
I will post any and all future changes here and we can discuss a solution assuming the changes are clientside, of which I have not yet encountered.
Thank you.
1
Here's the thing, I've got a server and a modpack and I've worked on it for a while now. I've got a decent playerbase and from how I interpreted the agreement that I had agreed to at the time, I was allowed to make modifications to your set of mods as I saw fit assuming it doesn't have an affect on actual gameplay. I understand that you do not want to appear to the public as showing a favoritism nor do you have the time to spend checking every modification (as in change) to your mods. You do not want those shitheads who call themselves admins disabling parts of your mod to create a 'pay-to-play' environment and I support your attempts at disallowing them the ability to do so. I would do the same in your case.
In the case of people like me, who don't beg for donations, provide donation perks, disable any aspects of any mods, and simply want a nice and stable pack to play on, we're stuck working with outdated mods or crashing servers, which is clearly an issue.
Now, as said above, in this very window (intended to be posted as a private message), there were 5 rules regarding the use of your mods in the modpack. Now I'm not going to be a **** about this, nor am I going to step on your toes about something so small, so I'm going to be blunt.
The modpack I currently host has very few modifications to the DragonAPI, all with the intent of stability and compatibility. The jar is currently being distributed in the modpack and will not cease doing so as the rules I had agreed to above had not disallowed it. Here are the modifications as of 11/23/14 but they may change as server crashes are the only things that reveal instability and compatibility issues:
- DragonAPI 'thaumcraft' API removed (Outdated API, causes crashes)
- DragonAPI 'buildcraft' API removed (Outdated API, does not start)
- DragonAPI 'micdoodle8' API removed (Outdated API, causes crashes when entering space)
- DragonAPI TileEntityBase.class Equals() function patched:
The opcode range 00000003A to 0000003C was added, as well as an exception handler as seen in the image above. This is a simple try {} catch {} block if converted back to java code which prevents a crash when certain people join.
In no way am I going to revert these changes nor will I remove the current version of your mods from my pack. If you do not want me to modify your minecraft mods from here on out, I would be more than happy to follow your updated agreement and will consequently not update your mods from here on out.
As I am a developer myself, I believe this to be the most understandable and reasonable way of going about things, and I hope you see the same yourself.
Thank you,
Banandana
PS: This rich text editor really really sucks.
0
0
0
0
This exact issue was the crash I had when you told me it wasn't an issue with your mods. I did mislabel it as being a matchCoords issue but if I had looked more at the actual stack trace, I would have known it was that function. That one's on me, but I was still told I was unable to fix and distribute it.
I'd rather you just let people fix it themselves rather than having them downgrade other mods (which means other mods are more unstable) just to ensure your mod goes untouched.
I'm not trying to start anything here, but what I would like to know is why you have a strong urge to ensure that your mod is not tampered with in any way? Even something as simple as deleting an API folder in a jar of yours seems to have some issue associated with it, and I'm not sure how it would be a problem. I've done some small development projects in the past and if someone had some crash or issue with anything I've developed, I'd be more than happy to allow them to modify it (even in the case of strict enforcement of functionality change prohibition) simply for stability purposes. I understand you want your mod to be -just how it it's shipped- and I totally get why you'd want it to be so. You've put a large amount of work into every aspect of it, but not allowing someone to change something technical like throwing a try-catch into some crashing code is just going to squash the population of people who want to play it, assuming we're talking about semi-private packs here.
I assume the agreement you have on the OP is all intentional because it states that semi-private packs are denied all ability to do any form of editing.
Yet this only applies to semi private packs. Public packs are not explicitly denied the ability to do bytecode patching, source code editing, or otherwise, and from the guidelines,On another note, the buildcraft, thaumcraft, and galacticraft api are out of date in V2, but I'm sure you already are aware of that.
EDIT: Minecraftforum's editor sucks.
0
0
It's running on a server with players and the actual crashes don't seem to be consistent. It's kind of a nightmare of a crash because there are no logs other than what I've given to you, and as much as I'd love not to come to you with this problem (because it's not your fault), I'd rather come to you than to disregard what you said about custom build distribution.
Otherwise I'd add in the code I wrote already and would have this (hopefully) fixed.
0
I would have to disagree. While it's inherently better to find the root cause of the issue, it's not in any way easier, especially when no logs indicate that it's an issue and only ever give out the exception I pasted above. I could spend hours of my time searching through dumps and whatnot to figure out why a certain value is what it is, but a simple null check on your part would be a lot easier to fix the issue anyways, especially considering it's in the DragonAPI source that it crashes. I hope this makes sense.
0
Something even trivial like
private boolean matchCoords(TileEntity te) { if (te == null) return false; if (te.field_145851_c == null) return false; if (this.field_145851_c== null) return false; if (te.field_145848_d == null) return false; if (this.field_145848_d == null) return false; if (te.field_145849_e == null) return false; if (this.field_145849_e == null) return false; return te.field_145851_c == field_145851_c && te.field_145848_d == field_145848_d && te.field_145849_e == field_145849_e; }would make my life so much easier, if you don't mind either building me a copy or allowing me to change it myself for my modpack.
0
All that needs to be done, it seems, is some null checking here and the problem should go away.
0
0
After some detective work, it looks like you need to update the BuildCraft API in your DragonAPI to the latest version. If it's not updated, it'll crash because of a function mismatch in the RefineryRecipeManager interface (not sure if there's anything more than that, but probably. It'll just crash)
https://github.com/BuildCraft/BuildCraft/blob/6.1.x/api/buildcraft/api/recipes/IRefineryRecipeManager.java
The function in question is
void addRecipe(String id, FluidStack ingredient, FluidStack result, int energy, int delay);
whereas before, there was no string parameter first.
You'll have to push out an update, because it seems to have been changed in the latest 6.1.x update onward.