I fail to see how I have reacted in such a manner. All I did was reiterate that the code in DragonAPI, aside from mod handling and some trackers, is "on call", and therefore could not be the source of the problem on its own. Given that the code in the retrogen controller is supposed to only run when there is at least one registered retrogenerator (and you say the GeoStrata one is in fact disabled, and have no other of my mods), I do not see how that code would be the issue. I have pulled the registration of the instance, however, in case it is an issue with the event bus.
Also, by "take down", I mean remove the file from mediafire (and its trash can, as files are still accessible there). This prevents issues should anyone copy and redistribute that link.
Oh Reika, I am fully aware that you do not think you are being high handed and dismissive. If you were aware of doing and still doing it anyway that would make you a bad kind of person. I think you are completely oblivious to the way you come across and therefore to me it is just one of the issues of dealing with a creative person. However, I am not here to lecture you on your communication skills. I'll pass along that you would like the file off mediafire.
As bad as this makes me look, I have to ask you to take that link down. Go ahead and use it yourself, but I do not allow distribution of code edits.
I don't mind removing the link. I also do not want to make you look bad. However I have come to contact you in this thread twice now with what I believe were legitimate issues and your attitude has been very high handed and dismissive. It is extremely frustrating. You may want to remove that link from your quote of my post.
Even though there was no possible way whatsoever that your full blown mod that masquerades as an API was causing a potentially very serious bug on our server, patching out your chunk init retrogen code completely stopped the error from occurring. The issue specifically is that you register RetroGenController with Forge's EventBus.
Here is the patch for it if any other server owners like to keep their chunks intact. It is for v14 of dragonAPI and only the server side needs to be patched.
*snip*
Read the readme and follow the instructions. Thank you to blood from mcpc for doing this for us.
No, the disabler works, as I can always tell when someone is using it.
The class itself is in DragonAPI, but the execution is called from the mods' end. DragonAPI does very little on its own.
In all likelihood, it is not the retrogen doing this.
Ahh perhaps you are right. Be that as it may we only experience the CMEs with DragonAPI installed. I am not sure where else to point right now. Any suggestions?
If you want to do so, go ahead. It is publicly available.
Well no of course we don't really WANT to which is why I brought it to your attention. This is a potentially server destroying bug if the game world tries to save while this is happening it will eat chunks. I figured you'd be willing to take a look at it. We're 99% sure its DragonAPI and not geostrata btw. Without geostrata installed and with dragonAPI we still get the error, and without dragonAPI we do not.
I do nothing with chunk NBT. Why do you think it is DragonAPI, when there are no references to its code, and DragonAPI runs no code except on game load and when loading mod handlers?
I'm not sure what your level of experience is with Concurrent Modification Errors is so please excuse any assumptions I am making. The CME log will not show a stacktrace related to any mod's code because all it is showing is that the main thread is writing concurrently to an open block of data. In this case it is being thrown during chunk NBT iterations, meaning that is the block of data in conflict. In this case we attached a debugger to chunk NBT adds and removes to see what mods were accessing that data when the conflict arose. Based off that list of mods we removed them one at a time until the error stopped. Our lucky winner in this case was DragonAPI or perhaps Geostrata. I have not dug into your code to try and locate the exact problem but I suppose we could have someone do that if you'd like.
Please let me know any way we can help resolve this with you. I'm happy to assist.
I have a fairly serious bug that I believe we have traced to DragonAPI. Here is the log: http://pastie.org/8667361
What is apparently happening is that whenever DragonAPI is removing/adding to chunk NBT it is not doing it threadsafe. Therefore the main thread is also iterating those threads causing the CME. This is happening using forge 965 on a server with dragonAPI and Geostrata installed.
Can you please take a look at this as it can easily cause chunk corruption/reset.
Back on topic, I had a few thoughts about situations that could become.. lets say... interesting.
If a mod is incompatible with another mod, and their code is at fault, but is required for the mod to function, would that be considered malicious?
If a developer has his art assets stolen and used on another website, say, Second Life or IMVU or any of those user submitted content marketplaces, where if you lodge a legitimate copyright claim under any other circumstance those items can be removed, in this instance could that be considered invalid according to the above anti-mod-eula arguments? (Or certainly how they are worded. You make it seem modders have absolutely no rights to their content.)
And finally, is a malicious code considered a code that stops your mod from functioning, without compromising integrity of any other data, when used in circumstances that the developer didn't want it in?
I think you need to familiarize yourself with what 'malicious' means. The subtext is both act and intent. That should clarify your situations for you.
0
1
Oh Reika, I am fully aware that you do not think you are being high handed and dismissive. If you were aware of doing and still doing it anyway that would make you a bad kind of person. I think you are completely oblivious to the way you come across and therefore to me it is just one of the issues of dealing with a creative person. However, I am not here to lecture you on your communication skills. I'll pass along that you would like the file off mediafire.
0
I don't mind removing the link. I also do not want to make you look bad. However I have come to contact you in this thread twice now with what I believe were legitimate issues and your attitude has been very high handed and dismissive. It is extremely frustrating. You may want to remove that link from your quote of my post.
0
Use CamStudio, free and easy and will do screens or regions.
4
Here is the patch for it if any other server owners like to keep their chunks intact. It is for v14 of dragonAPI and only the server side needs to be patched.
*snip*
Read the readme and follow the instructions. Thank you to blood from mcpc for doing this for us.
0
0
Ahh perhaps you are right. Be that as it may we only experience the CMEs with DragonAPI installed. I am not sure where else to point right now. Any suggestions?
0
I do have it disabled. Perhaps there is an issue with having it disabled not actually disabling it?
Also remember we get this even without geostrata installed. Is there a separate config for dragonAPI that has a way to disable it I am missing?
0
Well no of course we don't really WANT to which is why I brought it to your attention. This is a potentially server destroying bug if the game world tries to save while this is happening it will eat chunks. I figured you'd be willing to take a look at it. We're 99% sure its DragonAPI and not geostrata btw. Without geostrata installed and with dragonAPI we still get the error, and without dragonAPI we do not.
Edit:
Here is the likely class:
https://github.com/ReikaKalseki/DragonAPI/blob/040a26c4317669da5a40d6df3c5891a1cb4c7127/Auxiliary/RetroGenController.java
NBTTagCompound tag = (NBTTagCompound)event.getData().getTag(NBT_TAG);
Found: https://github.com/ReikaKalseki/DragonAPI/blob/040a26c4317669da5a40d6df3c5891a1cb4c7127/Auxiliary/RetroGenController.java
Looks like it gets called on every forge chunk load. Hope that helps!
0
I'm not sure what your level of experience is with Concurrent Modification Errors is so please excuse any assumptions I am making. The CME log will not show a stacktrace related to any mod's code because all it is showing is that the main thread is writing concurrently to an open block of data. In this case it is being thrown during chunk NBT iterations, meaning that is the block of data in conflict. In this case we attached a debugger to chunk NBT adds and removes to see what mods were accessing that data when the conflict arose. Based off that list of mods we removed them one at a time until the error stopped. Our lucky winner in this case was DragonAPI or perhaps Geostrata. I have not dug into your code to try and locate the exact problem but I suppose we could have someone do that if you'd like.
Please let me know any way we can help resolve this with you. I'm happy to assist.
0
What is apparently happening is that whenever DragonAPI is removing/adding to chunk NBT it is not doing it threadsafe. Therefore the main thread is also iterating those threads causing the CME. This is happening using forge 965 on a server with dragonAPI and Geostrata installed.
Can you please take a look at this as it can easily cause chunk corruption/reset.
Thank you.
0
I think you need to familiarize yourself with what 'malicious' means. The subtext is both act and intent. That should clarify your situations for you.
5
This seems more like backpedaling than social experimentation, but congrats on your enlightenment either way.
0
0
If so any chance of getting this removed?