The easiest way to allow amazing maps!

[Iluvalar]

Per, now all we need is a way to target files in another ".wz" pack. And the game to be intelligent enough to transfer any pack needed amongst the player (no assuming there is only one).

[aubergine]

The updated <mapname>.ini looks awesome! Lots of flexibility in there already and looking forward to see what is added in future too.

Would it be possible to alter some of the property names in the <mapname>.ini for consistency with names of JS API features, before these things start to get set in stone?

[map] section:
If one of those properties gets translated in to the 'mapName' JS API global, could the property be called mapName so it's obvious which value the JS API sees?

[defaults] and [locked] sections:
alliances --> allianesType
bases --> baseType
power --> powerType

For alliances and bases, would it be possible to change the values in [defaults] to string constants? Eg. instead of bases = 1, it would be baseType = CAMP_BASE -- I feel this would help any map makers who want to start scripting feel more at home in the JS API environment, they'd know what the global property is called and what values it has as they'd be the same between the .ini and .js files. While most map makers probably won't write AIs, I imagine many would want to modify the 'rules' script or add the 'extra' script to do some minor adjustments, be it changing the weather or altering victory conditions, etc.

In the [player_N] sections, would it be possible to allow AIs to be specified by their .ai file rather than .js file? I know from previous discussions regarding <challenge>.ini files that there are some technical hurdles to overcome, but if possible it would be nice to have the new <mapname>.ini refer to .ai files from the outset. For example, I know the AI name can be overriden in the [player_N] section, but as an optional property (I assume?) it would be good to have it default to the name specified in the .ai file rather than hard-coded "Nexus". Also, if .ai files evolve in future to contain additional settings for an AI, the groundwork would already be done to use those as defaults to avoid needing to update lots of <mapname>.ini files.

Some other questions I had about <mapname>.ini:

* In the [map] section, are all properties mandatory or are some optional? If optional, what defaults are used?
* Are [player_N] sections mandatory?
* If [player_N].ai file is specified but not found, what happens? Does it default to Nexus AI script or no AI?
* If [player_N].difficulty is specified but no AI defined, does it force "Medium" difficulty for human player in that slot? (in WZ 3.1 humans are always MEDIUM difficulty according to JS API)
* Does [player_N].team default to N if not specified?
* Does [player_N].name get overriden by human player name if a human is in that slot?
* Does [scripts].extra get run against all human players, or just the human game host (player 0)?

What happens to a map if it doesn't contain a <mapname>.ini file?

What happens when the map is changed in game set-up screen if the new map has or does not have the <mapname>.ini file? For example, map A contains scav bases and it's ini enables scavs and locks the setting, then user changes to map B that doesn't have any scav bases, doesn't disable scavs but locks the scav setting -- does the scav setting stay enabled but locked?

Regarding challenges, instead of having a v2 for <challenge>.ini, why not use same format as <mapname>.ini (but with file placed in challenges/ folder) and differentiate between a v1 challenge by the sections in the ini file (a [map] section = v2)? A v2 challenge ini would possibly warrant a 'difficulty' property in the [map] section (does that really get used/noticed by end-users though?).

[Per]

Some of those questions need to be tested to see what happens. Help testing the new features would be appreciated.

<map>.ini are not mandatory, obviously, since most maps do not have them. No fields are mandatory, yet. File not found errors are usually terminal. Difficulty makes no sense for human players. Teams are by default incremental. These scripts are run on each player, but always owned by player zero. The need for challenge version field comes from the change to counting (starting at one or zero), not differences to fields and sections as such.

I will think about the suggestions.

[aubergine]

I need to upgrade my mac (recent change by dak180 dropped support for OS X 10.5.x) before I can do more 3.2 testing Something I've been putting off for a while but plan to do this month.

On challenge games, I assume the 'extra' script runs on each human player there as well? As for rules, I thought they only ran on human players (so one rules.js per physical computer connected to the game)?

P.S. Thanks for the updated info I'm updating my docs: https://warzone.atlassian.net/wiki/disp ... ame%3E.ini

[NoQ]

It says things like

Code: Select all

error   |12:19:57: [WzConfigHack:41] multiplay/maps/2c-Vision.ini could not be created: No such file or directory

for maps that don't have any .ini (both built-in and external)

[Per]

@aubergine: Yes, 'extra' and 'rules' run only once for each network peer, not once for each player. My bad for being inaccurate. Also note that the 'ai' script in the player section will only run on the host, as usual.

@NoQ: Oops.

[Iluvalar]

Oh, and don't assume the name of the level is the same as the name of the map containing pak please.

For exemple : I might make a level pack that is called 4c-rushKOH.wz . That would run the script/mod (don't see any distincton here...) kingotthehill.wz and nooildrum.wz in the map contained in 4c-rush.wz

The client would then communicate with each others until the 4 files are on both end :
*Do you have XXX.wz ? Yes; No. There it is.