Crash Offsets

robocop wrote:
Where would that info be added to the NPCs characteristics? It seems to be related to the added NPCs in the system (Order and DSE in Omicron Minor) and not elsewhere in the universe.

Looking at the decoded wav files, only system St01 has a refer line, and there are no St base lines at all.

DwnUndr wrote:
Assuming these are new bases and systems?

http://freelancercommunity.net/viewtopic.php?f=5&t=316

Good God Almighty…

I might’ve isolated that content.dll error ( 0x47bc4 ) to a bad encounter. Specifically, I had neglected to add a formation to the factionprop of the faction spawning added armored transport spawns. Once I added the formation to the factionprop, the content error has not reappeared

I have strange crashes at content.dll 0005ccd4 sometimes when docking to tradelane.

Anyone experienced this?

Looks to be a missing/mistyped formation.

Getting a strange ctd at offset 0000109c in engclass.dll

engclass is ver 2.0 for multicruise

ctd is reproduce-able by either scanning npcs/players in space or opening the personal cargo window on the hud.

only seems to affect capships. currently testing the rh_cruiser and battleship (you have to love turret zoom for this) tested the engine on an eagle and it worked fine

adoxa wrote:
Looks to be a missing/mistyped formation.

Maybe. I have changed TTX of vanilla ships, have made pilotable Lifter and Repair ship from vanilla, have added some new ships. And all

SDK - yours, JFLP ))
FLScan 1.3 says 0 errors

Mystic…

@Thaddeus: v2.01.

@Helloween: It really looks like it wants a formation - it’s the function to test if the position is for NPC or player. It’s crashing because it can’t read the position data (if you look at the report, ECX should be 0). It appears neither FLScan nor FLEC pick up this error. Here’s a perl script to test it (run it in DATA\MISSIONS).

open(FORMATIONS, 'formations.ini') || die('no formations.ini');
while (<formations>)
{
  if (/^nickname = (.*)/)
  {
    $formations{$1} = 1;
  }
}
close(FORMATIONS);

open(PROPS, 'faction_prop.ini') || die('no faction_prop.ini');
while (<props>)
{
  ++$line;
  if (/^formation = .*?, (.*)/)
  {
    if (!$formations{$1})
    {
      print "Missing formation '$1' at line $line.\n";
    }
  }
}</props></formations> 

Thx Adoxa! Now i know where to dig )

adoxa wrote:
@Thaddeus: v2.01.

Thanks problem is cleared. Gracias amigo

adoxa wrote:
Here’s a new plugin for the content 124bd problem. This one only logs on a bad address (also eliminating the crash), so you should have no problem on a running server. It will generate EXE\EngBase-0124BD-bad.txt, logging the values of the previous call.

2011-06-30 02:29:37.481: Common.0630E681
Bad address = CDCDCDCD
Previous call:
cmp -> equipment\models\weapons\ku_hornet_launcher.cmp
part -> k_hornetlauncher_base_lod1020829120522.3db

2011-06-30 02:45:49.832: Common.0630E681
Bad address = CDCDCDCD
Previous call:
part -> equipment\models\torpedoes\ge_torpedo.3db

2011-06-30 21:56:49.318: Common.0630E681
Bad address = CDCDCDCD
Previous call:
cmp -> equipment\models\turret\li_turret03.cmp
part -> base021119202809.3db

2011-07-01 21:59:10.152: Common.0630E681
Bad address = CDCDCDCD
Previous call:
cmp -> equipment\models\weapons\ku_hornet_launcher.cmp
part -> k_hornetlauncher_base_lod1020829120522.3db

2011-07-02 01:51:27.616: Common.0630E681
Bad address = CDCDCDCD
Previous call:
cmp -> equipment\models\turret\ku_turret04.cmp
part -> base021119202046.3db

Got crashes - where to dig?

Wasn’t this resolved to the lack of hardpoints (hpid) in the sur?

adoxa wrote:
Wasn’t this resolved to the lack of hardpoints (hpid) in the sur?

I dunno about it, aby prooflink?

EngBase-0124BD was refined to GetRoot, which was further refined to GetCollisions. Adding hpid to the sur was found to be the solution.

I get Crash at Fault offset: 0x00021117 in Common.DLL

it is appeared here:

.text:06281105 loc_6281105:			       ; CODE XREF: DamageList::operator=(DamageList const &)+91j
.text:06281105		       mov     [eax+4],	edi
.text:06281108		       mov     [esi+4],	eax
.text:0628110B		       mov     edx, [eax+4]
.text:0628110E		       mov     [edx], eax
.text:06281110		       add     eax, 8
.text:06281113		       test    eax, eax
.text:06281115		       jz      short loc_6281128
.text:06281117		       mov     ecx, [ebx+8] ; <-here
.text:0628111A		       mov     [eax], ecx
.text:0628111C		       mov     edx, [ebx+0Ch]
.text:0628111F		       mov     [eax+4],	edx
.text:06281122		       mov     ecx, [ebx+10h]
.text:06281125		       mov     [eax+8],	ecx

Whats wrong may be?

Crashes detected by me or our server:

content.dll
000db0f1 - bad patrol(i think)
0009100f - bad tradelane(i think)
0009566d - bad tradelane(i think)
000d8e14
00016bb3
000ab23d
000d8e14
00013bb3

freelancer.exe
0013d13a
0013b395
001545f7
00006100- bad wireframe(Adoxa)

remoteserver.dll
00012460

common.dll
0010960c
0005be63 - non existing exclusion zone, but is called in asteroid/nebuda file - look to FlSpew.txt for zone nickname
00025cc9 - bad surface file
000f2597
00103141
00025cc9

x86math.dll
0000189f

rendcomp.dll
00011163 - bad hash at <vmeshlibrary>example <li_gunboat.3db.lod0.vms include=“li_gunbship_cmp\lod0.vms.xml”>but hash is li_gunboat.lod0.vms

thorn.dll
0002c9ae</li_gunboat.3db.lod0.vms></vmeshlibrary>

Uh
not sure if i post this here or not, but FLServer crashes on me before it finishes even starting up. Don’;t know if this is correct, but
Offset 0x00003de4 in DACOM.dll

Got strange offset at flmaterials.dll

0x00005b33

At flspew.txt:

C:\work\builds\dalibs\dalibs-build\build\Src\RendComp\VMesh\VMPartArch.cpp(697) : NOTICE:General: VMESH: couldnt find material 65536
C:\work\builds\dalibs\dalibs-build\build\Src\RendComp\VMesh\VMPartArch.cpp(697) : NOTICE:General: VMESH: couldnt find material 327684
C:\work\builds\dalibs\dalibs-build\build\Src\RendComp\VMesh\VMPartArch.cpp(697) : NOTICE:General: VMESH: couldnt find material 589832
C:\work\builds\dalibs\dalibs-build\build\Src\RendComp\VMesh\VMPartArch.cpp(697) : NOTICE:General: VMESH: couldnt find material 851980
C:\work\builds\dalibs\dalibs-build\build\Src\RendComp\VMesh\VMPartArch.cpp(697) : NOTICE:General: VMESH: couldnt find material 1114128
C:\work\builds\dalibs\dalibs-build\build\Src\RendComp\VMesh\VMPartArch.cpp(697) : NOTICE:General: VMESH: couldnt find material 1376276

Tried to find this values by FL Developer - no luck

Happens mostly at one system - bw08 (Tau-23)

Digging fl forums i see not only me had this problem…
Someone solved?

Try to remove

….
[Object]
nickname = Bw08_suprise_ge_train_1
ids_name = 261761
pos = 21340, 0, 22673
rotate = 30, 0, 20
archetype = suprise_ge_train
visit = 16
ids_info = 66426
loadout = SECRET_train_bw08
……

and check if it still happens.

I encountered various texture related problems
using the HD texture mod.
Dragging that one down was real pain.

Yeah, b!g thanks F!R!
Works ferroconcretely