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

No idea, I have not studied zones yet, focused mostly on RMG_Mapitem which hold data of all items, access, land etc.

Speaking of which, found an interesting bit in RMG_MapItem->packedGroundData2.
Bit 28 (0x08000000) is set when a piece of ground is blocked by an object.
This bit is set when placing objects on the map based on its mask.

You can see the conditional check at 0x53249E and the bit being switched at 0x5324B6. This may be related to obstacle mask presence?

 

If it is always set, very few roads are able to be placed.

 

If it is never set, roads go through obstacles in straight lines!

 

Besides, it would be very useful to know when generated Monster is a guard of connection between zones (immediately to write to some array Monster index or Mosters x-y-z). As far as see in my old paper notebook : sub_00542570 is related to such Monsters.

More precisely, most important information from Monster generation - between which zones Monster is generated. This information can be obtained in post-processing, but for many cases (when connection Monsters close to each other) such information obtained at Monster generation stage would be quite useful.

It seems, both arguments for sub_00542570 - a2 and a3 - are connected zones.

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

char __thiscall sub_00542570(int this, int a2, int a3)


I believe this is the correct function prototype.

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

char __thiscall sub_00542570(_RMGStruct_ *this, _RMGGenZone_ *a2, RMG_ZoneConnection *a3)

Also tinkered a bit with monster generation sub (RMG_MonsterGeneration_00541010) and identified this
RMG_MonsterGenerationObjectGuards_00546BD0 ... so all monsters generated by this function are meant to guard objects.

It could be possible to make a global list of these creatures and then in post-processing check if any of these monsters block road, then attempt to move them.
Simplest fix available at the moment without more reversing.

Also:
RMG_MonsterGenerationMinesGuards_00545E80
RMG_MonsterGenerationZoneBlocks_00541630
RMG_MonsterGenerationGates_MonolithsBlocks_005431D0
ED. address typo

There is one more to generate monsters, sub_00541FC0, but I don't seem to have written down what this one does.
ED: seems to be for shipyards

RoseKavalier писал(а):

RMG_MonsterGenerationZoneBlocks_00541630
RMG_MonsterGenerationGates_MonolithsBlocks_00541630

? (the same address for 2 proc)


What about sub_005431D0 ?

Unfortunately, I don't see in procedures check for object type (for example, 43-45 - monolith, 103 - UG gate, 87 - shipyard) or writing corresponding object type.

Interesting piece of code in RMG_00543730:

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

          if ( sub_00541630(v3, v101, k, (int)&v84, (int)&v91) )
          {
            v37 = l;
            *(_BYTE *)(v36 + 10) = 1;
            *(_BYTE *)(v37 + 10) = 1;
          }
          else
          {
            if ( sub_00541FC0(v3, v35, v36) )
            {
              *(_BYTE *)(v36 + 10) = 1;
            }
            else
            {
              if ( *(_DWORD *)(v95 + 12) != 8 )
              {
                if ( sub_00542570(v3, v35, v36) )
                {
                  v38 = l;
                  *(_BYTE *)(v36 + 10) = 1;
                  *(_BYTE *)(v38 + 10) = 1;
                }
              }
            }
          }


and below:

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

if ( sub_00541FC0(v3, v101, v63) )
            {
              *(_BYTE *)(v63 + 10) = 1;
            }
            else
            {
              if ( *(_DWORD *)(v95 + 12) != 8 )
              {
                sub_005431D0(v3, v101, v63, (_DlgItem_BUG_)v96);
...


RoseKavalier писал(а):

It could be possible to make a global list of these creatures and then in post-processing check if any of these monsters block road, then attempt to move them.

There is alternative way - refill zone if it do not satisfy some criteria of post-processing.
I'm not sure that it is possible simply to improve some NWC RMG algorithms, some of these are incorrect by nature. We should use our advantage over NWC - more CPU resources (though not infinite, of course). So, some things can be setup by way of trial and error.

Here in RMG_00549E20_ChooseTemplateAndGenerate each zone can be refilled (before filling one should make backup of _RMGStruct_, also it is possible one should change rand seed, may be not):

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

    while ( 1 )
    {
      v41 = v2->GenZones;
      v50 = v38;
      if ( !v41 )
        break;
      if ( v38 >= (v2->GenZonesEnd - (_DWORD)v41) >> 2 )
        break;
      RMG_00547850(v2, v41[v38]);
      v42 = v2->Progress;
      if ( v42 )
      {
        v43 = v2->GenZones;
        if ( v43 )
          v44 = (v2->GenZonesEnd - (_DWORD)v43) >> 2;
        else
          v44 = 0;
        (*(void (__fastcall **)(int, unsigned int))(*(_DWORD *)v42 + 8))(v42, 0x1AF4u % v44);
        v38 = v50;
      }
      ++v38;
    }


Цитата:

It could be possible to make a global list of these creatures and then in post-processing check if any of these monsters block road, then attempt to move them.
Simplest fix available at the moment without more reversing.

There is no problem to get monsters. Code at 0x4FDF64 doing it well.
The problem is to get the passability of the tile (x,y,z).

@Ben80
It was typo on my part, corrected in post as:
RMG_MonsterGenerationGates_MonolithsBlocks_005431D0

How I could confirm this is simple:
I skipped the procedure for all but one call at a time and noted where monsters were placed.
The check for item type is done before these functions, however if you look carefully you can see references to these object types in the various functions.
e.g. 0x54320D looks up Monolith-2way data.

 

This is my current disassembly at code you specified:

 

@as239
There are advantages at not patching at 0x4FDF64
1 - this hook activates for all maps, even non-randoms.
2 - the hook will be called every time you hit 'Restart Scenario' instead of a single time during map creation
3- there is no way to know what job is a monster at (x,y,z)

We can get the same information from during RMG creation and even better because you can know that a monster at (x,y,z) is a zone guard or that (a,b,c) is an object guard.

From the current steps in reversing RMG, there is already enough information to do a much better job that 0x4FDF64 hook.
Current capacity would allow:
1) let RMG complete its task
2) identify all monsters guarding objects during RMG creation
3) inspect where these monsters object-guarding monsters are
& if they are on road - try to move them.

Good arguments.
Unfortunately I cann't do anything with it without samples.

I'm still ironing out some details in the structures before I can give a good example.
As I am travelling, it will have to wait a bit(