Warzone 2100: Contingency (Beta now released)

[Shadow Wolf TJC]

Talk to NoQ about that. He's the one that developed NullBot 2.0 (although I'm considering replacing it with NullBotSW in future bundles once it's finished.)

Anyways, I had enough free time on my hands to work on and release Contingency version 0.7.7, which mostly tweaks the Scavenger AI. Players should find that it has a few new toys to play with, though should also find it more merciful (as it'll now give players 5 minutes to prepare for the 1st assault, and 15 minutes to prepare for its VTOL assaults).

[mobius1qwe]

Shadow Wolf, I got a little question:

Why Proto Railgun upgrades are so cheap and quick? The last research before it have around 2.5m and cost more than 300 power to research. But then the Railgun upgrades in damage, rate of fire and accuracy are way too fast and cheaper.

Is that thing correct or it was something u didn't saw comming?

[Shadow Wolf TJC]

That was intentional, since I expected players that specialized in cannons to later switch over to railguns, so I figured that they shouldn't be penalized for researching both cannon and railgun upgrades.

[Goth Zagog-Thou]

Tomorrow I plan to get started with the conversion (MANUAL conversion ... ) over to the .ini format. csv2ini will NOT work for me since I have no idea how to run it.

(Why in the name of all that's holy would someone write a script in php of all things ... argh. At least do it in Python or something that the average human being could *actually* use.)

Any new stuff to Contingency since 0.7.4? Wouldn't want to omit something that I'd just have to put in later on.

[Shadow Wolf TJC]

Not much. Just the addition of a few Scavenger units (though only the Scavenger RPG's body and weapon are new), and the changing of some .pie models. I'm planning on making a few more changes to some .pie models later on, though if you plan on converting the various .txt files from version 0.7.4 of Contingency to .ini format, then I could just make some quick changes here and there.

[Goth Zagog-Thou]

Take your time .. if you've got some things cooking I don't mind waiting.

[Shadow Wolf TJC]

What I meant to say is that I don't mind if you go ahead with converting to .ini right away. I could always update the .ini files later on.

[Goth Zagog-Thou]

Very good. What I'll do is start with the current Contingency (0.7.7 I think) and submit the conversion over to you for tweaking. Yes?

[Goth Zagog-Thou]

It also occurs to me that there's an opportunity (since I'll be waist-deep into the guts of the stat files) to apply a little change I've been working on.

I'm sure you're aware that I've been working on Research Paths that are more or less isolated from different weapon types. This does NOT affect the "crossover weapons" such as Incendiary Machineguns and so forth, since those weapons exist because of the player researching the needed weapon types. This one goes further in scope than that.

My idea is to allow for the Classic Research to exist in parallel with Contingency. We enableResearch() the "trigger topics" at map / mission start, the player selects which path they want to use (Classic or Contingency). To the player, they would see what they should see (Machinegun, etc) and follow the research normally.

To the code, however, these Machineguns are different topics entirely.

For Classic Research, it's R-Classic-Wpn-MG1Mk1

For Contingency's version, it' R-Cont-Wpn-MG1Mk1

See the prefix? That's where the difference lies. I had a similar idea with the tilesets about a year ago.

Shall I implement this, or leave it be for now and simply do the conversion to .ini ?

[Shadow Wolf TJC]

It also occurs to me that there's an opportunity (since I'll be waist-deep into the guts of the stat files) to apply a little change I've been working on.

I'm sure you're aware that I've been working on Research Paths that are more or less isolated from different weapon types. This does NOT affect the "crossover weapons" such as Incendiary Machineguns and so forth, since those weapons exist because of the player researching the needed weapon types. This one goes further in scope than that.

My idea is to allow for the Classic Research to exist in parallel with Contingency. We enableResearch() the "trigger topics" at map / mission start, the player selects which path they want to use (Classic or Contingency). To the player, they would see what they should see (Machinegun, etc) and follow the research normally.

To the code, however, these Machineguns are different topics entirely.

For Classic Research, it's R-Classic-Wpn-MG1Mk1

For Contingency's version, it' R-Cont-Wpn-MG1Mk1

See the prefix? That's where the difference lies. I had a similar idea with the tilesets about a year ago.

Shall I implement this, or leave it be for now and simply do the conversion to .ini ?

You could implement it for your singleplayer campaign if you'd like, but I personally don't want any features, structures, or components renamed, since I'm trying to make Contingency backwards-compatable with current Warzone 2100 maps.

[Shadow Wolf TJC]

Version 0.7.8 is out, with some new updates to the sitrep code that you might find interesting. (Also, you might notice a visible laser pointer on some turret models.)

I'm thinking about performing an overhaul in how rules.js is structured to make it more modular in design, by using many .inc files for different parts of the code. I personally hope that we'll be getting a new standard in which rules.js in future official Warzone 2100 builds would be made as modular as what I'm planning.

[aubergine]

I've already got a part baked modular rules.js that I didn't get round to finishing, would be interested to hear what your plans are.

I separated out just about every component - such as all the various bits of player initialisation (eg. techs/components/base type/etc) and game rules (eg. is player alive, win conditions, etc).

[aubergine]

Recycled units are giving sitrep "unit destroyed" -- prolly need to check their .order to see if it's DORDER_RECYCLE etc. to choose correct sitrep.

[Shadow Wolf TJC]

Same thing happens when demolishing structures. However, if the enemy manages to destroy them before they're recycled or demolished, then I fear that the scripting would think that the unit or structure was recycled or demolished, when it was, in fact, destroyed by enemy fire.

[aubergine]

IIRC I found a way to resolve that issue but I can't remember off the top of my head what it was - if you look in most recent ver of Enhanced SitRep mod, it's in there triggered by eventDestroyed(). Also, for 3.2 compatibility remember that eventDestroyed() will be getting called for everything that gets destroyed including enemy units.