SCAR: difference between 'Instant' and regular commands

[Khorney]

We're having some issues with getting some functions to work. the 2 commands are:

Cmd_PlayerUpgrade( PlayerID playerid, UpgradeID upgradeid[, Integer count] )
Cmd_InstantPlayerUpgrade( PlayerID playerid, UpgradeID upgradeid[, Integer count] )

the 'instant' command is a singleplayer command that is flagged as a cheat function in multiplayer games and is therefore blocked.

however, simply switching to the command to the 'non-instant' version breaks the command. we can see it is still processing, we have prints after each command which are all showing up, but the upgrades arn't being given.

what do we need to change to make the upgrades be given if the instant part is removed?

we're trying to give the player tiering upgrades and unit lockout upgrades that change what units are available to build at the HQ, so its kind of critical this works

cheers

[eliw00d]

Have you tried contacting Relic? Maybe they can disable the cheat flagging for mods. Also, have you tried with and without -dev?

[Khorney]

hmmm, don't think i've tried without dev, that's a fair point. not that that would make much difference. In the SCARdoc it says not to use instant commands outside of singleplayer scenarios so i assume that's why.

[Khorney]

Yeah, double checked, sga packing and removing the -dev command line doesn't make a difference.

who would i need to contact at relic?

[Shuma]

Thunder is about the only guy i can think of that you could contact. He's the community guy iirc, or you could try contacting Pulse.R but he's tech support, not sure what he could do. Only other guys i've seen around the community often are Noun(no clue what his department is), Egon(Jeff Lydel), and Mecha, but he's on the Space Marine team, so i assume he can't do anything.

Either way i wouldn't keep my hopes up about Relic doing anything for the modding community.

[eliw00d]

@Khorney
To see what kind of support they can give? Maybe they can look into removing the cheat check for mods or -dev, or provide insight into why it is not working? They created the game, after all. It's worth a shot. If they can't help you, at least you asked.

[Khorney]

Cheers, can't hurt to ask

@eliwood, i was asking who, not why =P

[eliw00d]

@Khorney
My fault! I read that as why.

[Copernicus]

Is this thread still relevant? Using some DLL patching you can defeat this problem. I'm still working on getting the Squad-upgrade to work, but the player-upgrade functions already work using my patch (...which I will report on if there is interest in it).

[eliw00d]

That would be great.

[Copernicus]

It is actually quite simple to get the commands considered to be cheats back into the game; getting the normal, non-instant versions working seems to be more difficult. Anyway, who cares as long as the instant-ones work?

So, now for the details:

1. DoW2 has a class named World which takes care of all kinds of stuff.
2. When you execute the scar command, you issue a WorldCommand which is first checked by the World to see whether it is a cheat-command.
3. Using vft-comparison (using WoldBase from SimEngine.dll), you can easily locate World_AreCheatCommandsAllowable.
4. Patch that function to always return true, e.g. 'mov al, 1; retn'.

Cmd_InstantPlayerUpgrade and Cmd_InstantSquadUpgrade now work as expected. By the way, you need to do in-memory patching to achieve that. It would be so much better if Relic decided to give us those functions back as they did in CoH 2.501.

Regards,
-cope.

[Bonte]

What is a vft-comparision?
What are you using to decompile or view the actual assembly commands the hex codes relate to?
When you say memory patching, are you referring to run time memory injecting?

Are you saying that you have successfully edited the dll itself and allowed these commands to work.

[Copernicus]

VFTs are VirtualFunctionTables. C++ compilers use these to store information about base classes with virtual functions (duh ), it is a table of function pointers. So basically the following happens when you create an instance of a class: First, memory gets allocated and the classes' ctor gets called with that chunk of memory. It will then call the ctor of the base class which will place a pointer to its VFT at [ECX] (MS-compiler). When the base classes' ctor finishes its work, the actual class may overwrite that VFT with its own function pointers. Now suppose you have an object of class C and you are using a MS C++-compiler. When you call a virtual function of the class, the following will happen:

mov tmp, [ecx] -- get the VFT
lea tmp2, [tmp+4*x] --  get the xth entry of the VFT, may also be a mov
call tmp2 -- call the function pointed to by that entry

I hope that clarifies what a VFT is.
Every base class will store its VFT somewhere so a library's client may create subclasses. In this case we're interested in the VFT of the World class (see SimEngine.dll) which is fairly easy to find (because the DLL exports it). Now you gotta find the ctor of the subclass which actually implements the functionality of the virtual functions and compare its VFT to the World-class' VFT to figure out where the real implementation for World_AreCheatCommandsAllowable is. That's what I referred to as VFT-comparison.
I'm using the free version of IDA Pro to do all the analysis.
Memory patching refers to run time memory patching as Steam will attempt to redownload the DLLs as soon as you change them.

I have a working setup and a mod which uses all this to do some client-server based persistence stuff, yes. I wouldn't refer to it as editing the DLL but - as said - as memory patching.

-cope.

[Bonte]

Is there a way to load a new dll and "hide" the existing World_AreCheatCommandsAllowable function with a new one.... So that we don't have to "hack" the game?

[Copernicus]

No. I don't consider this to be 'hacking' btw, it is more like 'advanced modding'.

[Bonte]

yeah, but it is not desirable for mod players to have to re-download a file each time they want to play the regular game.

[Gorb]

What does this change with regards to the regular game that prevents players from playing it?

[Copernicus]

Oh, I think you misunderstood something, Bonte .
Upon starting, the game loads its files (including DLLs, executables etc.) into memory. Changing the game's memory does not change the game's files at all. All the patching is done in memory, the users normally won't even notice. So it does not have any permanent consequences at all.

-cope.

[Khorney]

totally still interested in this - so your saying we can memory patch out the cheat commands restrictions? is this something that could be abused to allow cheating in the vanilla game? or would it render the game versions different? If possible we would still like to go down the route of having our own dll that overwrote the function (i can taste the anti-virus false positives already), but we'll take what we can get.

@Gorb - our concern was if we had to have our own simengine.dll for the mod we would need to overwrite players default DOW2 one, and when they wanted to play the regular game, they would need to replace it back with the relic one. Such technical details have a tendency to scare off less IT competent players, which is less than ideal if you want a large multiplayer community

[Gorb]

Steam would also potentially harm that plan as it doesn't like launching games with any modifications to the DLLs - found this out testing memory management improvements to DoW I.

cope is, as usual, the man

[Copernicus]

If a player used the memory patch for cheating it would probably end in a sync error. Both players need to run the same script in order to avoid sync errors, so as soon as someone uses a different script (and to exploit the fact that he can now use 'cheat'-commands, he'd need to alter scripts) it will fail to sync the games. If the other player does not have the memory patch, it will lead to a sync error even if they use the same script: Cheat commands won't run for the player w/o the patch, thus desyncing the games right on execution of such a command.
You will get false-positives, though technically they aren't even false positives: The techniques used (that is, injecting a DLL and/or patching the memory of a process) are what those tools are supposed to detect. It is just that the user needs to trust you.
There are two reasons why using a custom DLL will not improve your situation:
1. DoW2 does not support custom DLLs for mods, thus you'll need to inject it in order to load it -- which of course will also look suspicious from the viewpoint of an anti-virus program.
2. The function which needs to be patched is not part of a library. Sure, there is a function World_AreCheatCommandsAllowable in the SimEngine.dll, but that is only the virtual function which the concrete implementation from DoW2.exe overwrites. (That virtual function will always return true, so instead of patching the overwriting procedure you may also patch the VFT in the DoW2 executable.)

@Gorb:
That's what I was referring to .

[Khorney]

sorry if i haven't understood this correctly, would it possible to have our own modified .exe which returns the function as true? i'm just trying to think distribution wise we would prefer to have the modifications as passive as possible so we don't need a launcher running in the background while the game is playing. that said we would need that on launch for using your .dll injector to begin with =P

[Copernicus]

Well, technically you don't need to have the launcher running all the time. You need to have some kind of tool applying the memory patch, because you can't simply take your own modified version of the executable and use that (Steam won't like that). You need to do in-memory patching.

[Khorney]

so bonte was asking specifically what lines we would need to change for that to work? he's the more technically minded so its probably more useful for him to ask but apparently that's the info we are missing

[Copernicus]

0x30A820 RVA in DoW2.exe. May change when DoW2 gets patched.

[Gorb]

I don't think you have to worry on that front.