How to add new campaigns to 3.2

[aubergine]

Reiterating: The ini isn't defining what level comes next. That's done in the script.

The ini is just stating what levels there are -- the [mission_N] sections -- and if those missions rely on completion of other missions/campaigns before they become unlocked.

As an example of the unlocking thing, I might want two campaigns to be interwoven. So that part way through camB you get reports of one of your locations in camA getting attacked, and go back to that place complete with the base as you left it and the droids, etc., in camA. While doing camA you wouldn't even know the extra mission existed - basically it would be a mission for future use. Similar things would relate to my ideas for a "Training campaign" -- as you progress through a main campaign, new training missions become available in the Training cam should you require some extra tutoring on new weapons/buildings/skills etc.

[Emdek]

Reiterating: The ini isn't defining what level comes next. That's done in the script.

OK, then we agree at some basic stuff.
But I'm still against optionalproperty, since it is not useful to scripts at all, but more for users that dig into campaign definition.

[aubergine]

The game engine is keeping track of which missions are won or lost, hence why I would prefer the 'optional' property in the ini rather than a script. By the time a script is running, the mission is already started.

[Emdek]

aubergine, wouldn't be enough if such mission simply wouldn't be listed as required by any other mission?
Also, for what are used separate INI files for each mission? What would those contain, map definitions or what?

[aubergine]

The last mission in a campaign isn't required by any other mission (otherwise it wouldn't be the last mission in campaign ).

Note that the optional property defaults to 0 (false), and thus won't be required for the vast majority of missions in a campaign. It's only there for specific missions that need it.

[dak180]

Emdek that would only work if they did not have other missions that resulted from them, such as a set of two side missions.

[Emdek]

aubergine, I still don't like that approach (too verbose).
What about replacing it be (un)locked property set by scripts? That would be one clear solution to directly tell game that given mission (or missions, in complex case, like story branching or showing the same event from different perspectives) should be unlocked from now (maybe also allowing to lock unused branch after going further into originally selected one or failing to achieve required objective).

[aubergine]

@Emdek: Yes, it could use an unlocked property set by scripts. However, I really wanted the <campaign>.ini to double up as an at-a-glance overview for anyone wishing to mod or document it. Being able to get an idea of the mission flow just by looking at the main ini file for the campaign solve that requirement better than hunting through scripts for an unlockLevel() function and then trying to work out whether it actually gets called or not (eg. it might be a random leftover from an earlier version of the script).

-------

Putting the "optional in .ini" vs. "unlock in .js" debate to one side for a moment, what are people's feelings regarding the overall nature of the .ini a and the ideas about ditching things like messages/ folder in favour of centralising stuff in to the likes of audio.ini, sequences.ini, research.ini, etc?

I realise the change would be a lot of work, but it would allow hundreds of files to be replaced by just a few, and with the new centralised data about audio/sequences/etc make it easier for stats editors (fewer file specifications to handle)...

[Emdek]

aubergine, I can't agree that quick glance will be always enough to comprehend layout of whole campaign, surely it is possible with current ones, linear. For more complex it would require (at least for many users) some kind of graphical diagram.

About second suggestion, it is always better to keep minimum level of complexity, and having single kind of data type (plus JS scripts where required) is for sure simpler solution (also we don't need additional parsers).
So I agree, but there is still issue of how it will be implemented in detail.

[aubergine]

I certainly agree that reducing complexity is good idea, when I looked at existing campaign structure there were gazillions of files in different formats and different places that I still have no idea how they all fit together or what they all do despite wading through them for past several months. (If only I could get my brain to understand C++ I'd be able to work things out a bit faster).

But I think it was Einstein who said: "Simplify, but don't over simplify". IMHO .ini and .js go hand in hand, with .js being mainly for dynamic stuff and .ini for static stuff. JS is fairly easy to read, .ini is very easy to read. etc. They have slightly different pros and cons, but they compliment each other very well IMHO.

[Emdek]

IMHO .ini and .js go hand in hand, with .js being mainly for dynamic stuff and .ini for static stuff. JS is fairly easy to read, .ini is very easy to read. etc. They have slightly different pros and cons, but they compliment each other very well IMHO.

I agree.