Fix for unit flag that prevents setting dest. marker with context menus disabled

[r59]

Hello everybody.

I come upon a minor but still annoying bug during my latest MP games with the guys at the KS group.
In HITS mode, if you raise the camera a little above ground level and right click on the terrain to lay down the destination marker for the selected unit, you'll have good chances that flags will receive a positive hit test for a significant portion of its horizon.
Even if the context menu option is set to disabled, the code in charge of handling that, will improperly reject any further processing of the given click event.
Effectively preventing the unit dest. marker code to get its chance to run.

So, yesterday I spent a couple of hours tracking down the root of the issue in the executable.
I was able to isolate it, luckly, and I'd like to share a fix to anyone interested.

Here's my tentative recreation of the C++ code of the guilty function (I really can't be more exact than this, without taking a look at the sources):

Code: Select all

bool ProcessMouseRightButtonPressOnSelectedUnit(int x, int y, bool bReleased)
{
    if (theUnits.selectedUnit < 0) { return false; }
    const auto selectedUnit = theUnits.unitList[theUnits.selectedUnit];
    if (selectedUnit == nullptr) { return false; }
    if (PRTerrain == nullptr) { return false; }
    bool ret = false;    
    if (selectedUnit != nullptr) {
        ret = true;
        std::uint64_t o = UINT64_C(0);
        if (selectedUnit->flagHitTest(x, y, &o)) {
            if (bReleased) {
                if (localPlayerOOBLink.side != 0 && selectedUnit->OOBLink.side == localPlayerOOBLink.side) {
                    SComm comm;
                    if (bCampaignMode) {
                        comm.Type = eComLoadLayout;
                        strcpy_s(comm.Param1, "SBCOob");
                    }
                    else {
                        // BUG...
                        if (selectedUnit->MyGuys()) {
                            if (optHideMenus.Value == false) {
                                comm.Type = eComLoadMenu;
                                comm.Val = selectedUnit->Marching() ? MENU_MARCH : (selectedUnit->HasTarget() ? MENU_TARGETS : MENU_STAND);
                            }
                        }
                        return true;
                        // ...BUG
                    }
                    theApp.AddComm(&comm, 1);
                }
            }
        }
    }
    return ret;
}

This is called from two places in the game:
1) CNSDBaseMgr::onMousePress;
2) CMainWnd::ProcessMouseInput => ProcessMouseRightButtonRelease.
In both cases, if our function is going to return true (and, as you can see, it does also if #opthidemenu == true), this will cause troubles.
Respectively stopping the entering in the unit destination marker mode and the firing of the ending eComMoveDir/eComAddPath/etc. commands.

My proposed fix:

Code: Select all

...
else { // !bCampaignMode
    if (selectedUnit->MyGuys() && optHideMenus.Value == false) {
        comm.Type = eComLoadMenu;
        comm.Val = selectedUnit->Marching() ? MENU_MARCH : (selectedUnit->HasTarget() ? MENU_TARGETS : MENU_STAND);
    }
    else { return false; }
}
theApp.AddComm(&comm, 1);
...

I tested it quickly and I can see the destination marker working fine also behind fully or partially occluding translucent flags now.

We'd been told the game wlll receive no more patching to get rid of these "imperfections" (they're clearly marginals, but still quite a lot).

1) As we're talking about changing just a couple of bytes here (literally);
2) sharing any exe file is out of question, for what concern me.
I ask to the dev-team to let me know if sharing step-by-step instruction to do it on your own through an hex editor and/or within the AI DLL code (or a difference file?), is gonna create any sort of embarrassment or, even worse, measures are going to be taken towards my position in the forum.
I'd love to avoid both situations, if possible.
Because I can take the blame to enjoy your games still very much. I sure do. But not being considered in bad faith, frankly.

Thanks for your patience and understanding.

[Biondo]

Ciao r59

some times ago I made a simple fix to this issue to permit to play at 2 as camera distance from your character; basically I raised a bit the flag of the commander and of the unit too (they blocking your view if you march together with them).

Probably you can use a lower value if you only play MP because the flag is already raised a bit respect the single player. If you play singleplayer too, I suggest to keep more or less my values.

Here's the link to the mod

http://www.norbsoftdev.net/forum/waterl ... 9-hits-mod

If I remember correctly you can change gfxpack value only to your mod version without creating problems to MP games but it's better to test it

Ciao

[r59]

Ciao Biondo.
Yes, Grog already told me about your attempt to workaround this on the KS group forums.
Well thought out, indeed!
Anyway, it's a bit too specific for my taste...
Because it should rely upon the user camera distance setting and the flags dimensions of the mod being known before hand.
As a side (and totally surprising) effect, solving the problem at the root, *seems* (I need to test more thoroughly, however) to solve another one that happened me a few times: unresponsive middle/wheel-button dragging issue while any move (and possibly other) command is acknowledged in MP (e.g. camera rotation denied until the marker is finally laid out on terrain).
Please consider I may have some more of these genre of contributions in the works as well.
So my request for a conditional green light to allow the game not falling totally abandoned with regards to the exe, stands.
But thanks for your prompt and "proactive" reply. I very much appreciated it.

[con20or]

I find when terrain etc means the flag is blocking my desired click destination - a quick tap on 'A' or 'D' lets me pan the view left or right, even with a very short camera limit like 2 - the general flag is hidden then and it usually sorts this?

Its a pain, but regardless its great to see a member of the community with these skills suggesting workarounds so ignore if I'm wrong - welcome r59

[r59]

Hey con20or!
Thanks for your words, first of all.
You might be right of course.
Especially on open terrains, you'll always find a way to move slightly and avoid the issue.
Last week, however, in a MP HITS game (I took a brigade), I ended up in such a situation, heavily pressured by hordes of pesky russians, that I should tell you.
Basically I had a stream/bridge at my shoulders, line infantry rushing down on my right flank from the upper part of a town, jaegers/artillery in front of me and upslope (hidden behind a line of trees, otherwise I would have not crossed) and my left flank covered by an hugeee wheat field infested by invisible evil cossacks (paid a whole battalion to them and their abrupt sorties).
My troops were crammed in little space, stuck under artillery fire (often in square formation) and, for several reasons (I assume my faults for ending up in that murderous "cage", of course ), I really had a bad time to sort out the situation and control them properly.
The bug we're talking about here made me impossible on few occasions to assign destinations to my selected subordinates along any direction intersecting their flag.
Big or small, but it wasn't just mine...
Their overall contribution in pixels, in such a situation, wasn't irrelevant.
Admittedly, these virtual scars dictated the agenda for my last Sunday afternoon, hence.
Cheers!

P.S. I'm going to wait a few days for any response from Norb or Jim, before posting the 2 required opcodes and offsets to implement my solution.

[mitra76]

Ciao R59

I don't think is a great idea teach how to use a hex editor in order to change the exe code on the game forum, also if is for correct a problem. This is a commercial product with a contract with a distributor.

Please, in order to avoid any form of problem don't post them in absence of any Norb or Jim communication.

Davide

[r59]

I obey ("obbedisco")!
It seems fair to me to wait.
Possibly runtime memory patching from the AI dll could be the safest way.
But let's see how things unfold.
Ciao.