Modding vs. Hacking or the Dark Side of Kaels Tutorial

[xienwolf]

They made it mod friendly, they didn't do your thinking for you.

Adding a callback is SIMPLE. Kael's Tutorial shows you exactly how to do that for one case, figuring out more general cases is relatively simple.

If you want a callback added because your mod needs it, and you want to remain compatible with other mods, it is bloody simple: Release 2 mods.

Mod 1: Adds a LUA file with same name as a base file (thus overwriting it in a soft sense). This mod does NOTHING except add your callback.

Mod 2: This is the mod you actually wanted to make, and it uses the Callback from Mod 1.


Now you set Mod 2 to have a dependency on Mod 1, thus forcing it to be active for your mod to be activated.

BOOM! Your mod is compatible with other mods. If someone else needs a different callback added to that same file, then they ask you to add their callback to MOD1, or just release another mod which lists your mod 1 as a blocked mod. This prevents anyone from accidentally trying to use both at once.



So the fault isn't in the designers, and you cannot expect any manual to spell out every detail for you, so the fault isn't really with Kael either. IMO there is no fault, you just didn't see what seems obvious to others.

 

[Afforess]

They made it mod friendly, they didn't do your thinking for you.

Adding a callback is SIMPLE. Kael's Tutorial shows you exactly how to do that for one case, figuring out more general cases is relatively simple.

If you want a callback added because your mod needs it, and you want to remain compatible with other mods, it is bloody simple: Release 2 mods.

Mod 1: Adds a LUA file with same name as a base file (thus overwriting it in a soft sense). This mod does NOTHING except add your callback.

Mod 2: This is the mod you actually wanted to make, and it uses the Callback from Mod 1.


Now you set Mod 2 to have a dependency on Mod 1, thus forcing it to be active for your mod to be activated.

BOOM! Your mod is compatible with other mods. If someone else needs a different callback added to that same file, then they ask you to add their callback to MOD1, or just release another mod which lists your mod 1 as a blocked mod. This prevents anyone from accidentally trying to use both at once.



So the fault isn't in the designers, and you cannot expect any manual to spell out every detail for you, so the fault isn't really with Kael either. IMO there is no fault, you just didn't see what seems obvious to others.

Easy as pie, Xienwolf. Except that dependancies and mod associations don't work.

 

[The_J]

They are broken, you mean?
I'm not supprised, *sigh*.

 

[SamBC]

Easy as pie, Xienwolf. Except that dependancies and mod associations don't work.

Also, this only lets you add callbacks where it's already handled by Lua. If it's something that's in the compiled code, there's nothing you can do, and the only Lua bits are ones they decided to do in Lua for whatever reason (presumably to make it moddable).

I am however, using the described strategy for making resource modding more modular.

 

[SamBC]

They are broken, you mean?
I'm not supprised, *sigh*.

Not broken - just specified and covered by ModBuddy, but not actually implemented at all, and thus greyed out even in ModBuddy.

 

[Shiggs713]

well you could call it broken still. Not working as advertised at the least.

 

[xienwolf]

Also, this only lets you add callbacks where it's already handled by Lua. If it's something that's in the compiled code, there's nothing you can do, and the only Lua bits are ones they decided to do in Lua for whatever reason (presumably to make it moddable).

I am however, using the described strategy for making resource modding more modular.

While one could code callbacks on absolutely every step of the game ever, it would cause the game to run VERY slow (as you would have to provide callbacks for each 25ms screen refresh as well). Even when they aren't being used. Callbacks come with a price, and so putting in calls you don't use is a useless hit to performance.

We WILL have the DLL eventually, when that time comes we can add in numerous other callbacks. Still can't do EVERYTHING obviously (I want a callback at the instant my warrior's animation bends his left knee 35 degrees...), but you can do a lot more than what is in LUA so far.

We all want the sourcecode for the DLL, but there are reasons why is has to be delayed (cleaning up the code, running things through legal, removing/adding comments, removing debugging catches...)

 

[Afforess]

While one could code callbacks on absolutely every step of the game ever, it would cause the game to run VERY slow (as you would have to provide callbacks for each 25ms screen refresh as well). Even when they aren't being used. Callbacks come with a price, and so putting in calls you don't use is a useless hit to performance.

You can have it both ways though. Remember PythonCallbackDefines.xml in Civ4? Just allow modders to turn them off and on. The check to see if the callback is off or on takes virtually no time, so you could have a lot more callbacks than Civ5 has.

Xienwolf, you're making excuses for Civ5... it's not a good sign.

 

[SamBC]

While one could code callbacks on absolutely every step of the game ever, it would cause the game to run VERY slow (as you would have to provide callbacks for each 25ms screen refresh as well). Even when they aren't being used. Callbacks come with a price, and so putting in calls you don't use is a useless hit to performance.

We WILL have the DLL eventually, when that time comes we can add in numerous other callbacks. Still can't do EVERYTHING obviously (I want a callback at the instant my warrior's animation bends his left knee 35 degrees...), but you can do a lot more than what is in LUA so far.

We all want the sourcecode for the DLL, but there are reasons why is has to be delayed (cleaning up the code, running things through legal, removing/adding comments, removing debugging catches...)

Holy Straw Man, Batman! No, seriously, I'm arguing for more callbacks, not every conceivable callback. Each time a building is gained, and lost, that's a pretty reasonable one. A reasonable software engineering process could examine the requirements represented by suggested callbacks, find ways of meeting them with a minimal set or (harder to implement but easier to use and faster) addition of hardcoded behaviour with reference to DB tables. They could easily have looked at popular Civ4 mods and realised what behaviour people were going to try and add to mods immediately.

I'm not actually a 2K-basher, mostly, but there are some shocking oversights in the mod interface. There does, however, seem to be a will at Firaxis and 2K to improve this short of the source code release, with iterative updates to the mod tools, and possibly even to the game's modding interface. Of course, that has the potential problem of breaking mods, and people have a harder time choosing when to update now that it's Steamworks, but we can hope it will happen, and happen smoothly.

Your defence of the game is commendable, particularly if it were in the face of one of the ridiculous attacks on the game that is common, particularly on the 2K forums (which I'm taking a break from, aside from the modding one); it was, instead, directed at a reasonable technical critique.

To make my critique even more reasonable and technical - I've realised that the callbacks, particularly those I've heard of being used, are largely oriented to the UI. Behavioural modification via Lua doesn't seem to have been any sort of priority in design, although there is some allowance. The start of turn hooks only apply to human players, for instance.

 

[xienwolf]

Not excuses for Civ5, just my usual approach of "You can code it yourself pretty easily." But since C5 just came out, people expect it all to be done for them. (Granted, that is the only option at this point, due to a lack of DLL code...)

And Sam: How does the coder decide WHICH "more" callbacks to add is what I am saying. It is bloody hard to predict what other people will use, and what will be a waste of time. You could base it on C4 mods, but with the changes in C5 you could just as easily base it on Alpha Centauri mods.


My arguments aren't at all from the stance of "Defend 2K" they are instead from the stance of "Would I have done any better writing the code?" And overlooking a pretty obvious and simple hook like "at the start of each turn for AI players too" is exactly the kind of thing I would naturally miss.

 

[SamBC]

And Sam: How does the coder decide WHICH "more" callbacks to add is what I am saying. It is bloody hard to predict what other people will use, and what will be a waste of time. You could base it on C4 mods, but with the changes in C5 you could just as easily base it on Alpha Centauri mods.

Well, it's something I'd expect to spend design time on, with multiple people, looking at hypotheticals and so on. It needn't even be that many man-hours. Maybe 3 man-weeks, which I would've thought would be a small proportion of total time.

My arguments aren't at all from the stance of "Defend 2K" they are instead from the stance of "Would I have done any better writing the code?" And overlooking a pretty obvious and simple hook like "at the start of each turn for AI players too" is exactly the kind of thing I would naturally miss.

I'd've thought it would be a hard thing to miss if you were sitting down thinking about callbacks that would be needed if you were modding the game's behaviour, rather than focussing on the UI. It's a very natural thing to miss when focussing on allowing mods to the UI.

Several shortcomings in potential behaviours that prevent certain building properties, say, would be easy to add behaviour for with the right hooks. I'd've thought that unit gained/lost, building gained/lost, and suchlike doesn't lead to a huge long list or a huge processing burden, but opens up a huge range of potential behaviour changes when combined with functions to do things like add/remove resources from the civ's supply, give/remove money, culture, reputation, and so on.

You can fairly easily mod a technology-based change of city bombard range using the Lua, but it will only affect humans. The reason it will only affect humans is because it's in code that checks whether a city is able to bombard a given hex, and this check is performed in the user interface, and thus ignored by the AI. To my mind, this is a weird way to do it, and certainly doesn't represent a sound MVC separation. If the MVC separation is sufficient, the AI will always have the same checks imposed on it as human players, and it would be doable. As it is, code that checks whether a tile can be bombarded is bound the UI (the V part of MVC), and the AI works through a non-moddable more trivial check.

 

[xienwolf]

MVC? Not familiar with that term.

With how often AI would make checks about bombarding a tile (well, how often it MIGHT), you don't want to be jumping between C++ and LUA on each call to get permission IMO. So leaving the AI authorization there does make sense to me. The confusing thing in my opinion would be having the Human check via LUA instead of the same C++ routine which the AI uses, rather than the other way around. You are certain that the actual bombard capable range changes, and not just the visual representation of where you can select? Does it also adjust the range at which you get the auto-notification that bombard is an option, and the target popup?

 

[SamBC]

MVC? Not familiar with that term.

With how often AI would make checks about bombarding a tile (well, how often it MIGHT), you don't want to be jumping between C++ and LUA on each call to get permission IMO. So leaving the AI authorization there does make sense to me. The confusing thing in my opinion would be having the Human check via LUA instead of the same C++ routine which the AI uses, rather than the other way around. You are certain that the actual bombard capable range changes, and not just the visual representation of where you can select? Does it also adjust the range at which you get the auto-notification that bombard is an option, and the target popup?

MVC is model-view-controller, a common paradigm is computer science particularly attached to the design of systems with GUIs (not just the design of the GUI, but of systems with GUIs), but applicable to many other systems as long as there is a 'view' of some sort.

I've not done the modding to modify city range mid-game, but taking the word of the chap who did, yes, it does adjust the range. It doesn't change the underlying bombard capable range, but that seems to be because there isn't really an underlying bombard capable range - if the UI doesn't let you, you can't, and if the UI won't let you, it won't notify either. The computer, however, just checks the maximum in the basic game defines, and there's no way to modify that as the game goes on, because it is prone to reupdate from the XML mid-game. You can modify it at the start of each turn, but then it only ends up applying to humans reliably. The guy who was trying to make city bombard range tech-dependent made notes about this on the 2K forums.

 

[Afforess]

You can fairly easily mod a technology-based change of city bombard range using the Lua, but it will only affect humans. The reason it will only affect humans is because it's in code that checks whether a city is able to bombard a given hex, and this check is performed in the user interface, and thus ignored by the AI. To my mind, this is a weird way to do it, and certainly doesn't represent a sound MVC separation. If the MVC separation is sufficient, the AI will always have the same checks imposed on it as human players, and it would be doable. As it is, code that checks whether a tile can be bombarded is bound the UI (the V part of MVC), and the AI works through a non-moddable more trivial check.

I assume you are referencing Bombardment.lua. You can't adjust the range or other factors, IIRC. It's just the code that draws the interface for the human.

 

[xienwolf]

So you could REDUCE the range for a human, but not the AI. But you cannot INCREASE for either of them it would seem from the descriptions given. That one does make perfect sense to be possible as you aren't actually changing what the human is allowed to do, just changing what he is allowed to input. It's kind of equivalent (gross exaggeration aside) to taking away the right mouse button and expecting rule changes to propagate from that. All commands accessible through right clicks are still valid, just inaccessible now to a human (who doesn't have a second mouse).