The easiest way to allow amazing maps!

[NoQ]

Put this into rules.js:

Code: Select all

include("multiplay/maps/"+maxPlayers+"c-"+mapName.slice(0, -3)+"/rules.js");

This will allow making scripted maps without involving map-mods (and including them into the game too!). Works on 3.1.

Unfortunately, throws a LOG_ERROR message if the map doesn't provide any script.

[aubergine]

Neat trick

What if the player just wants the map without additional scripting?

[NoQ]

Then he does the same thing he does now: plays some other map (:
We could make it adjustable, but it wouldn't be "the easiest" (:

[Per]

The challenge mode already has .ini files that allow you to add scripts to a map. I am going to look into reusing this functionality for non-challenge maps. Ideally, non-challenge maps should be able to set all the same things that challenge maps do. I may have to modify the challenge .ini file format a bit to generalize this.

[aubergine]

If you alter the challenge ini file, could you change it so that things are zero-indexed like in the rest of WZ? It's über-confusing having 1-referenced values in challenge inis. Same applies to team numbers in <mapname>.ini.

[NoQ]

Some maps with challenges do exist already, probably not a good idea to break compatibility; i'd easily fix mine (whenever they are suitable for 3.2+), but there may be some we don't know about.

Also, i'm a bit scared to allow arbitrary file names for scripts. Maps may start to conflict if somebody includes an edited version of the script into his map and doesn't rename it. Even with challenges: we don't have a good naming convention for challenge files anywhere. I believe everything must be forced to stay inside the map's physfs folder.

Maybe deprecate the /challenges/ folder completely and merge its functionality into the map .ini?

[aubergine]

Currently it's possible to create a challenge for any existing map, and that functionality is useful IMHO. If we force challenges and maps to be bundled together, it will be harder for people who don't make maps to create challenges. There should be some ability for a non-mapmaker to create a challenge (or mini campaign) and a non-scripter to make maps.

[Duha]

Put this into rules.js:

Code: Select all

include("multiplay/maps/"+maxPlayers+"c-"+mapName.slice(0, -3)+"/rules.js");

This will allow making scripted maps without involving map-mods (and including them into the game too!). Works on 3.1.

Some questions:

To change rules.js you need create new mod ?

Can you add some event handler in map js with out overriding rules.js. handlers?

[aubergine]

If I understand correctly, when a map is selected that adds it's folders to the search paths in the physfs system, couldn't you just override multiplay/skirmish/rules.js by having that path and file in the map?

[Iluvalar]

Currently it's possible to create a challenge for any existing map, and that functionality is useful IMHO. If we force challenges and maps to be bundled together, it will be harder for people who don't make maps to create challenges. There should be some ability for a non-mapmaker to create a challenge (or mini campaign) and a non-scripter to make maps.

It's easy to target an existing map in the .addon file

[aubergine]

.addon file? What are those?

[NoQ]

To change rules.js you need create new mod ?

I proposed to modify the base game's rules.js. There's not much sense in having this as a mod.

Can you add some event handler in map js with out overriding rules.js. handlers?

I that think if you mention an event twice, just both functions are called.

.addon file? What are those?

addon.lev etc., i think, some really weird logic we're trying to get away from by introducing map.ini (?)

[aubergine]

If you create two event listeners of same name, the second overwrites the first, unless you do some clever stuff with getter/setter properties.

[NoQ]

Uhm, yeah, right, never mind. So we're lacking eventGameInit (we still have eventStartLevel), eventAttacked, eventStructureBuilt and eventDestroyed

[Duha]

If you create two event listeners of same name, the second overwrites the first, unless you do some clever stuff with getter/setter properties.

I prefer bind unbind functions style