Questions about following Exavier Macbeth's Modding Guide

[Crazy Cossack]

I need to orient myself with regard to file housekeeping for modding. The explanations and questions below relate to Exavier Macbeth's Modding Tutorial Guide. First, I have to quickly set the scene of where the files are on my PC.

My current FAF Build is at;

C:\ProgramData\FAForever\

And it points to;

fa_path = 'C:\\Program Files (x86)\\Steam\\steamapps\\common\\supreme commander forged alliance'

But my original FA (steam purchased I think) is at;

C:\My Name\My Documents\My Games\Gas Powered Games\Supreme Commander Forged Alliance

So my 1st question is:-

Do I Mod the FAF from C:\ProgramData\FAForever\ and do I do it in my newly created Mod workspace as per Exavier Macbeth’s instructions?

My 2nd question is:-

Do I then create a Mods folder in C:\ProgramData\FAForever\ and place my mod there?

Can I assume that FAF points to steamapps and then my original FA? Or does it just point to steamapps? Or does this last even matter for my purposes? To put it simply, will a functional tested mod placed in C:\ProgramData\FAForever\Mods be available for selection and functional when selected in the FAF lobby via “create a FAF game”?

[nine2]

I am a beginner but here is my two cents

firstly understand that FAForever overrides some files from the steam version
you will be overriding one or more files from that ^^

You think you have multiple FA's installed but you don't.
steamapps is your 'real' copy of FA.
programdata\faforever is FAF which has overrides of FA but does not include the complete game
mydocuments just contains your settings - maps, mods, etc

Q1. I would just unzip a few files from the steam gamedata directory somewhere. In the back of your mind realize that FAF might also override those same files but you don't need that distraction for now. (Otherwise you need to read both the original and overriden files to understand what is going on ... of course there may not be an override at all - i would just ignore this for a while)

Q2. your mod would just copy a few of those files into your own mod folder which lives in my documents:
C:\My Name\My Documents\My Games\Gas Powered Games\Supreme Commander Forged Alliance

FAF points to steamapps which IS the original FA
You will place your mod in my docs

[nine2]

perhaps this is useful too
viewtopic.php?f=41&t=8103&p=76817#p76817

[Crazy Cossack]

Yes, thanks partytime. On further checking I found out that what you say above is correct. This has cleared up my first mis-conceptions. I now understand that it as follows.

Original FA/SC Install @
C:\Program Files (x86)\Steam\SteamApps\Common\Supreme Commander Forged Alliance.

User Reference Data @
C:\Users\My Name\My Documents\My Games\Gas Powered Games\Supreme Commander Forged Alliance

FAF mod install @
C:\ProgramData\FAForever\
Current build stamp is 07/07/2014 @ 11:12 AM.


Yes, I am worried about FAForever over-riding some files that I might change. This is because what I want to do is the following in this precise order;

1. Use last official patch of FA/SC.
2. Then apply all over-rides of FAForever Mod.
3. Then apply all over-rides of my Mod.

In other words, I want the end effect to be that I am modifying FAF (which in turn modifies last official patch of course).

I wonder if it is is easy or hard to describe what kind of hooking I need to do to achieve this? I recall reading somewhere about destructive and non-destructive hooking. Does this have something to do with it?

Footnote:-

I have successfully done a very simple testmod that changes a few parameters in the ACU blueprints. For example, I gave the ACU different walking speeds and different build ranges just to test things. Then I gave the ACU a zero starting speed and tried to add acquisition of walking ability to the T2 build upgrade. I found I could not do that via blueprint alone. It appears I now need to get into Lua scripting. I looked at how Nomads mod did ACU speed upgrade but I don't yet undertand what and where all the file calls and/or parameters are being called in from. So I need to understand the file structure more and the calls and parameters more.

I also need to learn Lua scripting. I do know basic programming principles from being a competent self taught Turbo Pascal programmer some years ago. I wrote a relatively simple program to play chess so I do have some concepts. For the geeks, I only used a simple minimax algorithm not the more sophisticated alphabeta algorithm to search the move tree.

Luckily, my son is an ace Python programmer. He gets Distinctions and High Distinctions in his Electrical and Software Engineering (3rd year). He took one look at Lua and understood it all immediately. So he can help me wrap my mind around scripting concepts (categories etc.) in Lua which are a bit different conceptually from old-fashioned, standard programming.

[nine2]

The order of overriding will happen the way you want it automatically, don't worry.

Destructive hooking is when you replace a file completely.
Non destructive hooking is when you replace just a part of a file (like just one function) and probably call the old function anyway, just adding your extra bit before/afterwards.
So you theoretically want non-destructive hooking to ensure you dont mess up any of the stuff that FAF has introduced. Having said that, in my beginner opinion the code is just mashed up everywhere and doing things cleanly is often impossible. Which is why FAF itself seems to use destructive hooking a lot and therefore sometimes you must also.

Lua is probably as easy as it gets so you probably just need to unlearn a thing or two. It's easy, you will see, and you don't need your son either just go through the code for a screen you understand, like one of the menus. There are many quirks to learn but they are moho/fa quirks - not lua quirks.

[Crazy Cossack]

Erm what is moho? What does moho mean?

[nine2]

Moho is the game engine that they made. Supcom is built on top of moho, so are some other games.

You can not change or even see the code for moho. This stuff is 'hard coded' (in c++) and is the reason why the modders can't fix all of the problems with FA. You can only change the lua files which give moho instructions, and ask moho questions.

The other thing you need to wrap your head around is the difference between the Sim and Ui parts of the game. There are basically two sets of code running at once, separately to each other. Ui is everything to do with clicking, menus, tooltips, ui stuff. Sim is the physics, economy, the actual game running. This is a very important distinction because once you 'get' it, you will understand what you can and can't do pretty quickly.

You know how you can have your own Ui mod running and the other player doesnt know about it, but the same is not true for Sim mods - why is that ? It's because sim mods are allowed to make alterations to the way the game behaves. Whereas ui mods really only change what you can see or indirectly place orders using the exact same code-mechanisms as normal. The way I think about it is when watching a replay - would my mod code make a difference to a replay of that match? If a user watches the replay without my mod - will it turn out the same way? If so, then you're in ui-mod-land. However some changes are not the same - for example your ACU change mod - if you tried to watch the replay without the mod then it would desync because at some point you attempted to do something that was impossible (eg: send a move order from somewhere you weren't).

Ok pretty crappy explanations but I'm in a rush

[Crazy Cossack]

That is a good reply thanks. It makes sense.

Initially I guess I will be working with some of the files from;

C:\Program Files (x86)\Steam\SteamApps\Common\Supreme Commander Forged Alliance\gamedata

There is a Units folder and then separate from the Units folder there are these files;
• ambience.scd
• editor.scd
• effects.scd
• env.scd
• loc_US.scd
• lua.scd
• meshes.scd
• mods.scd
• mohodata.scd
• moholua.scd
• objects.scd
• projectiles.scd
• props.scd
• schook.scd
• skins.scd
• testures.scd
• units.scd

The Units folder does not have all the units. All the units seem to be in units.scd which has to be unzipped. When the units file is unzipped I can find all the units. For example, UEL0001 is the UEF ACU.
Inside the folder UEL0001 there are .sca files, .dds files, .scm files, .bp files and a .lua file.

It appears that the important files to mod are the UEL0001_unit.bp file (as this is the blueprint file) and UEL001_script.lua (as this is the ACU script file) for UEF ACU changes that is.

What are the other files (.sca files, .dds files, .scm files) and would I be likely to need to mod them?

Also, what about the files in the higher level lua and moholua folders? Would I be likely to need to work on them? OK, you have answered this basically.


Some of the changes I will be making are;

• ACU starts game stationary and needs upgrade to walk.

• ACU and SACU RAS upgrades will produce less income.

• Cost changes (usually upwards) in terms of M and E for factories and units.

• Factories will have higher relative cost compared to costs of units they produce.

• Resource income changes (e.g. T2 mexes and T3 mexes will make less income than currently).

• Adjacency bonuses will become more important again.

• There will be engie factories which make only engies and military factories which make only military units. How I accommodate this graphics-wise might be tricky. The idea is that there will be a development succession. Intially, at T1 the ACU will only be able to make civilian factories and its standard list of other fixed T1structures except for military factories. The ACU will get the ability to make military factories from the T2 upgrade. Thus, the starting succession to get military units will involve ACU building engie factory, plus some mexes and some energy makers. Then the T1 engie factory must make T1 engies and the t1 engies can then make T1 military factories, more engie factories if required and/or range out and expand at other mex sites etc.

• Another change that will take standard FAF players some time to get their minds around, either theoretically here or in actual play will be this. Costs of fixed structures and some capital (large) units will escalate. This is to say that (for example) the first military T1 factory will cost x mass and y energy. The second military T1 factory will cost maybe double ie. 2x mass and 2y energy and so on doubling each time. Thus, while T1 units will be made a bit more effective against T2 units than is currently the case, the inflation of T1 factory costs will mean it gets to the point that a first t2 factory is a better investment than another (now heavily inflated) T1 military factory. This will go on up the scale to T3 and T4. Large capital units like experimentals and fixed PD will also escalate in cost as more are built.

In some ways, these concepts will have trouble being combined with FAF engie mod but I don’t want to ditch engie mod as it is the current standard.

I give the above examples really to enquire in broad terms what files I need to work with to make such changes. I know a lot of people will think many of these concept changes are bad ideas. Let me just say that the resulting mod will be very, very different from standard FAF. They will be two totally different games. Standard FAF is a great RTS of its type. I will be seeking to make a good RTS of a very different type. The reason for escalating the costs of factories, capital structures and some capital units (but not standard T1, T2 and T3 mobile units) is to push the game growth model from the exponential to the linear. There are deep theoretical reasons for doing this to get a different kind of game.

In summary, the main theoretical reason is that linear growth games are more strategic whilst exponential growth games are more tactical. This is a counter-intuitive fact. You would think that exponential growth games are more strategic because you more rapidly get to high resource production that enables expensive strategic weapons. However, exponential growth games are more tactical because an early tactical loss knocks you off the exponential growth path and you rapidly get out-ecoed. In a linear growth game, early tactical losses do not have such large ongoing effects though they still do have effects. Furthermore, strategic weapons whilst strategic in effect are not very often strategically complicated in execution. The simple point and click of a nuke launch is an example of this.

The net effect of these changes would make a game that is more about the military and a bit less about the eco... to a point. Eco will certainly still count.

[nine2]

Weird, i don't have a units folder - just the units.scd, is it possible that unzipped a few long ago into the units folder? Anyway, use the scd.

.sca files, .dds files, .scm files, .bp files and a .lua

.dds is an image format (could be icon), .bp is blueprint, .lua will be some behavior (maybe this could be a place to look on the nomads acu?)

Also, what about the files in the higher level lua and moholua folders? Would I be likely to need to work on them?

Lua.scd file is of great interest to you.
Moholua.scd & other scd files - not so much.

I give the above examples really to enquire in broad terms what files I need to work with to make such changes.

well I wouldn't have a clue how to do half of that. maybe you should prioritize easy tasks so:
- changes to costs (just edit blueprints)
- changes to adjacency (there is a buffs file in lua.scd somewhere)
- disabled acu & dynamic factory costs - hard - not out of the box - leave til last

The net effect of these changes would make a game that is more about the military and a bit less about the eco... to a point. Eco will certainly still count.

interesting enough, i like the idea of a new vision - might be quite an investment in pulling this off

[Mr-Smith]

the unit icons are saved somewhere else and just get defined in the blueprint.
the .dds files are the unwrapped textures for the units and the .scm should be the model itself than