Feature Request

[Wet_Flannel]

I think that engineers /dgs should be able to construst incubators radars for added laffs..... id spamm all type of incubator !

[trickfred]

Being able to set speed/hp/rate of fire for a set of units in the mission file rather than in stats.txt would be cool - you could increase/decrease unit speeds dynamically during the game - say, have enemies speed up or take more damage in later levels of a mod. Still use stats.txt, but have any stat changes listed in the mission file supercede it for a specific group.

Edit: Being able to call sound files other than the music files in scriptsa would be AWESOME, since we can only have one music file playing at once. For example, we were throwing around the idea of recording voice .oggs for Dr. S as a mod - but then we couldn't have music in the levels. If we could call the voice .oggs separately from the music, we wouldn't have to sacrifice the music to make it work.

Edit: being able to change team colours would be cool too - like specifying red for team 0 darwinians, so you could play the 'bad guys' - or an entirely new colour. Better yet, some kind of rgb 0-255 system.

(removed silly highlights idea)

[trickfred]

Bumpity-bump.

Another idea discussed on irc: Add the ability to switch avatars in game, as opposed to having one avatar (ie. Sepulveda) for the entire mod.

For example:

SwitchAvatar reddg
Say line1
Say line2
SwitchAvatar sepulveda
Say line3
Say line4

sepulveda would be the default avatar, so adding this command would not break the game or current mods.

Edit: To expand on the above, you'd either just add a directory in the mod folder and the command would call the name of that directory (reddg in the example above) containing files named reddg1.bmp, reddg2.bmp, etc..., or just name the new avatar files reddg1.bmp, etc... and toss them in the sepulveda dir with sepulveda1.bmp, etc...

Please also note the suggestions I edited into the above post.

[panda of doom]

I echo all four of the suggestions above. Would make the game so much more moddable.

[trickfred]

The ability to manually add secondary objectives other than 'open trunk port' would be helpful in creating more dynamic levels.

Edit: I'm sure this has been mentioned elsewhere, but I'll add it again here: SafeAreas should revert to offline when their required numbers drop.

ie. - A SafeArea requiring 10 DGs to become online should revert to offline if one DG wanders out of the area, leaving only nine within the confines of the SafeArea. Would help greatly in creating more intricate level puzzles.

[Icepick]

You CAN add secondary objectives.

Just create a section called SecondaryObjectives under the primary in your mission file.

[xander]

You CAN add secondary objectives.

Just create a section called SecondaryObjectives under the primary in your mission file.

I have tried that and find that Darwinia generally crashes. Is there some special sytax that I am missing? Or is it supposed to work just like primary objectives?

Specifically, it was formatted as such:

Code: Select all

SecondaryObjectives_StartDefinition
     BuildingOnline:SomeMap,0     SomeString     SomeScript.txt
SecondaryObjectives_EndDefinition

xander

[martin]

Easier scripting.

[Icepick]

You CAN add secondary objectives.

Just create a section called SecondaryObjectives under the primary in your mission file.

I have tried that and find that Darwinia generally crashes. Is there some special sytax that I am missing? Or is it supposed to work just like primary objectives?

Specifically, it was formatted as such:

Code: Select all

SecondaryObjectives_StartDefinition
     BuildingOnline:SomeMap,0     SomeString     SomeScript.txt
SecondaryObjectives_EndDefinition

xander

Im pretty sure that should work, though to be honest, I dont remember the last time I tried it. It may well have been during the beta and since been removed.

[Klepto]

Edit: I'm sure this has been mentioned elsewhere, but I'll add it again here: SafeAreas should revert to offline when their required numbers drop.

That would break my mod I think. One of the primary objectives is to move a squad through a safe area, if that goes offline before the end of the level then it's gonna break my events. As an option it would be great but as a change it would cause problems I think.

[The GoldFish]

Although the ideas (which many of us still want) haven't been included in any patches to date, afaik - I'm pretty sure that if objectives latch, the issue would be moot, they may do already, I'm not sure - regardless I'd prefer to see new variables for all buildings with iscurrentlyonline and hasbeenonline (or similar), which both respond to mission resets.

The major reason for this request is because without it, you can't have truly simultaneous or sequential objectives without map changing skuldugery, which come in handy for more complicated levels with different playstyles.

[Klepto]

I'm kinda new here, so there may be a better way to do what I'm doing. The missions are latched AFAIK but I have events like this...

Code: Select all

Event NotInLocation BuildingOnline :rs232,6 BuildingOnline :rs232,8
 Action SetMission rs232 mission_rs232_complete.txt
 Action RunScript rs232_next.txt
End

...to swap in a different mission file when the objectives are complete. If safe areas always went offline once the units left then it would never fire.

[trickfred]

Solution: Have SafeAreas go offline/online depending on units within, but once all objectives in a level are complete, then they all remain permanently active. That way you can have more variance within a level, and it won't break functionality after completing the level.

[xander]

A question: when an objective is completed, should it stay completed? If a SafeArea goes offline, and it was linked to a mission objective, should that objective remain completed, or become incomplete again?

There are three scenarios that I see:
I) SafeAreas cannot go offline. In this scenario, once brought online, a SafeArea remains online. Any scripts or objectives that rely on the status of the script will fire, no questions asked. This is the current state of affairs.

II) Safe Areas can go offline, and when the go offline any linked objectives go from complete to incomplete. I think this is a bad idea. Let us say that you have a script that runs when a particular SafeArea becomes active. It says something to the effect of "Yay you, you finished the objective." Then, some DGs run away. The objective is no longer complete. This could be rather confusing, and does not seem like an intuitive way for a game to behave.

III) SafeAreas can go offline, but mission objectives remain complete. For instance -- you must bring 50 DGs to a SafeArea, then move them to another SafeArea. The first SafeArea goes offline, but mission objective that instructs you to bring the DGs to that spot stays completed. In this scenario, I think that you would need to add a new kind of scripting call, and change the way that objectives are declared:

Code: Select all

PrimaryObjectives_StartDefinition
  0  BuildingOnline:foo,0  SomeString0  SomeScript0.txt
  1  BuildingOnine:foo,1  SomeString1 SomeScript1.txt
PrimaryObjectives_EndDefinition

Code: Select all

Event ObjectiveComplete:foo,0
  Action RunScript SomeScriptA.txt
  End

Event ObjectiveIncomplete:foo,1
  Action RunScript SomeScriptB.txt
  End

i.e. each objective has an ID, and the status of the objective can be used as a script condition. The problem with this is that it would break any existing mods, unless some kind of compatability mode were enabled (i.e. a line in game.txt that declares that the campaign is 1.2.1 compatable, or whatever). While I don't really have any problems with the way in which things are handled now (it is not perfect, but it seems to work), I think that this would be the best possible solution.

xander

[Klepto]

Yup, that would fix it. Personally I'd prefer a new boolean field for safearea, "sticky" or "latched" or something so we can have the best of both worlds. I can still think of a couple of (somewhat convoluted) instances where having latched safeareas would be useful.