stuff to unhardcode

[felipe]

Vexed's note: viewtopic.php?f=30&t=10090&p=114158#p114158

Hi guy's.

after more tough about this viewtopic.php?f=5&t=10028 and NoQ suggestion, I decided to to open a new topic, more in general.

To be clear from the beginning, we are not talking about changes in the default balance of the game, only to let mods be able to change some of that harcoded values, for skirmish and multipleyer games.

What comes to my mind is:
- Commanders starting number of droids (already posted a patch that use brain.txt).
- Multiplier for the number of droids (idem above).
- Maximum number of commanders (actually 10).
- MAX_CONSTRUCTOR_DROIDS 15
- MAX_MP_DROIDS 150
- enable rain/snow/fog and some value for the tunings
And last, but not last, a multiplier for the number of kills needed to change rank.

I leaved this at the end because, IMO, would be cool to be able to change that value at the startup of skirmish/multiplayer games.
Or, put this value in a txt file AND add an option on startup that override the txt value?

Something wrong ? Better ideas ? More ideas ?

Some examples of the possible benefits of this changes would be:
Being able to make 2/3/4 or, why not, more player maps without the limit of 150 droids x player(!!!).
Mods that give commanders more/less units.
Give ranks some sense in skirmish/multipleyer matches.
Turtlers can have a mod that permit more than 15 build droids.
and so on...

The changes needed in the c++ are "quite" simple (I think).
If we reach any sort of agreement (I hope) I can do the work, or part of it.

Let's talk.

[aubergine]

IMHO things like droid limits should be handled by rules.js as structure limits are defined there already - I've been working on a revised rules.js that will be much easier to mod due to it being split in to it's component parts (numerous small js files, each dealing with a certain aspect of game set-up and rules).

I'd like to see tech level also move in to the territory of rules.js. Currently it's in a bunch of txt files (camtech*.vlo IIRC) so it's moddable (I think?) but IMHO it would be better as part of rules.js.

In fact, anything to do with game set-up and rules would be well placed in rules.js. The benefit of having it in JS is that settings can be much more dynamic. For example, you could set a const that defines max number of units across all players then divide that by the number of filled player slots to determine max units per player. You could even, when a player is killed, spread the killed player's quota of unit slots around the remaining players so they can increase their army size.

As for weather, I'd love a JS API function to get/set that, but the most common use case would be to make default weather map-specific. For example, you don't want rain on arizona. I assume weather works this way already to some extent - current map system makes you choose a tileset (arizona, rockies, urban) and uses that to determine skybox, tileset (I think?) and applicable weather for the map. If there are future plans to let maps use tiles from any set, then there'd need to be a way for map maker to define which skybox and weather to use for their map (as it would no longer be clearly stated what tileset its using). The main use of exposing weather to JS API would be for scripting in-game cinematics.

[Avestron]

I would personally like to see part attributes become de-hardcoded.

Such would permit the inclusion of new attributes like 'max-ammo', 'max-fuel', 'stealth factor' (counter-range) and so on to make easier the prospect of mods inclusive of such elements.

Even the coordinates of other modules in relation to the bodies concerned could be modified, permitting a greater flexibility in the artistic department.

-

Not sure if music play lists or campaign listings (after all, why should there only be one?) could also benefit.

[felipe]

I agree with both of you.

But, none of the developers have something to say ?

What's wrong ?

[Per]

Nothing is wrong. I have been working on making more stuff customizable as part of my conversion of stats files to .ini format, and as part of the conversion from wzscript to javascript. I agree with the ideas in both the first two posts. Some help in this department would be appreciated.

[felipe]

Ok Per, thx for the reply.
I'll be on irc the most I can, to discuss more details.

[Stratadrake]

I haven't checked all of these against 3.x, but going from memory:

- VTOL speed modifier (light = 100%, medium = 75%, heavy = 25%).
- VTOL flame effect is specified on a per-body basis (Body.txt), should be per-matchup (BodyPropulsionIMD.txt) .
- EMP duration (10 seconds).
- Thermal weapons always one-shotting scav infantry instead of calculating normal damage.
- PIE file animation. anim.cfg (which is moddable) handles the event mapping but the actual events are hardcoded.
- Weapon trail GFX is hardcoded for indirect, rocket/missile, EMP/command/electronic/flame weapons.
- Weapon projectile GFX is hardcoded for flame/EMP/command/electronic weapons.

These we probably wouldn't want to change anyway, but are hardwired just the same:
- "Water" terrain is impassable except via hover.
- "Cliff" terrain is impassable by ground.

[Iluvalar]

These we probably wouldn't want to change anyway, but are hardwired just the same:
- "Water" terrain is impassable except via hover.
- "Cliff" terrain is impassable by ground.

There is already a per terrain speed modifier table, I believe the best is to make the game reconize that a 0 modifier mean impassable.

And yes, climbers, cliffhangers and also civil wheel (refuse to go in mud) is part of my dream wish list, i'd like to mod.

[felipe]

Do really have sense to be able to cross cliffs or water ?
Map makers use water and cliffs to limit specific units passage.
Changing this will have a big impact on ... a lot of thing.

I was looking at all the stats files and can't find a proper place to put all those new variables.
A new limits.ini seems the right place for me, at least for the majority of them.

My proposal is to make changes in:

brain.txt:
- Commanders starting number of droids
- Multiplier for the number of droids

limits.ini:
- Maximum number of commanders
- MAX_CONSTRUCTOR_DROIDS
- MAX_MP_DROIDS
- MAX_SK_DROIDS
- MAX_TEAM_DROIDS
- MULT_EXP_SK
- MULT_EXP_MP

And going on putting values that not fit any of the existing stats files in limits.ini.

[Andrie]

Do really have sense to be able to cross cliffs or water ?

Yes!

Map makers use water

Add a rules.js function to disable hovers!

[Stratadrake]

These we probably wouldn't want to change anyway, but are hardwired just the same:
- "Water" terrain is impassable except via hover.
- "Cliff" terrain is impassable by ground.

There is already a per terrain speed modifier table, I believe the best is to make the game reconize that a 0 modifier mean impassable.

As beautiful as that sounds in its simplicity, consider this: Pathfinding data must be pre-generated on a per-map basis, so there's a clear advantage in having fixed definitions of what is / is not traversable. So while it would be neat if we can mod it, the ramifications on the mapmaker would be hell....

- VTOL speed modifier (light = 100%, medium = 75%, heavy = 25%).

More specifically, this could be specified on a per-chassis (Body.txt) basis. Then it would be possible to make chassis specialized for VTOL usage.

[felipe]

A php script I made to convert csv to ini.

[Per]

limits.ini:
- Maximum number of commanders
- MAX_CONSTRUCTOR_DROIDS
- MAX_MP_DROIDS
- MAX_SK_DROIDS
- MAX_TEAM_DROIDS
- MULT_EXP_SK
- MULT_EXP_MP

I think all of these should be set by javascript from rules.js, that way they can be changed dynamically, which would be useful for campaign and challenge scripts, for example.

[felipe]

Updated cvs2ini to v1, now quote the fields containing spaces.

limits.ini:
- Maximum number of commanders
- MAX_CONSTRUCTOR_DROIDS
- MAX_MP_DROIDS
- MAX_SK_DROIDS
- MAX_TEAM_DROIDS
- MULT_EXP_SK
- MULT_EXP_MP

I think all of these should be set by javascript from rules.js, that way they can be changed dynamically, which would be useful for campaign and challenge scripts, for example.

even better than my proposal

[Shadow Wolf TJC]

Might as well list a few things that I'd like to see:

- Allow modders to specify max commanders in rules.js and/or multilim.slo/multilim.vlo
- Allow modders to specify max construction droids in rules.js and/or multilim.slo/multilim.vlo
- Get rid of hidden scripting that prevents players from being able to tell trucks to build additional factories whenever 5 or more factories are present, even if game settings allow players to do so (usually through modding). See ticket #3775 for more info. (OK, so this isn't exactly a request to unhardcode something, but it does seem like something that's unnecessarily preventing modders from allowing players to build more than 5 factories. )
- Unhardcode how propulsion is supposed to move around (that is, whether it's supposed to turn in place like tracks or Cyborgs, or turn while moving like wheels, or slide around like hovercraft for example).
- Unhardcode sfx that is played whenever a howitzer-type weapon is fired. (In addition to the sound that is assigned to the howitzer via weaponsounds.txt, it also plays hwtzflgt.ogg.)
- Unhardcode scripting that causes machinegun-type weapon rounds to randomly play one of the following 3 sounds upon impact: richet1.ogg, richet2.ogg, or richet3.ogg.
- Unhardcode EMP, NEXUS Link, and LasSat Command Post scripting so that modders could more easily modify how they work (and to possibly allow them to create new superweapons ).