Which parts can/should a SDK mod affect?

How to get around editing the OpenRA main project code?

Information and discussion for custom maps and mods.
Post Reply
SirCake
Posts: 393
Joined: Thu Feb 04, 2016 5:40 pm

Which parts can/should a SDK mod affect?

Post by SirCake »

Hi Guys,

I have a general question about the OpenRa project code. Currently I want to change some part of the map editor logic and which information it loads from a terrain template.
I'm editing the OpenHv project for this, but it also could be any other mod project.

So far I have managed to add new hotkeys to the editor by defining a new Logic module which gets loaded via the chrome yaml files. The code for this is completely in the mod project.
Now, for the extra information I want to include in a tile template I could edit the openRA main project file and it's class TileTemplateInfo and just add a field to it.
But that seems and feels "wrong" even though in any other software I'd just change the code. Now that raises my general question:

Which parts of the OpenRA engine code can be modified by an SDK mod? (That means by adding code to the mod project and NOT to the OpenRA.Game / Common etc.). Is it just those parts which connect via yaml to the Engine, like traits and chrome? Is there some way to identify the parts which can be changed by using only extensions?
As far as I know, I can't just re-define classes in the mod-SDK to overwrite the main project classes, right? So those are 'fixed' from my point of view. Or am I missing something?

Would you also encourage or discourage editing the main project code in an SDK mod?

Cheers,
----SirCake

Matt
Posts: 1144
Joined: Tue May 01, 2012 12:21 pm
Location: Germany

Re: Which parts can/should a SDK mod affect?

Post by Matt »

I only edited the map editor logic out of necessity, because the resource placement and saving to map works differently for OpenHV and I have a custom new map dialog which doesn't show tilesets but rather background tiles as there is only one combined tileset. Those are definitely not prime examples of mod code. Actually forking such core modules should be avoided, but the engine simply isn't flexible in that regard yet. In theory only custom file formats or game play logic (traits) including bot modules should live in mod code. The more you fork and modify the engine, the more painful it will be to update your mod.

User avatar
Graion Dilach
Posts: 277
Joined: Fri May 15, 2015 5:57 pm

Re: Which parts can/should a SDK mod affect?

Post by Graion Dilach »

SirCake wrote:
Fri Sep 25, 2020 6:29 am
Which parts of the OpenRA engine code can be modified by an SDK mod? (That means by adding code to the mod project and NOT to the OpenRA.Game / Common etc.). Is it just those parts which connect via yaml to the Engine, like traits and chrome? Is there some way to identify the parts which can be changed by using only extensions?

As far as I know, I can't just re-define classes in the mod-SDK to overwrite the main project classes, right? So those are 'fixed' from my point of view. Or am I missing something?
Somewhat. Every trait which uses interfaces to trigger their effect and acting independently can be replaced/rewritten/refactored in SDK downstream. Common/TraitInterfaces is your friend here. This is however a general point of direction, because while in a lot of cases, it looks straightforward as this, stuff can still end up hardcoded to a single Trait(OrDefault) lookup where you either hope that everything is exposed for a child class (harvester-refinery is a great example, last I checked, you could override the Refinery class in SDK at the cost of losing the text ticks). You can be lucky with some classes though - WithIdleOverlay is an example I could duplicate and change downstream into a WithIdleOverlayOnGround because it had everything exposed/available through interfaces to function.

But really, this ultimately comes down to a per-usecase basis, and something which looks fine at first sight might break in the end because of something being left in a private variable/function call between classes.
SirCake wrote:
Fri Sep 25, 2020 6:29 am
Would you also encourage or discourage editing the main project code in an SDK mod?
If you feel yourself enough knowledged to manage some breakages here and there, then sure. One of the biggest and often overlooked strengths of the ModSDK is that you can take any arbitrary commit from any repo as your "engine" - and this includes softforks. In AS, I set up a modus operandii that for stuff where I need to edit something in the engine to suit my mod idea, I try to limit this into a hook of an interface call and then let my mod code implement the interface. I prefer and do rely on duplication from engine to mod code even because if something regresses between upstream and my mod namespace, then it usually regresses into a compiler error and I have less chance to miss updating it to suit the engine update.

Personally, I never was too fond of SDK mods including actual codebase. I accept the necessity of their existence but I consider it as inconsistent design, because the SDK put clear effort to untangle the engine-mod interactions, but the first moment the modder introduces downstream code in the mod repo, this is undone in a design level. I find a softfork including the custom code + a codefree ModSDK project repo alongside more cleaner because it maintains the engine/mod separation.

I very well know this dilemma though, because it was a very long decision for me to drop the separate OpenRA.Mods.AS for a full-fletched AS/Engine project. Ultimately it was the mudded line between what's doable in downstream and what isn't which pushed me into taking the risk.

For your usecase I'd write a new interface into the engine namespace to shim out what you want to a maplayer trait in mod code and implement the chrome class in mod code as well around the maplayer. A similar way was how I implemented RA2 resource twinkling a good while ago - https://github.com/AttacqueSuperior/Eng ... ac96bd2f5e.

Post Reply