Modding: Engine Support Wishlist

[Gazz]

Since the issue is near and dear to my heart, I'll hang on to all that expended brain sweat. =)

Chris' Basic Modding Guide thread is more an overview and about what can and cannot be modded.

This here is a summary of things that modders would like to mod regardless... but cannot... with the current state of the engine.

I would like to ask you to be brief so this thread does not turn into another non-navigable morass but hey... looks who's talking.

Note that this is a modders' wish list and not for playable game features.

Only for the engine to support certain functions / properties so that modders can create the features.

No grand frontends, no artwork, no balance issues.

If you have an idea then everything here is based on the premise that you (and not "somebody"!) will be doing the work of creating the actual feature.

View Ranges (tactical combat)

View ranges for humans day / humans night / aliens day / aliens night

would be externalised into config.xml.

Different alien races would then use % values of this base value.

The big-eyed Ceasars might have 110% of the basic "alien" view range.

The equivalent of gruntish mutons might have 85-90 %.

This would allow balancing of the main view range (like for another difficulty level) without completely redoing the relative view range assignment of every single alien race / subrace.

View Range Modifiers

Held items and worn armour could have a modifier for view range + view angle.

Holding binoculars reduces view angle but increaes view range.

Some kind of close quarters assault armour vastly increases the view angle but reduces view range.

This prevents one armour type from being "always best". A mix of scouts and stormtroopers would be more advantageous.

General item boni - especially with armour

This is probably the single best chance for modifying ground combat because through the armour types one can design drastically different soldier abilities and therefore roles.

Different troop trees, so to speak.

If you read anything in this thread, then this bit. =P

Items, but especially armour, should allow for a wide range of boni.

Adding AP, Accuracy + View range would create a light "sniper" suit with improved sensor and fire control electronics.

Adding more armour, strength and possibly even morale gets you a grunt suit.

The grunt suit would add carrying capacity by adding more strength than is required for wearing the suit. The soldier can carry heavy weapons and lots of ammo.

The sniper / scout would be more mobile but have to "travel light".

That would allow for more depth and specialisation while remaining balanceable.

Everyone can only wear one suit of armour after all and they cannot be changed during the mission.

Weapons would have other modifiers. The most obvious one would be Reaction.

A pistol might have +10 reaction while a machine gun has -10 and a sniper rifle -15 or -20.

A pistol / SMG / carbine does allow you to react to surprise attacks more readily. That's what they are for.

Instead of hardcoding any rules, a Reaction stat bonus would do the same thing and be adjustable in the XML file.

Flat attribute boosts would be a Bad Idea™ because they annihilate the need for soldier experience.

What is a much better approach is to let an armour give a % increase to a stat.

A 130% strength armour is not going to turn a 30 strength soldier into the Hulk. It only goes up to 39.

This way a heavy suit of armour can let a soldier use very heavy weapons that unaugmented soldiers can't use or can't use very well.

For the really good stuff you still need a naturally strong soldier, though, so soldier experience always stays valuable.

Soldier starting stats

How high are the stats of a newly hired soldier?

Could increases to these hiring stats be tied to research items?

This would allow hiring "better rookies" late in the game and allow them to be useful (although not excellent) replacements for your advanced squads in the later game.

What about your "special" starting soldiers? How much higher can their stats be?

Another "colour" suggestion:

soldiernames.xml

Instead of

<Regiment name="regiment.america1">

<Experience>experience.none</Experience>

<Experience>experience.america1</Experience>

</Regiment>

it could be

<Regiment name="regiment.america1" chance="10">

<Experience Name="experience.none" AP="0" Resilience="0" Strength="0" Accuracy="0" Reflexes="0" Bravery="-3" chance="30" />

<Experience Name="experience.america1" AP="5" Resilience="0" Strength="2" Accuracy="3" Reflexes="0" Bravery="0" chance="70" />

</Regiment>

A particular service history would give soldiers stat boni when they are generated.

Pure infantry troopers could march others into the ground (+AP), while spec ops would have higher reaction.

There could be a low chance to get someone from a recon (sniper) company with good accuracy...

More colour!

The service history being only randomised fluff text is pretty meh.

Building stats

How well / fast an "Advanced Alien Medbay" heals soldiers, how many persons can live in "Living Quarters", what the upkeep / cost are.

What function a particular building has, including multiple functions, such as

RADAR (range and detection chance), Garage (vehicle storage capacity and repair speed(?)), Hangar (aircraft capacity and refuel / repair speed), younameit.

Building stats...

Currently all of this is hardcoded.

Interceptor Weapon Bays / aircrafts.xml / aircraftweapons.xml

Right now there are only "normal" or "heavy" weapon bays.

And yes, you can mix them on the same aircraft, for instance giving the F-16 2x normal and 1x heavy weapon bay. That already works.

I suggest that this assignment is reversed so that each hardpoint has a list of compatible weapon classes.

The aircrafts.xml table snippet for the MiG currently looks like

NormalWeapons / HeavyWeapons / WeaponPositions

0 / 4 / 17,52;58,52;27,43;47,43

If it looked like

Weapons / WeaponPositions / WeaponClass1 / WeaponClass2 / etc...

4 / 17,52;58,52;27,43;47,43 / normal,heavy / normal,heavy / etc...

there would be more freedom in assigning which kind of weapons an aircraft could carry.

In an extreme case there could be a weapon that only a single aircraft type could carry, like a heavy cruise missile that only a B-29 could lift.

In addition to that, aircraftweapons.xml should allow attaching a weapon to multiple size classes.

While both F-16 and MiG-29 are air superiority fighters, the F-16 carries a 20mm gatling gun and the MiG a 30mm cannon.

All the "normal" weapons would be attached to both hardpoint types except for the guns. These would only be compatible to "their" hardpoint type.

This twist to the system would keep inventory management down because the player would not be dealing with a doubled or tripled list of identical weapons.

Since "heavy" would not automatically include "normal", hardpoints could be balanced more accurately.

An "only heavy" hardpoint on the MiG could carry a 2x pack of Sidewinders but not the 1x Sidewinder "weapon". It would also not be compatible with the normal-sized autocannon.

Aircraft could have their loadout somewhat restricted to their intended role so it's easier to avoid having one "always best" aircraft that can carry everything and the mostest.

Internally it would not be a big change because when equipping aircraft each hardpoint already has a type and only offers weapons that match this filter.

What would change is how the type is read from aircrafts.xml and the filter mechanism.

IMO, a maximum of 5 weapon positions should suffice.

If someone were to mod somewhat realistic aircraft loadouts then these pracically always have uneven numbers with one hardpoint under the fuselage.

Edited February 13, 2012 by Gazz

[Gazz]

Interceptor Sensor Pods / aircraftweapons.xml

A weapon property of "RADAR Range".

With such a sensor pod equipped, the aircraft would use THIS RADAR range instead of it's own.

Multiple pods would not be cumulative.

A FiringArc of 0 could tell the engine that this "weapon" is not meant to be fired at all.

This would allow to "upgrade" aircraft later in the game when you may have to find alien bases on earth.

In the same vein, ECM Pods

would either give a bonus to missile avoidance and / or substantially increase the UFO's lock-on time.

That would force the player to decide between more weapons or more defense.

Flight/Hover

For flying armor mod/variant.

Teleportation

For making a Teleportation Device. Cary a piece with you, and leave a piece like a "marker" to the spot you want to Teleport to.

I was thinking about the changes I have made to the game so far using the xml files and decided it was just a little too messy.

For example if I want to make a Jackal_2 armour type I would need to edit 4 or 5 xml files to add the entries required to make the artwork show up in game and the item to function.

If I now want to send my hard work to Gazz, who has been making a weapon mod, he would need to edit all of those xml files again to add my entries or overwrite his own modified files with mine.

My suggestion to make the process easier and more streamlined would be to make a few changes to the way the xml files are handled.

Strings.xml, armour_gc.xml etc should each have their own folder.

The game would load up the default files as normal then check the folders for any other xml files.

I could then make Jackal2_string.xml in the strings folder, jackal2_gc.xml in the armour_gc folder and have them loaded up without altering the original files in any way.

Now when I want to send someone my hard work they can just be unzipped to the correct folders without affecting any other mods they may have (unless they happen to have the same filename).

I am unsure which file should take precedence though. Should the original item be overwritten if there is a mod item with the same name or would it make more sense for the original to always be dominant?

An important point but not easy to solve.

One point that I would like to stress is to keep the mod files away from the game files.

If you start replacing files, you're in serious trouble when buying such a game from a digital distributor like Steam.

Instead, when loading files (any files) the engine should only look for mod stuff if the current folder contains a "Mods" folder.

After reading all entries from the vanilla folder, the engine checks if the mod folder contains a file(s) with a similiar name.

If so, all entries in that file(s) overwrite the entry in the game.

Example:

\Build_V5\assets\cities.xml

After reading cities.xml, the engine checks

\Build_V5\assets\Mods\cities01.xml

\Build_V5\assets\Mods\cities02.xml

etc.

All files are read and they are read in sequence.

So if cities01.xml adds Chicago, cities02.xml can add Bremen or alter the position of Chicago.

This system does not only work for XMLs but for every kind of file. Graphics can be replaced like that.

The big issue is that you never completely screw up your game. It's a virtual file system where the content of files overlays that of other files without physically overwriting it on the HDD.

Rename the Mods folder and all changes are gone. Poof.

That's pretty much what I was saying apart from the addition of the extra step of putting all of the folders inside a single mod folder.

That does make things easier to track.

I would avoid looking for specific file names though.

Duplicating the xml filenames as sub folder names inside the mod folder would tell the program where to look instead.

The person creating the mod could call it anything they wanted to.

You would be less likely to get twenty people all creating different mods with the files called armour_01 that way.

That also removes the annoyance of renaming multiple files if you wanted to install a new mod.

The only thing is still the problem of priority.

Maybe make each mod create a 'mod list' file in the mod root folder listing all of the files added to the mod directories.

A simple text file with the 'mod list' filename and a number can be used to allocate a specific priority if you want to.

The 'mod list' file is serving the two roles of giving an easy way to prioritise and letting you track what files a mod SHOULD have installed in order to work.

If you don't need to prioritise then you don't need to add the name into the priority file.

It may not be quite as simple as your suggestion Gazz but I feel it would be a more robust system.

To copy your example:

\Build_V5\assets\cities.xml

After reading cities.xml the engine checks the mods folder

\Build_V5\assets\Mods\Cities\gauddshouse.xml

\Build_V5\assets\Mods\Cities\Ukrainian_Cities.xml

etc.

. Edited October 19, 2011 by Gazz

[Chris]

The wiki should make life a bit easier for you, Gazz - but as far as modding goes, we're going to have to check with Steam whether the files will stay encrypted after download. If they do...well, then it's going to be very hard to mod the game, and we'll have to think something up.

[Gazz]

The last three posts about file / resource formats were on this exact topic.

Any means of modding that requires replacing original game files is completely out of the question when using Steam.

Adding to a Steam "content" folder is no problem at all since the new files are not part of Steam's checklist.

we're going to have to check with Steam whether the files will stay encrypted after download.

They do not.

Steam can produce a "working folder" that exactly matches your current alpha builds.

The real problem is that currently, the only way of modding is to overwrite core game files that must be part of Steam's "check list".

The auto-update function would then routinely "repair" those files, removing all mods.

That's why I (and others) suggested file / data structures to allow modding in a way that does not conflict with any core game files.

It is perfectly possible to add to a "SteamApps" folder without Steam. That is exactly how modding X3 (which exists in a Steam version) works.

All modding there is added on top of the core game files and the engine reads the new files instead of the older core files. This particular system is still quite limited and creates a lot of headaches on it's own.

A "good" system would allow to change only part of a file without having to duplicate the entire resource file with the changes included.

That is the base for combining more than one mod, which is a major headache with replacing entire files.

Edited October 23, 2011 by Gazz

[Chris]

Fair point. Either way, we'll look into it properly once we've got a distribution agreement tied up with Steam.

[Mylar]

When looking at their suggestions to add mods without screwing with the base game files, take a look at Cortex Command.

Basically 90% of the game is the modding. Spend some time using his system to make your own actor sets, change around some weapons and build a scenario or two.

The system for that game is far from perfect but it is... expansive. I'm not suggesting you copy it, just that you take time to experiance it and the things a community has done with it before you implement your own.

[Gazz]

Powering / Fueling items from backpack / inventory items

A flamethrower "weapon" could be fueled from a 4x4 tank in the soldier's backpack.

The ammo value displayed on the weapon would be coming directly from the backpack item.

These inventory items would be at least 3x3 size so a soldier can only ever carry one of them.

This functionality would also make fun stuff like the XM214 possible.

Of course, it doesn't anything as mundane as... single shot.

[Sathra]

Wait, so...Whirlwind Attack with bullets? Cause that could be...fun? Something like fun at least.

[3havoc]

I am not sure how the engine is designed but something akin to a mod launcher within game to handle loading alternative scripts and assets, it shouldn't cause any issues with steam since core files wouldn't be overwritten or modified .

[hawk66]

Is the "Basic Modding Guide" still accessible somewhere? Link seems to be broken, thanks

[Sathra]

I think it got lost when the old forums died.

[hawk66]

I think it got lost when the old forums died.

Ok, then I ask a specific question: Is modding only possible via editing xml files or is there also access to the engine available, eg. scripting?

[Sathra]

Xml only I think.

I'm not quite sure, I usually rely on Gazz to remember the modding stuff.

Edited November 30, 2011 by Sathra

[Gazz]

There is no scripting of any kind.

You can modify content / values, add content of the predefined types, or reskin the UI.

[lionel23]

Question on modding... as I know in the FAQ they say they aren't going to add Female soldiers.. is it possible to 'replace' Portraits? I don't care about the in-game models and I've been leaning on the fence (I like female soldiers ^^) about this, so I wanted to know if it's possible to replace portraits to get a 'female soldier' in the game or is that not editable?

[Sathra]

I think it can be changed, but not quite sure how.

[Gauddlike]

You can change the portraits if you want to, they are located in assets/soldierimages.

I haven't looked to see if there is a file to allow adding new ones though.

I don't believe there is a way to specify a combination of name/face either so you might struggle to get female names to tie in with female portraits.

Unless you rename them manually of course.

[Quartermaster]

This is hypothesis, but you might be able to do it by modifying the following files:

soldiernames.xml - Add a new 'fem' ethnicity, add the nation of 'amazonia' which only draws from the fem ethnicity, add the first and last names that you want, and add a regiment. As a note when setting the ethnicity count it should be the number of pictures that will be used to create portraits (ie. 3 portraits = 3 for the ethnicity count).

In the soldierimages folder, add the female portraits to the various armour.whatever files. Also add hands to the to the 'hands' folder. When adding the images use the following format to name them fem00, fem01, fem02, etc. Same for hands.

Anyways I haven't tried adding an ethnicity or anything before, but looking at the files these are what I think would need changed as far as I can tell.

[Chris]

It would be possible. It's all done soldiernames.xml.

You'd add a new nationality for each nation (Canada2 ec), then go into strings.xml and have Canada2 display as 'Canada'. That way it'd look the same. Then you'd add new portraits in a new group (currently there are northern, mediterranean, asian and black soldier portraits) and set the woman portrait group to appear 100% of the time. Using that nationality, you can change all the names to female names too.

Bit of hassle, but you could do it.

[Overlord]

Where can I mod buildings (construction time etc.)?

[IceVamp]

assets/gameconfig.xml would have it if you can change it. Haven't checked

[Chris]

Not sure buildings actually are moddable. I'll ask the coder when I see him.

[TheTuninator]

Is it possible to add in the ability for players to upload custom soldier portraits? Even if it's a fairly involved process involving editing text files or whatnot, that's something I'd really like to see, as it would greatly enhance the fun of naming my own soldiers if I can attach an appropriate picture as well.

[Gauddlike]

You would need to be able to change images for specific soldiers.

Maybe if you had a mod root folder you could have the game search inside it for folders matching the modified name of a soldier?

If its there and there are compatible image files then use those instead of its own random image?

It wouldn't look great unless you happened to have an image that was just the right size and facing in the precise direction to match the pre generated ones though.

The ground battle portrait would be easier but the equip screen image would have to be pretty much exactly right.

[TheTuninator]

Yeah, I imagine it would be a lot of work, but I'd be willing to go through a fair amount in order to do so as I think it'd be rather hilarious.

If the game doesn't support it, though, it's absolutely not something that needs to be included; I was merely curious whether the game would naturally support a feature like that at launch.