For example , we can display ST3sniper's toggle on a custom window , and give it custom tooltips so that it will be hard to confuse with their current mode anymore
Posts made by illumination
-
RE: Expansion Technology Pack
-
RE: Expansion Technology Pack
I'm really glad I've finally implemented that . I thought it was very hard . I'm really surprised and proud , since since now , there're more choices for game modding , as you can script some very specific codes and assign them to a certain button . We can develop many , many interesting things depending on that
-
RE: Expansion Technology Pack
The Second Construction Panel (SCP) mod done . I will upload it for technological reference .
-
RE: Expansion Technology Pack
Codes link : https://github.com/BornOfSet/TheSecondConstructionPanel . My English is bad when it comes to describing complicated concepts.
I love this kind of tidy neatly codes . -
RE: Expansion Technology Pack
Current progress . Succeeded in commanding engineers to build units from the second construction panel. The engineers are not able to build things beyond their current techlevel and things having no statement of being able to be built by things other than factories . Having trouble commanding engs group to build the same structure . Yet I have no complete ui interacting functions, so they can only build buildings at their current location. Having a layout problem about displacement as well .
-
RE: Expansion Technology Pack
@jip It's a ui panel displaying several units with specific categories , e.g. , you can add a field named 'XDSDDSDSD' in bp and this panel is able to find out all the units having the category called 'XDSDDSDSD' . I want to create the second construction panel
-
Expansion Technology Pack
Total Mayhem and other similar sim mods which add more units into game have the problem of construction-ui overload , where all kinds of units , vanilla and mod , mixed together , let alone some mods have even terrible icon designs , making it as much not intuitive as possible . But you all love playing with a large number of mods.
So , I think , it'll be a good idea to put mod units into a separated 'folder', which is , in this case , the T5 construction bar . I'm working on a mod for this .
I'm learning the manner FBP Orbital uses of adding more tech levels into game . This is my progress now .
The resizing function is not perfect yet , but is playable . Just pay attention not put this too large even having the dragbar out of the screen , in which case the only method to bring it to its place is re .
How about a 'Top Secret Protocol' ? You can do this based on my mod .
For now , it has no buttons yet , but I will add them later . The problem is , how to create a unit that's 'beingbuilt' on the ground , so it won't cheat ?
And what's more , as the title said , there's something doing great changes to the vanilla gameplay . An example is 'DesyncedSalvo' .
Which is able to fire one gun of the set while the another gun of the set is during recoil , which is not possible in vanilla because it will force that recoiling gun back to its place when it's going to fire another gun of the set. This will greatly optimize Cybran weapon effects . -
Question about SimLua
I met problems when I was trying to call global functions .
The game warned me ' access to nonexistent global variable xxx' , but I make sure these ones actually exist.
Except for those defined as elements of a certain table, there's still magical bugs.
For example , DamageArea , GetEntityById . These global functions cannot be found .
After looking up this post .
https://supcom.fandom.com/wiki/Console
I tried a lot in game console and if I prefixed commands with SimLua , they woul run . And I think it's maybe because some commands are storaged in SimLua Global , which cannot be found in Lua Global .
I was trying to call functions in SimCallBacks.lua , which failed. But I know I can call DamageArea in Effects/Entities , what's form of power is that ? -
Patch for hotkey modding tutorial
Since it's another part , I'm aiming to post a new post.
What's the difference between UserKeyActions and UserKeyMap ?
1. Every time you insert something into UserKeyActions , the game will automatically update UserKeyActions table in game.prefs , but without a specific hotkey bound , what is updated is only UserKeyActions .
2. Once you distribute a hotkey for the added new action , the game will copy the default key mappings into UserKeyMap and UserDebugKeyMap , and automatically update your custom hotkey into UserKeyMap even if it's a debug hotkey , thus UserDebugKeyMap is not important in this case.
3. As a kind of overriding specification of SupCom , once UserKeyMap exists , the game will only read mappings from UserKeyMap , ignoring default key mappings , which is why if you delete some of UserKeyMap's elements , the corresponding hotkey lost in game.
4. To solve 3 , you can delete UserKeyMap entirely , which drives game to read datas from default file .
5. UserKeyActions is maybe a interface left by someone to make customing hotkeys easier . It's complex to explain , but there is a bug if you don't use this convenience :
Your own hotkeys won't be recognized until F1 pressed detecting hotkey files once again , since the command path is written else where the program had already passed through ,while the path written in UserKeyActions can be recognized automatically. (there is no place other than /lua/keymap that can be read if you don't use UserKeyActions )
Thus I think it's impossible to define custom hotkeys in /lua/keymap by table operations in gamemain.lua . The program had already passed through.
6. Defaultly , players don't have UserKeyMap or UserKeyActions in game.prefs , if you do , maybe your game had encountered a SetUserKeyAction command sometime , and you gave the custom action a hotkey .
7. It's terrible to get polluted game.prefs rid of various custom hotkey mappings from UserKeyActions and UserKeyMap by programming manner . If you have a polluted game.prefs consists of tons of esoteric hotkey mappings , delete the UserKeyMap , leaving the actions blank without hotkey , and distribute them manually again. -
RE: The MOST detailed UI modding tutorial · hotkey aspect
@reckless_charger I know this . Mine is modifying lua , not game.prefs
-
The MOST detailed UI modding tutorial · hotkey aspect
[Guide for UI modders]
This is a tutorial for those who want to add their own hotkeys into game.
I don't know how the original game binds keys to various actions , but the following is a way available for modders
Firstly , we need to pay attention to this directory , for Windows , it is
-- C:\Users\User\AppData\Local\Gas Powered Games\Supreme Commander Forged Alliance --
And you will find a file named game.prefs here . Yes , 'prefs' is the suffix , thus you must tell your Windows which application you want to open it with. Mine is notepad ++
This is where SUPCOM storages its user datas .
How to access it in game ? It's a function embedded in Engine , and you can find it in
-- SupCom\mohodata\lua\user\prefs.lua --
You will see something named 'GetPreference' here.
It can be found on supcom wiki , however , only such a perfunctory statement.
'INFO: obj GetPreference(string, [default])'
What 'GetPreference' actually does is extracting datas from game.prefs . That's why you can pass 'profile' , or 'profile.profiles' to it , as the game.prefs itself contains these tables.
Secondly , we should notice that there is a thing called profile.current .
It is a number , recording how many profiles you have in game.
Emmm.....
Is it really that simple ? Of course not.
Another role it plays is pointing to the current profile , which is used by Player now. New profile would be added to the end of profile table , and its index is just equal to the total sum.
So you would see these codes .if profile.profiles[profile.current] then
As profile.current pointing to the current profile , the current profile must storaged with a index having a value of profile.current , which indicates that all the profiles are storaged in profile.profiles . You would understand the abovementioned code better if you take a look of game.prefs.
Thirdly , take a look of this line of codes.
profile.profiles[profile.current][fieldName] = data
If you do have took a look of game.prefs , you would notice the variable called 'fieldName' .
You can put whatever you want into this variable , even give it a value of 'asdjoiadjgrjsiofgjsdoigr' , though which won't be discerned by game.
I'm not talking about something magical , but if you want your custom fieldName can be recognized , you need to assume that there're really a ton of lines of fixed codes somewhere you can't reach , saying 'local x = profile.userkeyaction' , or something like that , fixed , unchangeable .
Thus if you want your codes be recognized by game , especially to put your custom hotkey into use , you must follow the specification .
The specification I found is following:
If you want to add your own hotkeys into game , there're two things you need to pay attention to.
One is action, the another is category.
Game says : There will be v.category . Then there popped out a rule for modders that if you don't have a element indexed with string 'category' in table , even if this table contains actual command , game won't recognize it.
Category is necessary , but what value it actually holds is not important. You can say:local t = { action = 'rtertghfgh' , category = 'bbhhnjnjfg' }
Just keep category ~= nil , and if there's no such a bbhhnjnjfg category , game will create a new one. You can press F1 to see this category printed out .
For action , if you don't give it a string path value like
"UI_Lua import('/mods/apimod/lib/main.lua')._print()"
The game would remind you that unknown console command not found.
e.g. The game won't find what is called rtertghfgh.
But anyway , it runs successfully .
Keep it in mind that if you don't have a action stuff while still having category , the game will crash at the beginning , because he cannot comprehend a nil value as actual path .
And if you have both two , you can put them together into one table .
Usually , we have another element called order , but this is not a thing decisive
Finally , your codes look likelocal t = { action = "dxxxx", category = 'dxddx', order = 35 }
You can add whatever you like into variable t , though they will not be discerned.
It's also legal.local t = { 12,34,45,67,89,90, action = "dxxxx", category = 'dxddx', order = 350 }
We are not finished yet.
After completing table t , we need to put t into a larger table .local s = {t}
Somewhere we can't see , game loops table s , and for each k,v in s , it loops v to know what category this v has, and what action this v refers to , and prints k as a description of the action in v .
If you directly pass t as the result , like thatPrefs.SetToCurrentProfile("UserKeyActions", t)
Things you made won't be shown in game , as the game is attempting to loop a string value. The game would get stuck .
Once everything set well , you should worry about the description shown out.
The game shows index of table t in the table s as the description for the t , which is number 1 in this case.
You can set the index as a string , but that's not convenient.
Mine solution is :local keydes = import('/lua/keymap/keydescriptions.lua').keyDescriptions keydes[1] = 'dsdsds'
Note that I said keydes[1] , not keydes['1'] , as the index is number not a string.
Lua passes table from = rightside to = leftside as referrence , so you can call keydes[1] to modify original table , which is the one game reads datas from.
Thus one gamemain.lua file does all the thing , no need for modders to put keydescriptions.lua into hook.
Eventually , the hotkeys bound to custom actions are shown in currentprofile.UserKeyMap .
Thus , even though you clear UserKeyActions , there's still referrence to the hotkey bound to the cleared one.
Theoretically , you can make use of \lua\keymap in similar way , to achieve similar function without using UserKeyActions , you can make a try. I suggest you to do these in gamemain.lua , do not put too many files into hook to mess up your mod.