How to fix mods after updates ?

GobiGobi Join Date: 2013-05-28 Member: 185390Members
Hi, I'd like to have some clarifications about the updates and the way UWE is working.

- UWE wants mods. They tried to made NS2 easy to mod, but there is still no documentations on how things work. You have to find everything on your own by looking at the code... Or I may be missing something, in this case I'll be glad to have any informations. (And don't mention the JSON api, without doc it is really totally uberly not dev friendly)

-Updates break mods some times.
Ok updates are great and UWE is doing the job well :D but...
Can't the UWE team post what is being modified and how to fix mods ?
Can't they give the community a way to mod that will be unbreakable ?
Or at least have better logs when the NS2 crash (if there are commands to have full debug, please share).

I think that's a great thing to give tools to the community, but UWE needs seriously to spend some time on documenting the mod creation.
They have the knowledge, all they need to do is to share with the community
I think the ROI will be awesome and justify the time spent on it.


p.s: I'm editing Rio's hidden mod and it doesn't work anymore, application crash after checking files for consistency. If anyone has a suggestion...

end of log:
Hashed 1 game_setup.xml files for consistency
Hashed 814 *.lua files for consistency
Hashed 40 *.fx files for consistency
Hashed 18 *.screenfx files for consistency
Hashed 117 *.surface_shader files for consistency
Hashed 3 *.fxh files for consistency
Hashed 3 *.render_setup files for consistency
Hashed 2 *.shader_template files for consistency


  • RioRio Join Date: 2005-01-28 Member: 38716Members
    edited June 2013
    The crash is probably because of the new Lua JIT. I'm modifying and hooking some Spark Engine Lua functions in my mod which are defined in the engine, not in Lua itself, that's probably what causes the bug. I haven't spent much time investigating what causes the crash, so it's just an assumption.
  • GobiGobi Join Date: 2013-05-28 Member: 185390Members
    Thanks for the infos :) in fact the problem comes from the lib classes (LibLocales.lua) if you remove it, ns2 will not crash, but it still doesn't work. However we can now have access to the console and logs to see what's wrong.
    I don't have much time to spend on the mod now so let me now if you have the solution.

  • MetaMindMetaMind Join Date: 2012-12-06 Member: 174358Members, Reinforced - Gold
    I absolutely agree to Gobi...
    As a modmaker myself I m desprately struggling making my "Last Resistance" Mod functional again but I was not successful.
    UWE really should make some more indepth changelog and make it more mod adaptable, this would be awesome.

  • RioRio Join Date: 2005-01-28 Member: 38716Members
    Seems like it's fixed with build 500.
  • McGlaspieMcGlaspie Join Date: 2010-07-26 Member: 73044Members, Super Administrators, Forum Admins, NS2 Developer, NS2 Playtester, Squad Five Blue, Squad Five Silver, Squad Five Gold, Reinforced - Onos, WC 2013 - Gold, Subnautica Playtester
    This thread should get some official attention.

    Unfortunately, I'm well versed in this problem. The true downside is, the more you mod the game away from NS2, the greater the problem becomes. There are several reasons why this happens, but mostly due to what (in concept) mods are in contrast with vanilla. The easiest way to put it is mods aren't modifications, they're hacks. The nature of how Lua functions from a language design angle and its utter lack of genuine polymorphic mechanisms means there is not a clean way to address the problem. Lua just wan't designed to address problems like this.

    The easiest thing UWE can do "right now" to help diminish the problem is bringing back the Build Version lock-in option for the publisher and how Spark handles mods. If mod author's could lock-down a mod to require a version of the code they developed on and know works, we'd see a lot more actively installed mods on servers. The spin-off problem is mod compatibility with other mods. Simple example, if a mod was written and locked into B248 that is gameplay mod, but server admins want to use the latest version of a server admin mod (that's updated on current build, say B250), then the two mods become incompatible and crashes are almost a certainty. This is bad, very bad. It's absurd to expect all the mod author's to get organized and synchronize updates or whatever else is needed to make everything out there mesh together smoothly. All of us modders have our own timetables, methodologies, and commitments IRL that make this impractical.

    It's essentially a lose-lose situation right now, and frankly, the build locking is only applying duct-tape to the problem. How things have gone so far forces mod author's into constantly keeping up with the updates UWE makes. UWE is a game studio, they do this work for a living 40~ hours a week. Not all the modders out there have the time or inclination to spend their free time just maintaining their mods. This is not a good way to encourage people to make mods. Had I known there was going to truly be this much upkeep time, I wouldn't have done MvM in the first place. It's not fair to the modders, nor the players that wish to play said mods.

    Yes, I am well aware of Sewlek's work with his framework. It's a good idea, and I like the mechanisms it provides. However, how it works is by-nature tuned to only tweaking vanilla ns2. Not devising large and extensive modifications, total conversions (full replacements of vanilla game). It also doesn't nothing to address version discongruity (multiple mods locked to different versions of vanilla codebase all being loaded at the same time).

    Imo, this is a huge problem that UWE needs to try to address in a comprehensive way ASAP. They have their work cut out for them though because this is inherently a very complex problem that won't have a simple solution, and will almost certainly require refactoring quite a lot of the current codebase ( 'core' and 'ns2' ). The whole problem is confusing to me, because UWE made the decision to write their own engine partly to increase moddability. It is quite moddable, but not very maintainable. So, we're sort of in a catch-22.

    If I had some scheme or idea to solve this I'd gladly write it up, but for now a truly clean solution eludes me.
  • acid_rainacid_rain NS2 NAPT Mascot Austin, TX Join Date: 2010-02-16 Member: 70588Forum Moderators, NS2 Playtester, Squad Five Blue, Subnautica Playtester
    Call/hook interceptors in .dll or .so format plox!
  • McGlaspieMcGlaspie Join Date: 2010-07-26 Member: 73044Members, Super Administrators, Forum Admins, NS2 Developer, NS2 Playtester, Squad Five Blue, Squad Five Silver, Squad Five Gold, Reinforced - Onos, WC 2013 - Gold, Subnautica Playtester
    acid_rain wrote: »
    Call/hook interceptors in .dll or .so format plox!
    While an appealing idea, that would introduce a wide array of security issues. Not too mention callbacks to hacking programs

  • snozysnozy Join Date: 2013-05-21 Member: 185318Members
    I've been playing with none of my mods working, sadly...

    I have like 9 reskin mods that make the game look better, but nobody wants to update them :( UWE should pay the modders to update those mods. With my favorite mods working, I'll keep playing this new balance test. Though once the game reaches 100% NS1-magic, I won't need mods, maybe a music overhaul mod would be nice though.
Sign In or Register to comment.