Fix - get_zone(xx) failed

StarTrader

Finally a fix! ;D

Please see this for full coverage:- http://forums.seriouszone.com/showthread.php?p=908369#post908369

;D

Bejaymac

ST could you post that fix here, atleast until Louva gets the SeriousZone back online.

StarTrader

Just saw your reply BJ, sorry.

Here it is…

If you get messages like these in FLSpit/FLSpew when browsing the mission board…

WARNING: get_zone(31) failed
WARNING: get_zone(31) failed
WARNING: get_zone(47) failed
WARNING: get_zone(47) failed
WARNING: get_zone(39) failed
WARNING: get_zone(39) failed

(or if you see “Go to Sector NN” in the mission description, you will also be getting these warnings but may not have spotted them)…

The fix (finally after many hair-pulling sessions) is simple…

You need to give a name to your pop zones! FL is not trying to get a vignette zone number, it is trying to get the name for the place where vignette zone xx is located! e.g. it’s looking for something like “Pittsburgh Debris Field”!

All you need to do is put in an ids_name = xxxxxx line in your pop zone definition.

Here’s an example:-

[Zone]
nickname = Zone_Dw03_pop_ambient_01
ids_name = 261400
pos = -19400, 0, -27500
rotate = 0, 0, 0
shape = ELLIPSOID
size = 40000, 20000, 40000
comment = Ambient Pop
sort = 50
toughness = 14
density = 10
repop_time = 10
max_battle_size = 6
pop_type = Background
relief_time = 10
population_additive = true
faction_weight = li_lsf_grp, 1
faction_weight = fc_lr_grp, 1
encounter = area_scout, 14, 1.000000
faction = li_lsf_grp, 0.400000
faction = fc_lr_grp, 0.400000

But there is a catch!

Our fellow modder DwnUndr has revealed a sequence of offsets that should be followed for mission pop zone names to show correctly on the mission board - see his topic at http://freelancercommunity.net/viewtopic.php?t=355

Here’s an example:-

The zone name must be located in Nameresources.dll, between 261208 and 261407. Obviously don’t overwrite other entries which are used in your modded FL!

Let’s say your pop zone is named Zone_Dw03_pop_ambient_01, and we want to call it “Samson Debris Field”.

So then let’s use entry 261400 (nameresources.dll)

261400 = Samson Debris Field

The required offset entries are in offerbriberesources.dll…

331873 (261400 + 70473) = Samson Debris Field
332073 (331873 + 200) = the Samson Debris Field
332273 (332073 + 200) = blank
332473 (332073 + 200) = blank
332673 (332073 + 200) = blank
332873 (332073 + 200) = blank
333073 (332073 + 200) = blank
333273 (332073 + 200) = blank
333473 (332073 + 200) = blank
333673 (332073 + 200) = blank

NOTE - All entries above and including 332081 in offerbriberesources.dll must be kept blank! The tables exist in plain FL, up to table 372, but they are empty. They are listed in DATA\INTERFACE\knowledgemap.ini for zones and other entries, so they should be kept as they are.

To complete… Once you have made these entries, make the following entries into the first section of DATA\INTERFACE\knowledgemap.ini as follows:-

Map = 261400, Zone_Dw03_pop_ambient_01, 33
Map = 331873, Zone_Dw03_pop_ambient_01, 33
Map = 332073, Zone_Dw03_pop_ambient_01, 33
Map = 332273, Zone_Dw03_pop_ambient_01, 33
Map = 332473, Zone_Dw03_pop_ambient_01, 33
Map = 332673, Zone_Dw03_pop_ambient_01, 33
Map = 332873, Zone_Dw03_pop_ambient_01, 33
Map = 333073, Zone_Dw03_pop_ambient_01, 33
Map = 333273, Zone_Dw03_pop_ambient_01, 33
Map = 333473, Zone_Dw03_pop_ambient_01, 33
Map = 333673, Zone_Dw03_pop_ambient_01, 33

One more note:-
331873 (261400 + 70473) = Samson Debris Field
332073 (331873 + 200) = the Samson Debris Field

If your field is named “Zone 21” or “Samson’s Debris Field”, then the second entry should not have the word "the " in front, because the mission would then read “Go to the Zone 21…” instead of “Go to Zone 21…” and “Go to the Samson’s Debris Field” instead of “Go to Samson’s Debris Field…”.

Just being grammatical! Heheheh.

Thaddeus

Nice tut for knowledgemap.ini, but its not the complete answer. I’ve had my zones named for years now and I still get this message even in vanilla systems. It is generated by the job board and the relationship to the vignette zone but no ammount of editing seems to change it. Anybody else have any ideas?

StarTrader

Many of the vanilla systems in plain FL give this problem for the same reason, including New York.

This was the last find that ultimately cured this problem after everything else was fixed.

You must also ensure that:-

1. Your vignette zones are entirely within the named zone

2. the vignette zone centres must be within 34000 km of the issuing base or within 34000 km of the end of a tradelane leading from the base, presumably the entrance to the tradelane must also be within 34000 of the base but I did not investigate this.

3. There must be at least the same number of vignette zones as the max missions set in mbases.ini for that base.

adoxa

I “fixed” it by patching Freelancer to remove the message altogether; the same for Used Hostile Pick Assistance and couldnt find material 163618903. However, Disconnecting equipment with FATE_UNKNOWN, using FATE_DISAPPEAR, I did actually manage to fix, since it was an actual bug - FL didn’t recognise the FATE_LOOT type.

BTW, the zone number is the sector coordinate. If the zone is 42 for example, that’s Sector 3E (or maybe it was 5C, it’s been a while).

StarTrader

Good news adoxa - what & how did you patch exactly please?

adoxa

Probably easiest just to post the whole thing. This is part of my upcoming patch, hence the name (JFLP = Jason’s Freelancer Patch).

/*
  jflp.c - Patch Freelancer to remove some FLSpew warnings.

  Jason Hood, 31 May, 2009.

  This patch removes the following spew warnings:
  * couldnt find material 163618903
    Generated when a waypoint is selected.  I was unable to fix it, so now I
    just remove the warning.
  * get_zone(N) failed
    Generated when a job sector has no name, which is quite frequently.
  * Disconnecting equipment with FATE_UNKNOWN, using FATE_DISAPPEAR
    Generated when a wreck drops its weapons.  This is a bug in Freelancer.exe,
    since it doesn't detect the "fate_loot" type.
  * Used Hostile Pick Assistance
    Not sure exactly when this is generated (or even why), but it's something
    to do with targetting enemy fighters.

  2 June, 2009:
  * replace the line number of the "Deform::start_aim" notice with the
    timestamp of the event (in milliseconds; it also replaces the string with
    "(null)", in order to fit the new code).

  Build (VC 6):
    rc jflp.rc
    cl /nologo /Fepath\to\freelancer\exe\jflp.dll jflp.c /link /dll /subsystem:windows /machine:ix86 jflp.res
*/

#define WIN32_LEAN_AND_MEAN
#include <windows.h>void Patch_Common( void )
{
  #define ADDR_VERS10 (0x62c1485 - 0x6260000 + common)
  #define ADDR_FATE10 (0x6293727 - 0x6260000 + common)
  #define ADDR_ZONE10 (0x633c26c - 0x6260000 + common)

  #define ADDR_VERS11 (0x62c14e5 - 0x6260000 + common)
  #define ADDR_FATE11 (0x6293487 - 0x6260000 + common)
  #define ADDR_ZONE11 (0x633c34c - 0x6260000 + common)

  DWORD dummy;

  PBYTE addr_fate, addr_zone;

  PBYTE common = (PBYTE)GetModuleHandle( "common.dll" );
  if (*(DWORD*)ADDR_VERS11 == 0x639F3CC)
  {
    addr_fate = ADDR_FATE11;
    addr_zone = ADDR_ZONE11;
  }
  else if (*(DWORD*)ADDR_VERS10 == 0x639F39C)
  {
    addr_fate = ADDR_FATE10;
    addr_zone = ADDR_ZONE10;
  }
  else
    return;

  // Change the fate test to below 3 is bad, below/equal 5 is good.
  VirtualProtect( addr_fate, 6, PAGE_EXECUTE_READWRITE, &dummy );
  memcpy( addr_fate, "\x72\x05\x83\xf8\x05\x76", 6 );

  // Skip the zone message altogether.
  VirtualProtect( addr_zone, 1, PAGE_EXECUTE_READWRITE, &dummy );
  *addr_zone = 0x28;
}

__declspec(naked)
void RendComp_Patch( void )
{
  __asm mov edx, [ebp]
  __asm cmp edx, 163618903
  __asm lea eax, [esp+28]
  __asm ret
}

void Patch_RendComp( void )
{
  #define ADDR_MATERIAL (0x6c318be - 0x6c20000 + rendcomp)

  DWORD dummy;

  PBYTE rendcomp = (PBYTE)GetModuleHandle( "rendcomp.dll" );
  if (*ADDR_MATERIAL == 0x8b)
  {
    // Add in a test for the ignored material.
    static BYTE code[] =
    {
      0xE8,0x00,0x00,0x00,0x00, 	// call RendComp_Patch
      0x74,0x2D,			// jz	skip_log
      0x52
    };
    *(DWORD*)(code+1) = (PBYTE)RendComp_Patch - ADDR_MATERIAL - 5;
    VirtualProtect( ADDR_MATERIAL, sizeof(code), PAGE_EXECUTE_READWRITE, &dummy );
    memcpy( ADDR_MATERIAL, code, sizeof(code) );
  }
}

void Patch( void )
{
  #define ADDR_ASSIST (PBYTE)0x4ede00
  #define ADDR_DEFORM (PBYTE)0x452648

  DWORD dummy;

  if (*ADDR_ASSIST == 0x68)
  {
    // Skip the "Used Hostile Pick Assistance" message.
    VirtualProtect( ADDR_ASSIST, 2, PAGE_EXECUTE_READWRITE, &dummy );
    (ADDR_ASSIST)[0] = 0xeb;
    (ADDR_ASSIST)[1] = 0x26;

    VirtualProtect( ADDR_DEFORM, 10, PAGE_EXECUTE_READWRITE, &dummy );
    memcpy( ADDR_DEFORM, "\x6a\x00"             // push 0 ;"(null)"
			 "\x8b\x76\x04"         // mov  esi, [esi+4]
			 "\xff\x76\x08"         // push dword[esi+8]
			 "\x90\x90", 10 );      // nop/nop
  }

  Patch_Common();
  Patch_RendComp();
}

BOOL WINAPI DllMain( HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved )
{
  if (fdwReason == DLL_PROCESS_ATTACH)
    Patch();

  return TRUE;
}</windows.h>