trouble with UnitDef.h

[sanderbakkes]

i extended the UnitDef structure with an "int value;". that int is initialised in CUnitDefHandler::CUnitDefHandler(void) of UnitDefHandler.cpp. it compiles and works nicely for my purpose.

yet, when using other already pre-compiled AI .dlls, these AI's are not working properly anymore. KAI crashes instantly, and AAI is idling.

anyone who has got a clue to why a new UnitDef is not accepted?
i compile in VStudio.7 an use default struct-alignment.

[Tobi]

Because CUnitDef is passed around to AIs, ie. modifying it in any way breaks ABI compatibility, so you need to recompile AIs.

[sanderbakkes]

makes sense, but still i have to extend that structure

anyone knowns how to hack into the UnitDef without breaking compatibility?

[KDR_11k]

There is none. You must recompile the AIs.

[sanderbakkes]

AF was so kind to suggest the following. perhaps it will help you too:

The problem ehre is not with howto extend UnitDef but the very action fo extending it.

Instead take a different approach and create a class such as for example

Code: Select all

class CUnitDefinition{
public:
    CUnitDefinition(UnitDef* u){
        ud = u;
    }
    virtual ~CUnitDefinition(){}
    UnitDef* GetEngineDef(){
        return ud;
    }
    float GetValue(std::string value, float default=1.0f){
        if(values.find(value) != values.end())
            return fvalues[value];
        else
            return default;
    }
    void SetValue(std::string value, float number){
        fvalues[value] = number;
    }
    std::map<std::string,float>& GetFloatValues(){
        return &fvalues;
private:
    const UnitDef* ud;
    std::map<std::string,float> fvalues;
};

That class will store arbitrary float values and your UnitDef pointer, and thus repeat the function and map container for integers strings etc you need to add, or just add member functions for single objects..... If you need to extend UnitDef just extend this class instead.

[KDR_11k]

The devs would kill you for adding an unnecessary class. Spring needs less hacky code, not more.

[Dragon45]

Why not just recompile all AIs? I don't see the problem; if the extension is significant it'll have to be added in next spring ver with new AIs anyhway; if its not significant, noone will care what your special AI modification is...

[sanderbakkes]

Why not just recompile all AIs? I don't see the problem; if the extension is significant it'll have to be added in next spring ver with new AIs anyhway; if its not significant, noone will care what your special AI modification is...

let me then please ask the DEVs to provide more 'space' in the UnitDef. i can only imagine that all AI developers have a need for some redundant properties they can use for their own implementation.

i for one would love to implement a scoring function, and it makes sense to include a unit.weight for that in the UnitDef structure (though other means are possible). i am confident similar scenarios apply to other AI developers.

[Tobi]

why can't you just use something like

Code: Select all

class CExtendedUnitDef {
  CUnitDef* ud;
  float weight;
  int aiclass;
  // etc.
};

in your AI?

or even

Code: Select all

class CExtendedUnitDef : public CUnitDef {
  float weight;
  int aiclass;
};

if you don't mind copying the entire unitdef (as opposed to just storing a pointer to it).

[krogothe]

why can't you just use something like

Code: Select all

class CExtendedUnitDef {
  CUnitDef* ud;
  float weight;
  int aiclass;
  // etc.
};

in your AI?

Thats what i did, and what i bet the other AIs do too (in one shape or another) theres no need to change the interface to store additional unit info...

[KDR_11k]

I'm not sure he's writing an AI, perhaps he's implementing a new feature into the engine itself?