@evan_ said in 100 days of ladder:

How have you guys been finding these reports? Does anyone relate to the issues I am trying to fix with my playstyle? Anyone feel inspired to try and get better with me?

As someone who has been playing for a long time, but not frequently enough, and without seeing much in the way rating improvement, it is definitely interesting to follow your progress (and motivating for me to try something similar, or at least play ladder a bit more often). Don't give up!

@jip Maybe your reply is to cunnismeta, but, for what it is worth, I found out how to do the thing I was looking for.

Try the following, in the game console (with engineer or commander selected):

ui_lua import('/lua/ui/game/commandmode.lua').StartCommandMode("order", {name="RULEUCC_Script", AbilityName='AttackMove', TaskName='AttackMove', Cursor = 'ATTACK_MOVE'})

Interestingly, this works better than clicking the attack move button, because you actually get the correct cursor shown while in the relevant command mode, whereas there is a problem with not seeing a change of cursor when clicking the attack move button.

The lua script I am copying this from is as follows:

local function AttackMoveBehavior(self, modifiers)
    if self:IsChecked() then
        CommandMode.EndCommandMode(true)
    else
        local modeData = {
            name="RULEUCC_Script",
            AbilityName='AttackMove',
            TaskName='AttackMove',
            cursor = 'ATTACK_MOVE',
        }
        CommandMode.StartCommandMode("order", modeData)
    end
end

Note the small case 'c' in cursor, which is what makes the difference. I guess this is probably a bug..

I've been looking into benchmarking the performance cost of different ui mods, and made a minimal ui mod for this purpose.
('OnBeatTimings', uploaded to the mod vault.)

This tells you how long is being spent in UI 'beat functions', on average. (Not the total performance cost of UI mods, in all situations, but something which I think is significant, and which can be measured quite easily.)

To use this, run FAF windowed, open the log viewer and console, set up a benchmark situation, leave it to run for a bit (10 seconds or so) and then enter the following in the console:

UI_Lua import("/lua/ui/game/gamemain.lua").AverageOnBeatTime()

This tells you the average time spent in beat functions which are not flagged as 'throttled', per update.
You can also get the average time spent in 'throttled' beat functions, with:

UI_Lua import("/lua/ui/game/gamemain.lua").AverageOnBeatTime(true)

Note that these timings include time spent in built-in beat functions, as well as beat functions in mods you have enabled, but you can disabled and enable mods and see how this affects the timings.

To quickly set up a benchmark situation, I suggest enabling cheats and then using the copy and paste units thing. (So set up a situation with a load of units placed one time. Select the units. Hit ctrl-shift-C to copy placement script for these units. Paste that into a text editor. To place the units back into game for future benchmarking copy the buffer out of your text editor and then ctrl-shift-V in game.)

When looking into the timings coming out of this I found that one built-in beat function in particular, for 'avatar update', was taking a disproportionate amount of the time spent in situations I was benchmarking.

'Avatar update' is for the ui elements normally towards the top right of the screen that show things like ACU health and shield, number of idle engineers, and so on.

I made another 'micro mod', then, to simply remove this update function. ('DisableAvatarUpdate', also uploaded to the vault.) With this mod installed and enabled, the avatars no longer get updated, so no longer work correctly, but this enables us to quickly check the cost of this beat function, and also enables you to reduce your total UI beat function overhead quite significantly, if you are so inclined.

If anyone is interested:

• Have a go and see if you can repeat my findings (e.g. benchmarking beat function times with and without DisableAvatarUpdate enabled)
• Check the beat function cost of other ui mods you have installed (if there are significant performance costs for running popular UI mods then it would be good for people to know this)

@evan_ said in 100 days of ladder:

This leads into the next point. I've uncovered yet another issue of mine that has gone unnoticed until now: Move overriding. I will give a move order to a unit and then give another order to override it. An example of this is when I put an attack order on a lab that had slipped through, only to change it into a move order for some reason, which caused the lab to escape and continue to cause trouble.

Setting up some hotkeys of the form 'select nearest idle [unit type]' (or similar but adding to existing selection) could perhaps be useful here.

So I'm working on a selection helper mod where I want a given hotkey to sometimes add a unit to the current selection, and sometimes start a new selection, depending on context.

The way I have it set up currently is that, after you made your initial selection, (or add to a selection) it stays in 'incremental selection' mode for a fixed time. So if you press a selection hotkey several times in quick succession you get that many units of that type, but if you wait a certain amount of time before pressing again, it starts a new selection.

The problem with this is that this depends on the user having some idea of the time that has passed since the last key press, which ends up being not so intuitive (in that it will sometimes not do the selection action that the user wanted).

What I would really like is for incremental mode to remain in effect until the current selection is given some command, with selection mode then reverting back, such that the next hotkey press after the command is given starts a new selection.

For this, I need to detect when a command has been given, but I can't see an easy way to this.

Does anyone here know how this can be done (detecting when selected units have been given a command)?
Any other ideas?

@jip Hmm.. so the following also works correctly (shows the same attack cursor while in the new command mode):

ui_lua import('/lua/ui/game/commandmode.lua').StartCommandMode("order", {name="RULEUCC_Script", AbilityName='AttackMove', TaskName='AttackMove'})

(What I did here, instead of capitalising the C, is to just leave out the 'cursor' table entry.)

So maybe 'Cursor' with capital C is not actually correct, then. (This was really just a random shot in the dark, on my part.) Maybe what is happening here is that there is no 'ATTACK_MOVE' cursor, so if we specify that then we don't get any cursor change, but if we instead just allow it to fall back to a default cursor (which looks like it might be the attack cursor, based on the "RULEUCC_Script" name), either by leaving out the 'cursor' table entry, or misspelling this with a capital C, things look much better..

@crispweed said in How to use different strategic icons:

@jip what is the status of this now?

I tried installing "BrewLAN UI Strategic Icon Overhaul Small", which has a load of icons directly inside 'custom-strategic-icons.scd', inside the mod folder, but this doesn't seem to work, I just see the default icons.

Ah, never mind. I was testing by watching recent replays, and seems like these were from a different patch or something. Running patch 3724 now and seeing different icons with this version..

@jip Bingo, yeah, that was it, thanks!

@jip Bingo, yeah, that was it, thanks!

Where can I find this log on the local filesystem, to view it in a separate editor?

@mostlostnoob No, I don't think so, and I just tried this in non-full screen window (floating window), and still no log window opens up.

There is a hotkey action "Debug->Toggles the debugging log window", which was set to F9 for me.

This used to open a window that shows some debug log output, which would show errors from mods, and so on, (kind of essential for mod development), but this no longer seems to work.

I tried mapping this to a different key, in case there was something specifically blocking my F9 key, and instead mapped this to a key that I could see was working in FAF, but no dice. It seems this just doesn't work any more for me.

Does this work for other people?
If not, any idea why or when this stopped working?

@askaholic client.log.2023-03-24.0.txt
The problem occurred around 21:39, in this session, as far as I can work out.
Did you try repeating the problem based on my repeat description, also?

So, often, after playing a game, it happens that I have caps lock turned on by mistake.

And then, when attempting to join a custom game with a friend, this means that the first attempt at entering the game password fails.

And then I've noticed that, when I next attempt to join, and this time get the password right, it seems like the client then spawns two Forged Alliance game processes, which leads to connection problems and general confusion..

@jip Hmm.. so the following also works correctly (shows the same attack cursor while in the new command mode):

ui_lua import('/lua/ui/game/commandmode.lua').StartCommandMode("order", {name="RULEUCC_Script", AbilityName='AttackMove', TaskName='AttackMove'})

(What I did here, instead of capitalising the C, is to just leave out the 'cursor' table entry.)

So maybe 'Cursor' with capital C is not actually correct, then. (This was really just a random shot in the dark, on my part.) Maybe what is happening here is that there is no 'ATTACK_MOVE' cursor, so if we specify that then we don't get any cursor change, but if we instead just allow it to fall back to a default cursor (which looks like it might be the attack cursor, based on the "RULEUCC_Script" name), either by leaving out the 'cursor' table entry, or misspelling this with a capital C, things look much better..

@jip Maybe your reply is to cunnismeta, but, for what it is worth, I found out how to do the thing I was looking for.

Try the following, in the game console (with engineer or commander selected):

ui_lua import('/lua/ui/game/commandmode.lua').StartCommandMode("order", {name="RULEUCC_Script", AbilityName='AttackMove', TaskName='AttackMove', Cursor = 'ATTACK_MOVE'})

Interestingly, this works better than clicking the attack move button, because you actually get the correct cursor shown while in the relevant command mode, whereas there is a problem with not seeing a change of cursor when clicking the attack move button.

The lua script I am copying this from is as follows:

local function AttackMoveBehavior(self, modifiers)
    if self:IsChecked() then
        CommandMode.EndCommandMode(true)
    else
        local modeData = {
            name="RULEUCC_Script",
            AbilityName='AttackMove',
            TaskName='AttackMove',
            cursor = 'ATTACK_MOVE',
        }
        CommandMode.StartCommandMode("order", modeData)
    end
end

Note the small case 'c' in cursor, which is what makes the difference. I guess this is probably a bug..

@rowey Yeah, I know this, but I still would like to bind a hotkey.

Note that alt + right-click is different from the 'Attack move' command mode you get when you click on the 'Attack move' button, in an important way.

Whether or not alt + right-click actually does an attack move depends on what the mouse is over and the camera zoom level. If you alt + right-click over some reclaim, for example, this will often give a reclaim command instead.

This is not the case when you enter Attack move command mode by clicking the Attack move button in the UI.

I just tried setting up a hotkey for 'Attack move' (i.e. to be equivalent to pressing the leftmost command button in the UI, 'Attack move'), but it looks like this is not possible?

(In 'Orders', I can see stuff like 'Attack' and 'Move' available for mapping to hotkeys, but nothing for 'Attack move' or 'Aggressive move'.)

Anyone know why this is?

Is there some way I can work around this with a targeted UI mod?