Jackson Perr

I would say that you should just do whatever works... without giving somebody a virus. The only goal is to get the files from your computer to other people, right? Shouldn't really matter too much the median. At least I don't think.

Well, that wasn't so bad! I added function parameters to each of the methods to make it easier to understand which function is which. Hope this helps out! PastebinCrash Log - Pastebin.comPastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

I do not believe that forge is compatible with vanilla, even if it is un-modded. This is mainly due to forge having different kinds of network packets as well as its own required client and server network handler that vanilla minecraft just doesn't have (although this networking should be done on a different named channel that forge's packets wont be being sent to if on vanilla). Forge might also add additional data onto some vanilla packets in some versions (which is just speculation, as I have never seen evidence of this before during my time modding, so it could be unlikely). There could be other reasons, but I would have to do some testing to find out exactly what is going on. In the meantime, I will try and find the right mappings to make your log file more readable, which should help get to the bottom of your specific issue here. I will get back to you. Edit: I will get back to you... In a while: this is going to be a bit of an undertaking.

So... ummmm, forge "1.2.11"? Do you mean forge "1.21.11" (as said in your crash report)? If you really meant what you said, then you're really gonna' have to provide a download link here (and maybe even a time machine). Also, please specify the exact version of forge that you are using. Because your crash report is completely obfuscated (for whatever reason), people are going to need access to the mappings in order to make sense of this crash report. Provide all of this (the mappings should be easily accessible if you provide the exact forge version), and I will edit this crash report to make much more sense and post it back here via pastebin. Hopefully then it will be much easier for others to answer your question. I will say though, just based on the error message I can see, chances are likely slim that you can use a vanilla client. These reasons would take a little while to get into, but even if chances look slim, you shouldn't let this discourage you; you never really know if a problem like this can't be solved unless we try. Hope this can help us get somewhere easier to work with. Let me know!

Alright, I have taken a look at the crash report you have provided and cross referenced it to the source code. It turns out that my theory is true! Strangely, when writing information to a save file, enigmatic legacy will just update the file and push all of its edits upon an error occurring. If it weren't for that, this issue probably wouldn't be happening. The problematic file you are looking for should be located directly in your world save folder in a file named "soul_archive.json". If you are having trouble finding this file, try using the search field in file explorer. The most direct solution to your issue at hand would be to delete this file directly. However, this file may be able to be repaired, but this option is up to you if you wish to pursue. Luckily for you, the file should be in a readable format. You can open it in notepad or some other text editor to view the contents. If you are having trouble detecting and solving issues within this file, you could try sending the raw contents of it through pastebin to this thread. I can take a look and send the modified contents back to you through pastebin, or if I could find no solution, I will let you know, in which case you should simply default to deleting the file. Please let me know if you encounter any unexpected issues or if something I said is unclear to you; I will help to the best of my ability.

I really should have specified this, but almost everything that mods end up writing to files is going to be serialized in some way. They do this because it is direct and easy for computers to handle. So if you pop one of these files into a notepad editor, you're probably not going to be able to find anything useful unless you're actually a computer and your using a hex editor. It literally has to be both. However, you can use programs to put this kind of data into a more readable format, such as NBTEditor if you are opening up .dat files, which I assume you did judging by your confusion. Keep in mind, if you are attempting to look through each of these files for discrepancy, you are probably going to have a hard time, as I am unsure if you even have any good pointers on even the file you need to look through. But that's okay; I can get this kind of information for you. I will need your latest crash report to be sure though, as well as the download link for the version of Enigmatic Legacy you are using so I can be certain that I have the same exact problematic mod as you. I can take a look through the code and refer to the crash report to see if I can find out exactly what's going on here. Furthermore, if it turns out that my theory is true, I can provide you exactly/approximately the file you need to look in and how you can open it readably. And don't worry, if you and I are thinking of the same symbols here, then they don't mean jack diddly squat to anybody.

Honestly, just do whatever works best. If you know for sure the best way to go about implementing ModConfigEvent to sync data, then go ahead and use it. It's always best to get with the standards. However, if it doesn't, then I guess you'll just have to do it the "old fashioned way". But ultimately, this choice should best be left up to you rather than somebody else. Now, it doesn't hurt to ask a colleague or friend for advice, but you should always know what best to do with the advice that you are given and the weight of your options. Now, if you are asking for how to use ModConfigEvent to sync config data, then I believe you may be mistaken. Syncing data is going to, from my current understanding, which should be pretty consistent, always require network handling. It is entirely up to you how you wish to handle sending the data to your clients or vice versa. However, for operations like this, USE THE MODCONFIGEVENT CLASS; it's going to be a lot more efficient and orthodox in recent versions to use this class to handle changes in mod configuration for your mods. It's also more appropriate. But again, if you have another way that you are comfortable with, and if you know the differences between your way and the standard way, and if you have weighed these options, then go for whichever one fits you best. Hope this helps! Also, if you would like something to be clarified, or if I missed the point of any of your questions, then please let me know.

Hey man! I noticed you've made quite a number of posts very quickly. Just make sure to provide more details in these posts. For example, with this particular post, it may be difficult to help you as you have not provided any code. Because there is no code, many people that are to respond to your post would only be able to be guided by the examples of what is going wrong that you suggest. Generally, this is not ideal, as it is best to allow those answering your questions to come in with an open mind. Although, I'm probably not a good follower of this rule, so don't start lookin' through my posts. Side tangents aside, these missing details do make it a bit difficult to track down the exact issue at hand. Regardless, I will still try my best to spit-ball here and see if anything sticks for ya'. You seem to mention that your entity is being rendered as a "black cube". If your definition of cube here is the same as mine, and your entity is not supposed to be a cube, then there is a chance that when establishing your model renderer for your entity, you extended the wrong class. This might also make sense in explaining why it is "black". From everything I can tell, if you supplied the correct texture but extended the wrong model renderer class, then the texture mappings will leave blank spaces that will render black from the entity model renderers being updated. That is to say, when the game applies this "cube" UV layer mapping to the texture file provided, because the texture is not constructed for the cube, the images pulled for the cube from the texture will obviously not end up matching. There is a slim chance that this can make your entire entity render as black. That last thing that I can think of as to the cause of your issue here would have to be that you MIGHT have forgotten to register your entity renderer. As for registering it, there is plenty of documentation of this on the Forge Docs, so be sure to check it out, but do make sure you register these for clients only if you haven't already. If all of the above suggested issues have already been checked, then my next and final best guess would have to be that the game isn't able to get your textures for whatever reason. Try searching your latest.log file for text like "missing texture" and see if anything seems familiar. If none of the above suggestions are applicable to your situation, then it would likely be pertinent to provide more information. The suggestions above are the most probable causes. If it isn't them, then the chances of somebody coming to a solution from the provided info is going to, unfortunately, be very slim. I would like to provide further help to you, but I do not have enough information to work with here. Here is some info you could provide that would help us get to the bottom of this: A latest.log file would give further information as to warnings or errors your game could be generating. If you do not feel comfortable with providing this log file, then you could use a CTRL+F search through the file to replace all occurrences of your PC Username with something else. There won't be much more identifiable info in the log file except for that and your minecraft username. Your source code would also give anybody attempting to answer your question a lot of ease for very pronounced reasons. Please get back to this thread with more; I would like to help you figure out what's going on here!

The enigmatic legacy mod is probably causing this issue because of mishandling nbt data or some other form of save data in your world that wasn't able to be serialized properly due to your storage device being full. It is likely trying to find some kind of save data in your world that it always expects to be a list, but under your circumstances, it wasn't able to actually put the list data in. This could be why your game crashed when trying to respawn. Because the data is still corrupted, when the game attempts to load this data, it always expect a list, but doesn't get one. So when it tries to treat the data as a list, it fails and causes a crash. This is likely why your crashing when attempting to load the world. Disabling this mod removes all features relevant to data loading for the mod, which explains why disabling it make your game work, but re-enabling it makes your game crash. If you would like to load your world with the mod, then try and find out the file that it is reading to get this "null" list and delete it. Ofc, that requires this theory to be true though.

My best guess would have to be that this is an issue with either your installation of the modpack you have, or it could be an issue with java itself, although the latter of which I doubt. Did you make modifications to your modpack in any way? Did you just install it fresh off of curseforge and then all of a sudden these errors are happening? If none of these are the case, then this issue is especially strange, and you should post on the issue tracker and tag it as a bug, because under intended circumstances and context, none of this should be happening. Also, please make sure to provide a link to your issue here so that other users with your issue in the future can more easily find information as to the problem.

This is a good question! First off, I'd like to start by saying that you probably should NOT be rewriting the entire source code of another mod only to change so little. No offense, but it is a bit unorthodox, but in all honesty, if a mod is open source, and I can save the time from writing code to manipulate the mod FROM ANOTHER MOD, I'm downloadin' that source code, so I can't blame you too much for takin' the "easier" option 'cause then I'd be a bit of a hypocrite... However, if you don't want your time spent trying to rewrite the code to go to waste, you could just create a new mod project, copy the forge code for the backpack mod into your new project, and assemble the raw mod from there. But it seems that for some reason you want to push this mod as an artifact, which I honestly don't really see the point when it's just a mod for you and your friends, as you could just as easily slap that thing in ya' google drive and call it a day. Alternatively, you could make your own github repository and change the references in the gradle project to that instead, but this is probably the MOST unorthodox thing you could possibly do, and I honestly think that if you were to do this then Satan himself might personally drag you into hell. So to save yourself from eternal damnation, you might not want to do this. But from a more practical and orthodox standpoint, it is MUCH more appropriate to make a mod that modifies the code for the original mod in some way. There are two ways this can be done: the orthodox way and the unorthodox way. Let's start with the unorthodox way, as it's a lot easier to explain. Basically, you can change the code for another mod by making sure your mod loads in first into the JVM, which is easily done by just putting a bunch of "a"'s in the mods name. Next, find whatever piece of code you want to add in, and create a class with that same code in your mod with the exact same path as the class you wish to change (e.g. net.minecraft.entity.Entity if you wanted to change code in the entity class). The goal here is to trick the JVM into using your class instead of the original. This also means that you don't even have to do like any setup, not even including the backpacks mod as a dependency, so it's SUPER simple. However, this might not be that easy for you to do, because you mention that you need to change enums. I haven't looked too deep into the mods code, and by that I haven't actually looked at all, but if there is one thing I think I remember about enums, it's that they might be treated similar to CONSTANTS after compiling, which means that changing the enum class will have no effect because every usage of the enum is treated like putting in a constant number. If you choose the unorthodox route though, then I could be wrong, so it's still worth a shot. Finally, you have the proper orthodox way to do it, which is with an assembly transformer. If you don't want to go through the headache of having to set up your own bytecode transformer and learning java assembly bytecode, then I would recommend just using mixin. Basically, mixin or any other ASMTransformer are special tools that can be used to modify the code for certain classes. If you have used Harmony for c# or c++ unity mods, then it's much the same thing: give the transformer a class to do it's magic in, give it a function to use for it's magic, and tell it where to do it. For mixin, this is done by using the @Inject thingamabob (legitimately forgot wth this kind of thing was called). If you want examples of the ASMTransformer route and how to set it up, I would recommend looking at the source code for Galacticraft, as it uses transformers EXTENSIVELY. If you wish to use mixin, then there is extensive documentation on it's usage. Hope this helps!

You shouldn't completely remove a post after you find a solution, as it prevents anybody with a similar problem as you from finding a solution as well. Unless it was something REALLY dumb like "Guys, why does java keep telling me that 1 + 2 = 3, I mean, that's clearly not true." If it's something like that then you should ABSOLUTELY delete it. Not only is it EMBARASSING, but if any employer were to find out about it, let's just say you probably aren't gettin' that codin' gig.

I have only ever really seen things like this done with assemble transformers, for example in Galacticraft. If you would like to see an example, then I believe the Galacticraft source code is open on github. If not, then NTM-CE HBM 1.12.2 and techguns ore open on github and both also mess around the sky and sun. This is the best I can tell you for now, so I'm sorry if it's not very concise or helpful. But if I may ask, what do you mean by "two layer". Isn't the sun a single flat texture in the sky? Do you plan on putting a mask over it, thus making it two layer? Although what you mean by two layer sun is not very clear, I believe it is clear what you mean by custom sky. I would recommend you use gimp to make a TILEABLE sky map. If you already have a sky texture, then you should add it in to your assets folder for your mod as long as whatever else you need for what you want done with the sun. Again, this is the best advice I can offer for now.

If I remember correctly, I believe one of the rules, or maybe the faq, states something like, "This is not a java school, so make sure you know enough java." I think it's clear that you might not know enough java to accomplish the task you have set out to do (or not, I can't really say based solely on these two snippets of code that you seemed to have selected and modified), but whatever the case may be, I find this rule, or suggestion, whatever it is, to be really stupid in some cases. With that said, if you wish to save the data to the world, then with the code you have provided, I see no Event Handlers to do this with. I'm not sure if you know how to subscribe to event handlers with forge, but if you have your mod running in literally any capacity, then you should have done this with some methods in your main mod class container, otherwise how on earth is your mod gonna' work? So, I'm going to assume that you have gotten your mod to work in some capacity, if you haven't then please look into some more basic mod development, but I might also be able to help you out a little. Anyways, there is an event you can set up with one of your methods called "FMLServerStoppedEvent". I could have the wrong one, so you should probably look into the difference between "FMLServerStoppedEvent", and "FMLServerStoppingEvent", but either should work. The essential idea is to use this event with one of your methods, that way when the server stops, you can have a method called that will save all of your team data. Basically, you're going to want to write into your main mod class something that looks a little like this: @EventHandler public void serverStopHandler(FMLServerStoppedEvent event) { //Code to save team data }And, in case you haven't done this yet, you're of course going to use the FMLServerStartingEvent to load this data into your mod, so you can do something similar to the above. But if you already have a method to load the mod data, then this shouldn't be needed. Now, there are a number of mechanisms that you can use to save your data, one such method being to write the data into an nbtdata file and save it to the world folder, or writing it to some forgecaps and loading those forge caps through some other means. However, by far the simplest thing you could do would be to use a Buffer object to write and read data to and from a raw binary file saved directly to your server folder so it can be easily accessed. The first idea to accomplish this task would be to create a file that will contain your team save data if none exists, then open this file and either read your save data from it, or write your save data to it. Creating your file is as simple as importing the java.io.File class, creating a new instance of the file class with whatever name you want, for example, new File("teamsavedata.bin"), and using a FileOutputStream to write the bytes to the file, or if you need to read the bytes from the file, you should specifically use the java.io.Files class's Files.readAllBytes method. This takes a file path as one of its arguments. This can be acquired after you create an instance of java.io.File, you can simply use the toPath(), method on that instance. It is important that you use the readAllBytes method because it is not only very simple, but it returns the data in the file as a byte array, which fits the implementation of the ByteBuffer function. Now, the ByteBuffer function is what I think best for you to use to serialize (aka store as a series of numbers or bytes) the information contained within any simple class. NOTE: SIMPLE CLASS. Your Team class isn't exactly simple, but I will get into what you should do about that after I demonstrate serialization here. Now, the ByteBuffer class is very simple, but it does have some caveats that I will get into soon here. But for now, let's move on to actually serializing your data so that it can be written to your save data file. First off, you're going to want to add the methods "toBytes", and "fromBytes" into your Team class. These methods should take a ByteBuffer as an output and input respectively. That should be all they need. Now, ByteBuffers work by reading data from a byte array and spitting out the data. I think this is going to be best shown with some code, so lets imagine we have some class we want to turn into bytes, and it has a boolean, a double, and a float as it's variables. If you were to implement the above into this class, it should look something like this. public class MyClass { float floatValue; double doubleValue; boolean booleanValue; // Gets the required size of the Buffer to store our information // This can really be replaced with some big number like 1000 if you don't want to have to deal with size serialization // However, the above isn't exactly recommended if you care about good code private int getSize() { return 4 + 8 + 1; // Size of a float (4 bytes) plus the size of a double (8 bytes) plus the size of a boolean (1 byte) } // Takes all class values and writes them to a ByteBuffer so it can be written to a file public ByteBuffer toBytes() { ByteBuffer retValue = ByteBuffer.allocate(this.getSize()); retValue.putFloat(floatValue); retValue.putDouble(doubleValue); retValue.put(booleanValue ? 1 : 0); } // Takes the ByteBuffer created from the contents of the file and sets all class values accordingly public void fromBytes(ByteBuffer buf) { floatValue = buf.getFloat(); doubleValue = buf.getDouble(); booleanValue = buf.get() == 1 ? true : false; } }Now, it is important to note that the ByteBuffer function, although easy to implement, it is very primitive, and with more complex data types such as strings and lists, it can be much harder to use than the netty ByteBuf class. The ByteBuf class is practically the same as the ByteBuffer class, except it has much more versatility. You would probably want to use this class for handling your data as opposed to the ByteBuffer class. I just use the ByteBuffer class here because it is a bit easier to demonstrate and describe specifically in examples. If you want to use the ByteBuf class, you need to instantiate and instance of ByteBuf by doing something like Unpooled.buffer() if you are creating an empty buffer, and Unpooled.wrappedBuffer(fileByteArray) if you are creating a ByteBuf with a byte array already put into it. Now, I believe the ByteBuf class is intended to be used for networking serialization rather than file stream serialization, but it's just too good not to use here, so although this is a bit of an inappropriate usage of the class, things should still be fine. Simply just use ByteBuf in the same way as described for ByteBuffer above. Make sure to use the right methods when handling data. With all that said, you should be practically done here and ready to write your code to handle saving and loading your custom data. You will have to take the liberty with how you are going to handle serializing your data. I will give you some quick pointers here for how to do that. STRINGS These guys can be a bit annoying to deal with, but the best way to do it is, if you are using a ByteBuf, to write the size of the string first, then write the characters of the string to the array, which can be done with the writeCharSequence method. String are implicitly CharSequences, so you shouldn't have to worry about casting, and use Charset.defaultCharset as your second argument. When reading the string data, read the integer first, which is the size of the string, then use the string size with the readCharSequence function. You might need to instantiate a new instance of String to convert a CharSequence to a string. LISTS/ARRAYS These can be serialized much the same way as strings, with the only difference being that you aren't serializing an array of chars, but an array of specific data types. Basically, read or write the size of the list to the ByteBuf, then iterate over either the size of the list and individually serialize or deserialize each object instance individually. OTHER CLASSES If there is another class that you wish to serialize or deserialize, then if it doesn't have the built in methods for converting to or from bytes, just find a way around storing them as data by any means. If you have no choice, then you will have to build your own functions to serialize and deserialize other classes you wish to use. Some classes may be convertible into arrays that can be serialize or deserialized, such example being UUIDs, which if I remember correctly, can be converted into an array of bytes through a built in function and such an array can then be serialized. Hopefully you find this helpful enough to be able to figure out what you need to do now on your own. If you do not fully understanding something that I have mentioned here, then please use the tools at your disposal to understand it better. If you are still struggling and need some pointers or additional advice, please reply to the thread with any questions or concerns you may have. I did not go fully into detail here, but rather just provided some pointers on what to do. I will clarify again, if you do not understanding something here, do not be frustrated, as I didn't put nearly enough effort into this reply in order to fully describe the topic at hand. Remember to pray before running your code. Little know fact, but all great programmers carry a bible, a cross, and some holy water just in case they run into any errors of biblical proportion that requires divine intervention in order to solve. Please let me know if this helps or not.

UPDATE: Okay, so I have a really good fix going on rn, but the problem still isn't exactly solved. Although the quick fix works well enough to be practical, it's not exactly perfect and can cause bugs. Basically, I just injected code at the start of the execute method of the execute command, as well as many others that search the argument list for the string "commands:onepunch" (the name of the super item that I don't want my friends to be able to have), and if it detects said string, it forces the function to return without doing anything. This might sound like a foolproof method of preventing anyone from getting the super item, which it is, but the problem is that it's a bit too foolproof. Instead of the logic behind the practical obtainment of this item in reference to commands being something like, "You can't spawn in this item by any means unless you are the server owner", it turns it into something like, "You can't reference the item in ANY WAY in commands unless you are the server owner." This could cause some issues, like, for example, if I were popbob, and I were to run the command "/execute @e[type=sheep] ~ ~ ~ give popbob commands:onepunch", the code would run the execute command successfully, even though it detects that the super item is referenced because popbob, me, the server owner, is running the command. However, because it is still not able to differentiate between a /execute trigger for a command and a directly run command, even though I am the one who ran the execute command, it will fail once the /give part of it is passed to the sheep. Although for all practical purposes I am happy with what I have so far, it still doesn't really work as intended, so I'll refrain from tagging this thread as solved in the hopes that somebody can come up with a solution to the specific problem at hand.