shmocz / ra2yrcpp Goto Github PK

Originally posted by @shmocz in #8 (comment)

Because the library accepts HTTP and plain JSON.

Traditionally CnCNet has supplied a suitably patched spawner binary, hence the tests scripts operate under the assumption that the
spawner can be executed directly. Syringe-based projects (Ares, Phobos, yrpp-spawner) store the hooks/patches in a separate DLL that are applied at run-time by the Syringe executable.

Simple solution is to just replace gamemd-spawn.exe -SPAWN command with Syringe.exe gamemd.exe -SPAWN -CD. This will cause issues for debug sessions, because gdbserver launches the spawner directly. One way to address this is to attach to the process after Syringe has created it. Past experiences have shown problems when attaching, such as unusual bugs and inability to load symbols. If this proves out to be the case, a separate tool to apply the patches could be created as alternative to syringe. This could be implemented as a DLL to be loaded and initialized at the entry point.

Portions of code still use the old "yrclient" as their root namespace, and overall the namespace structure is irregular.

Solution: devise standard namespace conventions, and update the code to conform to them.

• Implement a Syringe-compatible hook that fully initializes the library. This will replace the current method where a suitable DLL loader code is patched statically to the spawner
• Convert the existing hook/callback functionality in to Syringe-compatible hooks

In the README.md:

Copy libra2yrcpp.dll and patched gamemd-spawn.exe to the CnCNet installation folder (overwriting the original gamemd-spawn.exe) ...

Where can i find the patched gamemd-spawn.exe?

Most game control related commands in commands_yr.proto are low level, and map almost directly to a call of specific underlying game function. While this simplifies the library implementation, there are several problems:

• All high-level commands, such as "move unit", "produce building", etc. must be implemented client-side as wrappers built upon these low level commands. This is the case in pyra2yr currently.
• It's not clear what the commands actually do, and how should they be issued to achieve desired operation. In practice one needs to consult pyra2yr sources.
• While there are basic checks for invalid command data, some inputs might still cause crash, and perfectly restricting all illegal inputs is difficult, as the functionality of the underlying game commands isn't totally understood. In addition, restrictions may be counterproductive for debug/test purposes.

Solution is to add high-level API, that provide human readable commands for essential game controls. The low level API should be left intact for development purposes, but could be disabled by default as a safety precaution.

Non-exhaustive list of high level API features:

Production

• Produce units and buildings
• Cancel production
• Put production on hold
• Queue/dequeue production

Unit control

• Attack
• Attack move
• Boarding into IFV, flak track, BF etc.
• Capture
• Deploy/undeploy
• Detonate with Seal/Tanya or place Ivan bomb
• Eject passengers from IFV, flak track, BF etc.
• Guard
• Move
• Repair building with engineer
• Repair units with repair IFV
• Repair units on service depot
• Select/deselect
• Scatter
• Stop
• Waypoints

Building-related controls

• Attack with defense structures
• Place building
• Repair building
• Sell buildings and walls
• Set primary building
• Set rally point

Superweapons and specials

• Chronoshift
• Launch nuke/dominator/mutator/weather storm/iron curtain
• Paratroopers
• Spy plane/psychic reveal

Other

• Ally/unally with player
• Waypoints
• Taunts
• Chat
• Place/remove beacon

This seems to occur when issuing async commands, while executing regular commands at high frequency. Upon flushing the results, an async commands gets assigned the id of another sync command.

The bug manifests itself in pyra2yr as follows:

1. Game state is fetched by executing regular command GetGameState. The command id is retrieved from the ack and used to identify the result when it's polled back in the poll loop.
2. Async command, such as PlaceQuery is executed.
3. When state retrieval of step 1 happens, the command result indicated by the ack contains actually the PlaceQuery result.

This was assumed to be due to race condition addressed in a19197f, but the problem still persists, indicating a deeper issue.

          By the way, i modified the `python3` to `python` in the patch command. Command `python3` doesn't work for me.

ra2yrcpp/scripts/run-gamemd.py

Lines 365 to 372 in 0b295c7

	return [
	"python3",
	"./scripts/patch_gamemd.py",
	"-s",
	".p_text:0x00004d66:0x00b7a000:0x0047e000",
	"-s",
	".text:0x003df38d:0x00401000:0x00001000",
	]

Originally posted by @1099255210 in #8 (comment)