Modding vs. Hacking or the Dark Side of Kaels Tutorial

[theWul]

Lots of posts are from people having troubles runnig mods or combinations of mods.

So I think it's time for some critics about Kaels tutorial - but first and foremost thanks for the job he has done.

As good as most parts of the tutorial are, those where it gets into moddifying or overwriting core game files are bad. Very bad.
Mods using techniques as in the modlist example are going to fight each other with unpredictable results. ie. if anybody tries to add his own menu item (like modlist) from scratch it's gonna break modlist, or modlist would break it.

So please guys: DO NOT OVERWRITE OR COPY/REPLACE CORE GAME FILES.

In a couple of month we'll have safe techniques to hook into various UI/Game elements, there's no need for mods fighting each other like WoW had for 4 years ...

 

[Dave Lawson]

...
In a couple of month we'll have safe techniques to hook into various UI/Game elements, ...

Really? I'll believe that when I see it. I assume by safe you mean utterly modular.

 

[Pazyryk]

Your point is valid for add-on tweaks to the game that need to play nicely together. But why does someone making a Medieval or Ancient Mediterranean mod need to worry about whether Better Helicopters Mod hooks up or not? I think Kael is addressing those modders too. And I also don't see what can ever make modding "safe," other than funneling all access through a gui that limits what you can do. (Although a little error reporting from the db would be nice.)

 

[shinkicker]

Kael's Guide makes it sound like mods MUST necessarily delete objects that are being replaced. Or am I reading this wrong?

Civ4 modders will be accustomed to replacing files to make changes. If a new Civ4Civilizations.xml file is added to the mod the base Civ4Civilizations.xml won't be used. That is not the case with Civilization V. Instead of replacing files all mods automatically inherit the base objects, and modders must delete those objects if they aren't to be used in this mod (this guide will cover how to do that later). A modder creating a Civil War mod can create a Union and Confederacy civilization, but will also need to explicitly delete the base civilization's so that they aren't available (otherwise, France, Russia, etc will be available civilizations in the Civil War mod).

The advantage of this is that it makes mods modular. The game assumes that all assets are being used unless a mod specifically tells it not to. That way one mod may add a Canadian civilization, one mod may remove the German civilization and replace it with a new one, and another mod may add an Atlantis civilization. These mods can all be loaded together without any special integration by a modder. With enough mods available every players preferred mix of mods can be effectively unique.

I agree with theWul about preserving core game files. That's a pretty standard habit for good modders in any game. Now I find myself wondering if my new mod idea is going to require me to remove an existing civ from my installation?

 

[Dave Lawson]

Deleting replaced objects? I'm not so sure. If you include a new version of a core file, it overrides that file, but you don't actually delete it. Certainly you never remove it from your installation. Those original files are sacrosanct and should ideally never be open in anything but read-only mode.

 

[Shiggs713]

its kinda strange that he used the Civil War mod as his example, because for civ4, that is exactly what I had to do to make the Civil War mod. I even removed most of the era's, it was a nightmare. And I'm not talking disabling, I'm talking completely removed. I did get it to load up without crashing or anything, but it was a 200mb behemoth of a mess. Probably the reason it was never completed.

You really don't have to remove the old stuff, if you don't mind your civlopedia (or excuse me, help button) having a bunch of useless stuff in it.

 

[Dave Lawson]

Can you not remove entries from the civ pedia? Can't say I've yet bothered with the pedia.

 

[Pazyryk]

Just a question for you guys: If you aren't using any post-medieval unit in your mod, then is it better to leave them in (but unaccessible) or to delete them? I thought the later would be better to save resources and make a faster mod. It sounds like the consensus here is for the former. I could probably be persuaded to that view, but the arguments so far just don't apply to the kind of mod I'm thinking about (e.g., TAM or FFH). My feeling right now is that if I'm going to add 30 units and not use anything from core civ5 (except maybe a warrior and spearman) then it's better to delete.

 

[Dave Lawson]

It's a bit frustrating to talk about deleting this way, as deleting can mean two entirely different things.

If you mean deleting the content from the core xml files themselves, I would submit that this is entirely contrary to the new modding philosophy, and will (I suspect) entirely prohibit distribution via the in game modding utilities. In general it makes mod management more painful. The advantage is that initial load times will be reduced. I don't expect in game performance to be significantly affected.

If you mean adding xml files that contain delete statements which clean out the old, unused data from the database, I would say that this is probably the best way to go at the moment. Obviously, you end up loading data that you don't need, and that'll hurt load time. Come run time though, these elements are gone, so you shouldn't be affected.

If you mean adding xml files that disable content using the disable tag, and setting costs to -1 etc, I think this is probably a bad idea. Load time will worsen, and at run time you'll have a lot of crap residing unecessarily in memory.

 

[Pazyryk]

Dave,

No, I don't mean modifying the core files. I understand why that's a bad idea. But Kael's guide most definitely does NOT tell you to do that. His deletes are all your second option (xml files that contain deletes, or sql deletes). But I'm pretty sure that this is what theWul is referring to as a "hack", while I'm still viewing it (until convinced otherwise) as optimization.

 

[deanej]

its kinda strange that he used the Civil War mod as his example, because for civ4, that is exactly what I had to do to make the Civil War mod. I even removed most of the era's, it was a nightmare. And I'm not talking disabling, I'm talking completely removed. I did get it to load up without crashing or anything, but it was a 200mb behemoth of a mess. Probably the reason it was never completed.

You really don't have to remove the old stuff, if you don't mind your civlopedia (or excuse me, help button) having a bunch of useless stuff in it.

Why did you remove the eras? It's not like they show up in the civilopedia or anything. But removing things was a lot simpler in civ4, since you essentially overwrote the main files. I knew civ5's total modularity would favor add-a-civ type mods and would be bad for everything else. Mods for civ5 are less polished under the hood than in civ4, that's for sure!

 

[Dave Lawson]

I completely agree about using delete statements instead of paring down files. Infact, I expect theWul also agrees with you.

What theWul takes exception to (I think) is particularly those files that need to be wholesale replaced in order to promote certain functionalities, such as adding the modlist screen. If two mods need to add a button to that list, suddenly you have a significant conflict, and manual integration becomes necessary.

While I can't see anyone arguing that these inevitable conflicts are a good thing, I also can't see them disappearing. Especially since we have so few options for modding at the moment, we need to take advantage of what we can, and finding ways around some of these problems. Bhruic's mod for generating notifications is a great example of exactly the sort of mods we should be focusing on right now, as they extend the modding toolbase for further work, and help address potential conflicts.

 

[Laurino]

It sounds like the consensus here is for the former. I could probably be persuaded to that view, but the arguments so far just don't apply to the kind of mod I'm thinking about (e.g., TAM or FFH).

Kael speaks of the "necessity" to be able to combine mods. He also says that some mod, only a few, will be exclusive. As quoted, TAM (which I work on) or FFH, will be exclusive mods, since they consist on not only modifying things, but actually "re-engineering" the game for most of their content. Of course, having a "luxury menu" mod that isn't modular is bad design, but having a TAM mod that has Uranium in it doesn't fit, even if un-used, it just doesn't fit to have it in the "help" section. Then again, those mods are long to make, so I assume that at one point, it'll be easier. So far, I've been ripping Civ5 from most of it's feature so we can work from scratch, and believe me my friends, it IS a pain... When I think about it it was hard in Civ4 too at the start, I guess it's just a question of getting used to new ways...

 

[Shiggs713]

Why did you remove the eras? It's not like they show up in the civilopedia or anything. But removing things was a lot simpler in civ4, since you essentially overwrote the main files. I knew civ5's total modularity would favor add-a-civ type mods and would be bad for everything else. Mods for civ5 are less polished under the hood than in civ4, that's for sure!

I dunno, I'm just anal like that. Everything has to be perfect. I agree with you on your take of civ5 mods. I doubt there will be half as many total conversion mods as there was for civ4, or at least not to that level of detail that we saw.

 

[Laurino]

I dunno, I'm just anal like that. Everything has to be perfect.

That's the thing when you not only mod the game, but convert it. I understand what you mean... No way should anyone be able to see Uranium in TAM And I will work a month only to make sure than no one playing TAM can ever get infos on ICBM. Guess it's all about state of mind...

 

[hammypants]

He's talking about deleting it from the database upon load, so it will not be loaded for the mod. Not deleting an actual file on the hdd. See: SQL.

 

[theWul]

To clarify what I meant with "save techniques":
I'm pretty sure that adding a button to a core menu can be done by hooking into some events, without having to copy and modify any game files at all.
And I asume similar safe techniques exist for every single .lua modification.
Conclusion:
1. Coding problems can be totally avoided by proper coding techniques.
WoW modding (an almost identical environment) is the proof for that.
2. Content problems like adding or removing civs, units or techs are something different - it is impossible to avoid interferences at all as the XMLs and SQLs by design modify the same databases.

 

[xienwolf]

Absolutely NOWHERE in the guide does it ever tell you to modify core game files. The only time he mentions TOUCHING those files is when he tells you that for LUA modifications you need to open the base LUA file and copy it all into your new LUA, which has the same filename so that it overwrites the other one.


All talk about deleting things during the XML portion of his guide talk about deleting it FROM THE SQL DATABASE, which is not going to irrevocably alter your gameplay when you remove the mod in question someday.


There are some things (not too many) in LUA which are impractical to do via event hooks (mostly just UI related issues, like adding checkboxes/icons to existing menus). And many things which you COULD do by an event hook, but where you need a hook at doesn't have one by default.


Based on the title of the thread, I thought you would be talking about making mods such that they grant you information you aren't intended to see, or swapping the Like/Hate buttons or whatever in his little "joke" example on editing text strings. Though the term "Hack" can sometimes be employed to refer to a "Workaround" it should NOT be referred to as "Hacking" in this case, especially in print.

 

[theWul]

So what are you trying to tell me, Xien?
"Stupid code fiddling producing mods incompatible with eachother" was to long for the title, so I used "hacking".
And copying and modifying core game files is exactly what I referd to as the "Dark Side" of the tutorial.
"Impractical" from your examples is a bad excuse, better start developing utility libraries for commonly needed tasks.
And if something can't be done by event hooking then better don't do it at all - but imho far more things can be done with events than currently known...

 

[SamBC]

There aren't enough event hooks as it is, and some tasks (adding resources that are map-scattered, for example) can't be done without replacing core files (like AssignStartingPlots.lua). We really need more places to add callbacks. It seems like, rather than a mod-friendly design thinking "when might people want a callback", they went with a design where they noticed where they (the devs) needed callbacks, and added those.

In the example case, I'm working on making a single change that can then support modular adding of resources; this is no small task, and will only be useful if other people use it, but you never know, Firaxis might integrate it (or something similar) later. I'd really like some clear, unambiguous, authoritative documentation on LuaEvents, though, but it doesn't seem to be the same library as uses that name elsewhere...