Jump to content

agaricus

Members
  • Posts

    9
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed
  • Personal Text
    I am new!

agaricus's Achievements

Tree Puncher

Tree Puncher (2/8)

2

Reputation

  1. You can use MCP to deobfuscate by adding your mod classes to the Minecraft jar and then decompiling, or (perhaps easier) deobfuscate by feeding your mod jar to a tool like BON. You may be seeing apparent ambiguity in the obfuscated code since the Java runtime additionally uses type information to uniquely identify symbols. Nothing is stopping the bytecode from using the same name if it unique according to the JVM, for example see: https://github.com/MinecraftForge/FML/issues/210 (since fixed). Additionally the same name can be reused in a different context, so it cannot be substituted purely textually. But FML, MCP, BON, etc. all deobf properly and reliably.
  2. If you're using MCPC+ (btw, the MC Port Central forums would probably be a better place for this question; should've noted that earlier..), plugins with net.minecraft.server.EntityPlayer and other NMS classes will be reobfuscated automatically. More specifically, NMS is reobfuscated to srgnames -- net.minecraft.entity.player.EntityPlayerMP, in this case. FML runtime-deobfuscates Minecraft and mods from obfuscated "Notch" names (sq, etc.) to srgnames, so the actual classes loaded at runtime will all be using srgnames. Whether you're using mods or plugins, this remapping happens behind the scenes; you can use obfuscated symbols or srgnames symbols or mc-dev NMS symbols in your code, all will be automatically converted appropriately on load as needed.
  3. While some of the Spigot patches can cause problems for mods, many of the smaller patches are not as problematic. Also the changes are grouped together in separate patches so they can be applied or rolled back individually, if needed. For MCPC+, I applied most all of Spigot's patches, though a couple I turned off by default (so far, disabling chunk tick aggregation since it does reduce ticking noticeably affecting gameplay, as you said; also turned off entity range activation since I expect most players on modded servers will want their entities to be activated no matter how far they are away, but, either feature can be re-enabled in the config if desired). Many of Spigot's improvements, if they prove stable and safe enough, end up getting pulled into vanilla CraftBukkit. CraftBukkit itself has quite a few performance and stability fixes, above and beyond its plugin API which it is most well-known for. However, some of these enhancements even in CraftBukkit can cause unintended interactions with mods. Asynchronous chunk loading, for one. Caused tons of crashes with XyCraft, for example, due to the order which it loaded chunks (not too clear on this problem to be honest, but nallar recently submitted a fix to clear up some if not most of these concurrency issues with XyCraft in MCPC+, by not calling the Forge event asynchronously). But a lot of the changes are fairly benign. Some are even vanilla bug fixes (of course, Forge includes some vanilla bug fixes too). Just one example, CB gets tile entities from the chunk map directly instead of a bounding box on the world; avoiding the off-by-one error which loaded additional chunks, as well as avoiding the expensive searching operation. Maybe this could impact some mods, somehow, granted. Something I've been wanted to work on for a while, but haven't got around to it yet, is automatically remapping Spigot's patches ala MCPBukkit. Main reason why I have not yet is because Spigot is developed as a set of patches on top of CraftBukkit (similar to how Forge and FML include patches on top of vanilla), so the logistics of maintaining a linear history on the remapped source would have to be determined. Should be possible though, just would need non-trivial changes to the automation script. Not to say the changes can be blindly integrated, but would be nice to have an auto-remapped repository of both Spigot and CraftBukkit for reference purposes, to see if their changes could feasibly benefit Forge, imho. Or possibly a coremod could be developed by someone to add the individual optimizations. TickThreading basically does this, adding threaded ticks, but it also has to patch the mods for thread-safety purposes.
  4. While some of the Spigot patches can cause problems for mods, many of the smaller patches are not as problematic. Also the changes are grouped together in separate patches so they can be applied or rolled back individually, if needed. For MCPC+, I applied most all of Spigot's patches, though a couple I turned off by default (so far, disabling chunk tick aggregation since it does reduce ticking noticeably affecting gameplay, as you said; also turned off entity range activation since I expect most players on modded servers will want their entities to be activated no matter how far they are away, but, either feature can be re-enabled in the config if desired). Many of Spigot's improvements, if they prove stable and safe enough, end up getting pulled into vanilla CraftBukkit. CraftBukkit itself has quite a few performance and stability fixes, above and beyond its plugin API which it is most well-known for. However, some of these enhancements even in CraftBukkit can cause unintended interactions with mods. Asynchronous chunk loading, for one. Caused tons of crashes with XyCraft, for example, due to the order which it loaded chunks (not too clear on this problem to be honest, but nallar recently submitted a fix to clear up some if not most of these concurrency issues with XyCraft in MCPC+, by not calling the Forge event asynchronously). But a lot of the changes are fairly benign. Some are even vanilla bug fixes (of course, Forge includes some vanilla bug fixes too). Just one example, CB gets tile entities from the chunk map directly instead of a bounding box on the world; avoiding the off-by-one error which loaded additional chunks, as well as avoiding the expensive searching operation. Maybe this could impact some mods, somehow, granted. Something I've been wanted to work on for a while, but haven't got around to it yet, is automatically remapping Spigot's patches ala MCPBukkit. Main reason why I have not yet is because Spigot is developed as a set of patches on top of CraftBukkit (similar to how Forge and FML include patches on top of vanilla), so the logistics of maintaining a linear history on the remapped source would have to be determined. Should be possible though, just would need non-trivial changes to the automation script. Not to say the changes can be blindly integrated, but would be nice to have an auto-remapped repository of both Spigot and CraftBukkit for reference purposes, to see if their changes could feasibly benefit Forge, imho. Or possibly a coremod could be developed by someone to add the individual optimizations. TickThreading basically does this, adding threaded ticks, but it also has to patch the mods for thread-safety purposes.
  5. If anyone is still interested in something like this, here's my stab at it: https://github.com/agaricusb/ForgeMod It should be considered experimental and unofficial, but I've been using it for all my (admittedly few) mods, for some time now, working fairly well. SrgTools turned out to be a dead end, but a new SpecialSource project arose which became quite useful for this purpose. Comparing this SpecialSourceMP-based build system to the standard system: versus: 1) run "mvn initialize -P -built" to initialize a remapped dependency to build your mod against 2) run "mvn package" to compile your mod against this dependency and reobfuscate Notably this technique avoids any need to copy the source, and it only recompiles/reobfuscates your mod source, rather than all of Minecraft. Also simplifies source code management and setup, since your project directory only needs to contain your own source code (I've reviewed dozens of build scripts for open source Minecraft mods, usually with some variation of 'copy source to MCP dir'.. this new process avoids all that). Depending on the circumstances it can be several times faster (observed 120x-6x speedup). As I said, this process is experimental, but I welcome any feedback if anyone uses it, let me know how well it works.
  6. If anyone is still interested in something like this, here's my stab at it: https://github.com/agaricusb/ForgeMod It should be considered experimental and unofficial, but I've been using it for all my (admittedly few) mods, for some time now, working fairly well. SrgTools turned out to be a dead end, but a new SpecialSource project arose which became quite useful for this purpose. Comparing this SpecialSourceMP-based build system to the standard system: versus: 1) run "mvn initialize -P -built" to initialize a remapped dependency to build your mod against 2) run "mvn package" to compile your mod against this dependency and reobfuscate Notably this technique avoids any need to copy the source, and it only recompiles/reobfuscates your mod source, rather than all of Minecraft. Also simplifies source code management and setup, since your project directory only needs to contain your own source code (I've reviewed dozens of build scripts for open source Minecraft mods, usually with some variation of 'copy source to MCP dir'.. this new process avoids all that). Depending on the circumstances it can be several times faster (observed 120x-6x speedup). As I said, this process is experimental, but I welcome any feedback if anyone uses it, let me know how well it works.
  7. Actually its the opposite. FML deobfuscates everything to srgnames at runtime, including Minecraft itself. Runtime deobfuscation is always enabled [1], so obfuscated mods will be deobfuscated at runtime as well, though version-independent mods won't need deobfuscation. But the transformer still runs, and several other transformers run as well (for access, siding, coremods, etc.); I would not expect you to see any noticeable performance difference from version-independent/version-dependent mods (but I haven't benchmarked anything, FWIW). Also note the transformation only applies at class load time - once the classes are loaded, they are as fast as any other class. [1] Not quite true, FML will skip runtime deobf if it detects a non-obfuscated environment, e.g. testing with MCP's start scripts. The other instance where runtime deobf is disabled was: I had to temporarily disable deobfuscation in the early builds of MCPC+ 1.5.1 due to an issue with the server deobfuscating itself (FML issue #210 if you're interested, some obscure edge case with overloaded fields), effectively "pre-deobfuscating" the server at compile-time. This had the consequence of only supporting version-independent mods since the deobfuscation transformer did not run for them either. But as of builds 261+, runtime deobf is now enabled, so both types of mods should load. I just tested loading Millénaire, works great (awesome mod btw, great work). Going back to the question of performance, for MCPC+ I considered continuing to pre-deobfuscate the server (but enabling deobfuscation of mods), with the hope of better startup times. Forge and FML have to deobfuscate Minecraft itself due to how they are distributed (patches over vanilla classes), but since MCPC+ being based on CraftBukkit is a complete server jar, theoretically it could be deobfuscated at compile time. I.e., rather than remapping from MCP csvnames in the source code -> obfuscated names in the compiled binary -> deobfuscated srgnames at runtime, cutting out the middle step and going straight from csvnames in the source -> srgnames in the compiled binary. In fact this is how MCPC+ was built temporarily since the deobf issue was with obf -> srgnames, but now that that works, MCPC+ is compiled to obfuscated names just like a vanilla server. Maybe pre-deobfuscation is something that could be reconsidered in the future, but its probably not worth it, would be non-trivial to implement and again I expect little to no performance benefit. About the only con is that your mod might work when you don't want it to . "Version-independence" only guards against obfuscation changes - unfortunately not actual code changes (only real way to do this is with an API). So if Mojang changes the code a mod relies on, it may not work as intended. In 1.5, texturing significantly changed, several older methods which mods relied on no longer exist. And most all mods use textures of course. Not to mention, reobfuscate_srg was added in 1.5. But throughout the 1.5.x minor releases, you can expect version-independence to take effect. A couple mods built with srgnames for 1.5 already work for 1.5.1 (Portal Gun and Gravity Gun at least). This is an interesting point - as Lex explains, srgnames were chosen for FML runtime since they are as version-independent as possible. The mapped descriptive csvnames are up to the community via MCPBot submissions, so they are more volatile than srgnames. So curiously, a mod's compiled binary may be more stable across versions than its source code. One way to ensure version stability of source is to write your mod using srgnames. This is the approach FML itself takes, and it works pretty well for this purpose. But the downside is the user-unfriendliness of srgnames - with FML's relatively small patches, its not too big of a deal, but if you're writing a large Forge mod using srgnames everywhere would just be unbearable, leading to unreadable code. And after all, the mapped csvnames are intended to be descriptive and human-readable. Another possible solution is to use csvnames, but with a source-remapping tool to update the names automatically. We now have Srg2source, which can mass-rename large source code bases thousands of times faster than any IDE's built-in rename refactoring tool. Currently it is being used to automatically remap each commit of CraftBukkit into MCPBukkit, and it is tailored for that purpose, but in principle it could be reworked as a more general-purpose tool for modders. Something I've been wanting to look into, but haven't got around to it. A tool sort of like MCP's updatenames, but supporting not only renaming unmapped names (srgnames) to mapped names, but also arbitrary symbol renames between MCP updates. However, even if such a tool was used, it wouldn't take care of all symbol changes. Renames of mapped symbols are relatively rare (MCPBot requires a force update command, and its considered polite to only rename very poorly named symbols since it can break people's mods). In the 1.4.7 to 1.5.1 update, many symbols which appear to have been renamed were actually new altogether. The world block setting methods, for one. Signature changes, new parameters, regarded as new symbols by srgnames. So a source-based remapping tool using srgnames wouldn't take care of these situations. Still would be cool to have such a tool packaged up and easily available for modders to use, though (srg2source works today for this purpose, but it may not be the easiest tool to use unless you want to read the code and see how it works, what options are required, generating the update mappings, etc).
  8. Maybe this tool could help? https://github.com/agaricusb/SrgTools
  9. You may want to take a look at the CraftBukkit server, (though its not compatible with Forge) they've made many optimizations, including data structure improvements. The changes can be found here: https://github.com/Bukkit/CraftBukkit/tree/master/src/main/java/net/minecraft/server - notably: AABBPool is rewritten to use an "intelligent cache", Chunk's entitySlices is changed from an ArrayList to UnsafeList, ChunkProviderServer's unload queue and chunks map is changed to a LongHashSet and LongObjectHashMap (indexed by LongHash.toLong(i,j)), BlockRedstoneWire and ServerConfigurationManagerAbstract uses a LinkedHashSet instead of HashSet, and various other tweaks. Maybe you could port these optimizations to Forge?
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.