Posted September 29, 2015 can reveal now params of server like cele, indy, xana? Share this post Link to post Share on other sites
Posted September 29, 2015 (edited) its possible to make mod on different engine? I like torque3d, so cant port java scripts to torquescripts? Edited September 29, 2015 by ftoz Share this post Link to post Share on other sites
Posted September 29, 2015 What is wrong with Forge? I works really well for the person using the mods. If its so bad why has it for the most part become the standard? From my perspective as an end user the problems were that 1) modders couldn't agree on a standard mod loading API, 2) Minecraft updated in a way that was not at all convenient for modders.I don't have any Java skill so I could be very wrong, I think what needs to happen is folks need to agree to use some kind of a standard mod loading process. My point in referring to Forge was not that it's an awesome Mod platform. It is that it works very well for end user and most people agree to use it. The key to success is that everyone agrees to a standard.It was the part about updating i meant. It is quite easy to solve that issue If you understand bytecode engineering. A few of us even approached the dev teams back in the days, proposing a solution that would ensure mods did not break between game updates Assuming nothing fundamental changed. Unfortunately they shrugged it off as impossible, despite the fact that many of US has done it for the game RuneScape (which is significiantly more complex in its obfuscation).Naturally i agree that a standard is required, and that such a standard should be discussed in depth with the community once the time arrives. Share this post Link to post Share on other sites
Posted September 29, 2015 And as for creating a standard for wurm that won't break on updates, i already have an idea how to do it easily and quickly. I am on my phone at work at the moment, but if anyone is interested, i will gladly explain it. Share this post Link to post Share on other sites
Posted September 30, 2015 And as for creating a standard for wurm that won't break on updates, i already have an idea how to do it easily and quickly. I am on my phone at work at the moment, but if anyone is interested, i will gladly explain it. I will be happy to help if there will be something that requires Wurm dev attention. (personally I think that future of WU is modding) Share this post Link to post Share on other sites
Posted September 30, 2015 I will be happy to help if there will be something that requires Wurm dev attention. (personally I think that future of WU is modding) As do i! This being an unproven idea, i will experiment with the concept tomorrow, by the time WU is out it should be a matter of hours to implement Share this post Link to post Share on other sites
Posted September 30, 2015 It's logical to assume that the server code will be compiled and obfuscated. Decompiling and deobfuscating can give you a first view inside the mechanics of the game based on which you can code an API that wil be the base for all mods and libraries that will be built on top of the server. The problem imo arises when the server updates and the obfuscator changes all variables/methods/classes names on compilation. So essentially what you have is a completelly different version of the previous server release which makes coding the API and keeping it updated pretty difficult. Share this post Link to post Share on other sites
Posted September 30, 2015 It's logical to assume that the server code will be compiled and obfuscated. Decompiling and deobfuscating can give you a first view inside the mechanics of the game based on which you can code an API that wil be the base for all mods and libraries that will be built on top of the server. The problem imo arises when the server updates and the obfuscator changes all variables/methods/classes names on compilation. So essentially what you have is a completelly different version of the previous server release which makes coding the API and keeping it updated pretty difficult. Both client and server will be not obfuscated, so - while behavior or names of some methods/variables can change between versions, this shouldn't be a very big problem. 2 Share this post Link to post Share on other sites
Posted September 30, 2015 Epic, thank you very much That will make API creation very easy. Share this post Link to post Share on other sites
Posted September 30, 2015 It's logical to assume that the server code will be compiled and obfuscated. Decompiling and deobfuscating can give you a first view inside the mechanics of the game based on which you can code an API that wil be the base for all mods and libraries that will be built on top of the server. The problem imo arises when the server updates and the obfuscator changes all variables/methods/classes names on compilation. So essentially what you have is a completelly different version of the previous server release which makes coding the API and keeping it updated pretty difficult.That is precisely the problem you solve with pattern recognition in bytecode engineering as it removes the need to deobfuscate in the first place, and scrambled names are of no consequence. However, since it won't be obfuscated, my other system will likely work very well Share this post Link to post Share on other sites
Posted September 30, 2015 So if I get this right, what you do is, for a given class / method you read the byte code instruction set sequence and figure out it's unique "DNA" that maps it to a functional piece of code regardless of obfuscation. Smart Share this post Link to post Share on other sites
Posted September 30, 2015 So if I get this right, what you do is, for a given class / method you read the byte code instruction set sequence and figure out it's unique "DNA" that maps it to a functional piece of code regardless of obfuscation. Smart Precisely! I will use bytecode manipulation for my other idea as well. Basically, the server/client will be scanned to generate a "skeleton" API of all classes for a given release, and then you target scripts toward that skeleton. When a script is loaded into the engine, it will first be modified by a bytecode routine to replace all references to the skeleton with ones from the actual server/client. This way, it is easy to Keep the API up to date with minimal manual work, and additionally keep it up to date automatically with new releases. If something changes, the old definition is annotated with @depreciated and an additional tag denouncing what version it was available in. Share this post Link to post Share on other sites