The easiest way to allow amazing maps!

[NoQ]

If per-map rules.js is run as a separate script, we loose our capability of re-defining things already defined in rules.js (victory conditions, command center functions, etc.)

[Per]

The way things are done for challenges, you can specify if you want your script to replace the existing rules.js (for full control) or run as an extra script alongside it (cleaner, easier to code, easier forward compatibility).

[NoQ]

I didn't know.
Still, the ability to override only a few events and keep the others intact seems a bit more flexible (?)

[Per]

Still, the ability to override only a few events and keep the others intact seems a bit more flexible (?)

Yes, but I don't know a nice, clean way to do that.

[aubergine]

I'm working on a solution to handle that. It includes the ability to add multiple listeners to events by simply defining multiple functions (event listener is replaced by a getter/setter, the setter adds new functions to an array, the getter returns a function that iterates the functions in the array), ability to pre-process and post-process event calls (or any other function call), etc.

Any feedback on what sort of things you'd want to mod most appreciated: viewtopic.php?f=5&t=10030

[NoQ]

Still, the ability to override only a few events and keep the others intact seems a bit more flexible (?)

Yes, but I don't know a nice, clean way to do that.

So what is not nice enough in placing the include statement from the first post at the end of the base rules.js?

[aubergine]

The current rules.js isn't designed to be moddable. You could override it's events, and indeed anything in it, simply by defining new functions, etc., but then you end up with your map needing constant updates to keep up with the evolution of rules.js.

What I'm proposing is a more modular rules.js, where you could update specific aspects of it in a clearly defined manner. For example, providing a new function to work out if a player is alive, or replacing/ammending the starting techs, etc. It wouldn't guarantee that future changes won't break your customisations, but it would certainly reduce the likelihood of adverse affects.

[Per]

So what is not nice enough in placing the include statement from the first post at the end of the base rules.js?

If you define a function that happens to also be defined in base rules.js, you would get a syntax error, I believe. That would seem to defeat the purpose, if I understood it correctly.

As I wrote earlier, the optimal solution from a purely technical standpoint is to be able to override individual functions in file A with similar functions in file B. This would make the list of scripts into a tree, though, which can make understanding how the scripting system works for newcomers (as well as debugging it even for experienced scripters) significantly harder, I would think. But I will keep thinking about it, to see if I can find some elegant solution.

I think the idea of splitting up rules.js into lots of tiny files that can be individually overridden suffers from the same problem, just worse. As rules.js expands, such a solution would become a horrible mess, especially once we try to keep some global state around.

[aubergine]

It wouldn't cause a syntax error (at least not in my tests it hasn't) - it would simply replace the previously defined function with the new one.

The approach I've been taking so far is to have rules.js have an internal set of default functions and data sets, and use those if nothing else defines them first. The cruftiness comes from defining the include statements. It would be nice to have a "rules.mod" folder, in to which any mods could place their mods for rules.js (little scripts that change specific elements) in to that folder and then have an includePath("multiplay/skirmish/rules.mod/*.js") type function to pull them all in.

There would still be issues with one mod conflicting with another, but that's going to happen in any system that allows modding. By having granular, well defined mod points, that are flexible enough to handle most if not all scenarios, it should reduce collisions between different mods.

[Shadow Wolf TJC]

@Per: Perhaps you should have a look at how include() statements have been used in both modding (such as Contingency's usage of it in rules.js) and AI development (such as in NullBot) to get an idea as to how outsourcing parts of the code to included files can make .js files more resilient.

Also, when dealing with events and functions that are built in to Warzone 2100 (such as eventAttacked() or eventDestroyed()), many programmers would have those functions call user-created functions, which can themselves be outsourced into an included file. (NullBot does this nicely.)

[NoQ]

Ok, so for me it now sounds as if the best idea is a separate script (either overriding or complementing rules.js) stored in /multiplay/maps/<mapname>/rules.js; and better not including anything outside this folder.

And also includePath("multiplay/skirmish/rules.mod/*.js") for mods only, because we are looking for a way to avoid map-mods, not promote them (currently a map with a challenge inside is a map-mod; by definition, every map that injects into physfs anything outside its own folder (apart from addon.lev) is a map-mod, right?).

[Per]

It wouldn't cause a syntax error (at least not in my tests it hasn't) - it would simply replace the previously defined function with the new one.

Interesting. Googling around a bit, I see that javascript supports function function overrides this way (see http://stackoverflow.com/questions/2072 ... javascript for more info). I did not expect that. So adding another javascript file to the end of rules.js should allow a modder to decide whether to override events or not.

[aubergine]

Yes, they can easily override the existing functions/events, but what happens when the the rules change with each new release? The map maker would have to keep updating their map, although I guess that comes with the territory...?

[NoQ]

If you trust the base game's rules to not change too much and your map is more or less the base game, just with a little feature (eg. forest continuously growing in a certain area), then you'd like to allow the base game's rules to be changed and no longer need to update your map when they change.

If you want to modify only a few things (eg. force minimap on or change defeat conditions to loosing a certain structure), you override only that.

If your map has nothing to do with a regular game (eg. tower defense), then you'd prefer a full control of game rules, and then the base game's rule changes shouldn't affect your map, so you don't need to update it either.

So, what if the player overrides all events in base rules.js, but then more new events get being used in base rules.js?

[Per]

I have pushed the following changes to master:

If the <map name>.ini file is present (eg for 4c-fishnet, it must be called 4c-fishnet.ini and be in the same directory as 4c-fishnet.gam), then it is parsed for the following information:

[scripts]
extra = path to script to run on every player in addition to rules.js; this is identical to challenge format
rules = path to script to run instead of standard rules.js on every player; this is identical to challenge format

[player_N]
ai = path to script to run as AI on specified player, or 'null' for no AI; this is identical to challenge format
team = default to this team
name = use this name, instead of AI name, if AI
position = default to this start position
difficulty = default to this difficulty ('Easy', 'Medium', 'Hard' or 'Insane')

[locked]
power = prevent user from changing this setting in the GUI (0 for allow, 1 for lock)
alliances = (same as above)
teams = (same as above)
difficulty = (same as above)
ai = (same as above)
scavengers = (same as above)
position = (same as above)
bases = (same as above)

[defaults]
scavengers = default scavenger setting; note that this currently changes the user default due to a design bug (0 or 1)
bases = default bases setting (0, 1, or 2)
alliances = default alliances setting (0, 1, or 2)
power = default power setting (0, 1, or 2)

Some work remains to make sure the game understands that a map with extra scripts is different and modified, even if not renamed, and to look into allowing including extra scripts into same context as rules.js, but it should be possible to start playing with this now and do interesting things, I believe.

Finally, all counting now starts from zero. Challenges with "version = 2" or higher also start counting at zero, while challenges without a version entry will continue to count from 1. I hope to keep challenges made for 3.1 and earlier compatible with 3.2, but not the other way around, since I expect lots of new interesting features that will not be possible to run on 3.1 anyway.