Как создать плагин для HD мода

I need the place where RMG decides from which town to which town write the road.
Cause one of the most frequent bug at JC its wrong roads:

Well, RoseKavalier, you gave very important data - anyway sooner or later it will be used to produce useful code.

NOTE: Fixed previous post, I did not do careful arithmetic of negatives while shifting, bitfields should be good now.

 Demo

First digit is type, second digit is sprite #

@Ben80

I don't know the full contents of RMG_GroundTileData as I looked at sub_00532D60 which writes ground data to h3m file. Further disassembly is needed to see if there is useful data such as 'blocked' or 'entrance' etc.
What I did do was simple, as I said h3m format is well mapped with mirroring info here.

I only noticed references to RMG_GroundTileData when playing around a bit with breakpoints yesterday.

Finding objects can be done through positions vector. I have mostly finished my H3 header files and only use them nowadays so I don't have equivalent in homm3.h style but you should be able to find the matching structures in IDA database.
When SoD_SP 1.16 is ready to release (testing phase), they will be available to use.
_RMGStruct_ +EC4

Код: Выделить всё

// * +EC4
H3Vector<RMG_Object*> positions;


These structure format is very similar to h3m format in mapeditor, example.

Код: Выделить всё

struct RMG_Object
{
   // * +0
   h3func *vTable;
   // * +4
   RMG_ObjectPropsRef *properties;
   // * +8
   INT32 x;
   // * +C
   INT32 y;
   // * +10
   INT32 z;
   UINT8 _f_14[8];
};


Код: Выделить всё

struct RMG_ObjectPropsRef
{
   // * +0
   RMG_ObjectProps *prototype;
   UINT32 _f_4;
   // * +8
   UINT32 refCount;
   // * +C
   INT32 prototypeIndex;
};


Код: Выделить всё

struct RMG_ObjectProps // size 4C
{
   // * +0
   INT32 defNumber;
   // * +4
   H3Bitfield passable[2];
   // * +C
   H3Bitfield enterable[2];
   // * +14
   H3Bitfield land;
   // * +18
   H3Bitfield landpage;
   // * +1C
   INT32 type;
   // * +20
   INT32 subtype;
   // * +24
   INT32 page;
   // * +28
   BOOL8 flat;
   // * +29
   BOOL8 HasEntrance;
   UINT8 f_2A[2];
   // * +2C
   INT32 EnterX;
   // * +30
   INT32 EnterY;
   // * +34
   INT32 width;
   // * +38
   INT32 height;
   // * +3C
   H3Bitfield maskobject[2];
   // * +44
   H3Bitfield maskshadow[2];
};


So from RMG_Object *positions vector you can use RMG_ObjectProps *properties directly.

@as239
Yes that's the real question, I do not know yet - most of this mapping is from simple breakpoints and no disassembly. To answer this one has to decipher the parents of sub_005328A0, for example sub_004FAA50. It is the one that determines the coordinates to write a road, call to write road type via virtual table occurs at 0x4FAACE.

Also I looked into monster creation, it is already somehow mapped in IDA as RMG_00541010_MonsterGeneration.
If you want fun, change JS to JMP at 0x5410D4 and have no monsters at all on map)
Unfortunately, road generation occurs after monster generation so there is no easy way here to check if monster is being placed at a future road spot.

as239 писал(а):

I need the place where RMG decides from which town to which town write the road.
Cause one of the most frequent bug at JC its wrong roads:

Код: Выделить всё

// * +14B0
H3Vector<H3Coordinates> roadTargets;

Targets (x, y, z) that need to be connected to road network.
char __thiscall RMG_Road_00548530(_RMGStruct_ *this, int x, int y, int z, int roadType) ...
This sub reads these points to x, y, z and creates a road network from this point on.
How that works exactly though, I don't know. Good luck I guess

Again, very very interesting.
It would be very interesting if one can connect only towns with wood and ore mines (as we frequently see on NWC fixed maps), not towns with each other. However as far as I understand you say only about 1 general road network. Indeed such network must connect towns.

Or my idea is possible, how you think ?
(for example, run building procedure many times with different H3Vector<H3Coordinates> roadTargets)

I need HiHook syntax for RMG_Road_00548530.

@as239
I already gave function prototype in last post:

Код: Выделить всё

char __thiscall RMG_Road_00548530(_RMGStruct_ *this, int x, int y, int z, int roadType) ...

It's thiscall__ with 5 arguments, returns 1-byte _bool8_ or simply char.

You could SPLICE_ at 0x548530 or CALL_ it from 0x5488F8.
A better understanding of parent function is needed because hook on either of these will be called several times.
In any case you can make a hook there to see where roads are being started.

 

@ben80
So long as you know (x, y, z) coordinates to add it should not be difficult. However for practicality it would be better to add the coordinates directly when mines are generated imo, however that requires more reversing...
I sent this random road to nowehere:

 

Some of these things should be in this area:

 

RoseKavalier писал(а):

Some of these things should be in this area:

 

I'm was not digged into standart book algorithms such pathfinding or something like that from graph theory. However, in principle, I'm prepared to solve pathfinding tasks using some my own primitive algorithms.

There is one question. I'm failed to use some <Lists> structures. For example:

Код: Выделить всё

_ZoneSettings_* zone;
int x = zone->connections[i].value;


I suspect it is due to "->", because of o_GameMgr->Map.Objects[i] works good (here between whole structure and <List> we see ".").
May be this is structure alignment issue (I have set "Structure Member Alighment" to 1 byte) ?

So, I have to use non-estetic constructions, like that:

Код: Выделить всё

_ZoneConnection_* zc = (_ZoneConnection_*)(*(int*)(addr2 + 200) + i*28);
int x = zc->value;


_List_ is essentially a Vector, unlike what its name implies.
To get i-th element you must use a reference to list->Data like so:

Код: Выделить всё

auto conn = &zone->connections.Data[i];


If you wish to use this type of code directly:

Код: Выделить всё

auto conn2 = &zone->connections[i];


Then you can add operator[] overload in _List_.

sub_547D70 is very interesting for pathfinding.
There is a switch() at 0x547F05 that checks for object at current tile - monoliths, subterranean gates. It looks to me like this is mapping out movement costs but I need more reversing to understand what is what.

Код: Выделить всё

 switch ( objectType )
      {
        case MONOLITH_ONE_WAY_ENTRANCE:
        case MONOLITH_ONE_WAY_EXIT:
                ...
        case MONOLITH_TWO_WAY:
                ...
        case SUBTERRANEAN_GATE:
                ...


I haven't _RMGStruct_