Fix or Hack for persistent warning messages please

StarTrader

Hi adoxa.

Here’s a crash report from the sur problem, hope it gives us a clue.

And the dxdiag.txt file too.

I couldn’t copy the dump data from the dump window to upload it.

adoxa

Ah, the old 124bd bugbear. I made a plugin to log and prevent the crash (14 downloads, but no one’s reported back).

Edit: Scratch that, already tracked it down to a collision problem. Note this is solely an MP issue; the code is not called in SP. Attached two plugins (both installed via dacomsrv.ini). GetRoot will log the crash and prevent it; GetCollisions will log the collision that causes the bad root (I think that’s how they work; it was a while ago and I made no comments). The logs are created in EXE, as *-bad.txt. Unfortunately, I don’t think the collisions log really provides any useful information. Try running with PacketLog as well, see if there’s any correlation with the timestamps (the IM conversation where this originated never got that far). At the time, I thought this might have been a legitimate bug (some sort of race condition, where the object is destroyed before the collision is applied), but if it’s only happening with generated surs and not vanilla surs, I guess not.

StarTrader

Good if it is familiar - can we link that to sur problems?

They only happen when I use the new surs I made with Sur Builder.

It would be great to find the cause in the sur file so we can avoid them.

adoxa

You were too quick for me, where I edited my post. Only writing this since edited posts don’t show up as unread.

StarTrader

Ok.

Clue - collision as in collision between 2 ships?

I am jumping to conclusions, but -

I am using a giant ship (the Midway, 1800m+ in length) as a base, the test fighters attack it, and it could be when a fighter with the problem sur collides with the base ship hull!

Hence why it is so intermittent, and why Sushi isn’t seeing the problem at all, he has set up the 2 fighter types attacking each other only.

That could very well be the problem, collision detection, not hit detection! Bounding boxes missing - if so then it is likely that all custom surs will fail when tested in this way for long periods!! Yay!

How can we prove this as the case or not?

Sushi can you set only 1 test ship type and make the faction hostile to your base so they attack it? It will need to be a big base to encourage collisions.

FriendlyFire

Is your big ship’s SUR built using the SUR builder and couldn’t that be the faulty one?

StarTrader

I built the big ship sur manually and used Sur splicer.

When I change the fighter sur for any vanilla one it runs clean for overnight.

It could be that having one good sur (the vanilla one with boundary boxes) in a collision enables the detection and stops the problem, and if both the base ship and the fighter are custom surs (no boundary boxes) then the collision detection error-crashes.

Collision detection (ship-to-ship) sounds right at the moment, not hit detection since the ships can be destroyed for many minutes in constant waves.

Need to find a way to prove it.

Timmy51m

Like I mentioned earlier, all of my ships are made using surs built with the tool, I’ve bounced off a hell of a lot of them and not had a crash due to it. So I’d say ship to ship collisions are fine, but you’re talking about a collision with a custom solar sur, could the solar sur be the problem, not the ships.

Just for the hell of it, make an sur for the solar with the sur tool, then run the test again, see what happens. I know it will fit like crap but it’s a reasonable step to take for elimination.

LancerSolurus

The sur builder adds a collision box for every sur part it generates so it would have to be something else. If you can track it down exactly whats causing it there may be a way to fix it. Cant fix a problem if the problem isnt defined properly. I cant test them since my server worked fine with over 128 custom surs in it.

FriendlyFire

Well… ST’s base SUR wasn’t made with the SUR builder, so it obviously doesn’t have a collision box.

adoxa

Sorry, ST, I think it was a munition collision. Perhaps logging all collisions might help, although it might generate a huge file. GetCollisions.dll, 00114E, 74->EB. Search for “crash” in GetCollisions-bad.txt and see what’s around it. And run PacketLog, too (hope you have a lot of free space). Use PacketDump on the packet log and correlate the times with the crash times from the collisions log. GetRoot-bad.txt shouldn’t be providing any relevant information, unless the addresses are different (i.e. they should all be the same address, but I don’t remember what that address was). Alternatively, if possible, put together a mini-mod for me to test myself.

StarTrader

Thanks guys, I’ll do it when I can get some free time and report back.

adoxa

If you’re going to use PacketDump, delete/rename/edit packets-excluded.txt (or use -i from the command line), otherwise the collision packets won’t be included.

StarTrader

Adoxa - by munition collision, do you mean ammo, or a missile, hitting a ship?

Or do you mean ammo hitting ammo, like a missile being hit by a bullet?

This crash is so intermittent, it could be as bad as the second suggestion.

But what is against that is that when I replace the suspect .sur file only, with any of the vanilla surs, then the game runs clean. All the weapons and factions and ammo are the same. Only the sur is different.

Anway, which of the above do you mean?

adoxa

Actually, perhaps it isn’t necessarily munition collision after all.

void PhySys::GenerateCollisions(CBeam *)
void PhySys::GetCollisions(UINT,const PhySys::CollisionEvent * &,const PhySys::CollisionEvent * &)

```The server calls those two functions, then runs a loop, presumably testing each collision. The crash occurs due to an object apparently no longer existing. At least, that's what I thought was happening, but that would imply it would occur with vanilla surs, too. Since that doesn't seem to be the case, I guess it's something else. A look at the log files would help. But then, when you replace the sur file, do the object names in the sur still match the cmp? Perhaps the sur simply isn't being used in the same way.

w0dk4

Adoxa - by munition collision, do you mean ammo, or a missile, hitting a ship?

Just to clarify, its munition collisions aka beams (CBeam), so no missiles, no object-object collisions, only beams that hit an object.

StarTrader

adoxa wrote:
… But then, when you replace the sur file, do the object names in the sur still match the cmp? Perhaps the sur simply isn’t being used in the same way.

In prior tests I resized the vanilla surs and FLModelTool replaces all the part names with Root.

All ships have Root.

In the last tests I just copied the vanilla sur into the ship folder and renamed it so the only part of the sur that is functioning is Root. But they still run clean, so it’s clearly not a case of a missing cmp part - another possible cause now ruled out.

And of course in the tailor-made sur every sur part has a matched cmp group name.

LS - when I said Bounding box earlier I didn’t mean that, sorry - I meant the collision sur parts (Type 5) are missing from custom sur files.

This may well still be the cause of the crashes. Bejaymac kept pulling out his hair telling us time and time again that FL uses collision sur parts as well as hit detection sur parts. These are the Type 5 parts in the surs.

I cannot see how to put them in correctly…

I can make the shapes easily enough but as you and adoxa say, the hex “names” of those parts are in fact “offsets”, and I have no idea how to calculate those so that we can change the sur file with a hex editor and make it correct. I imagine it is the offset (but from where?) to the address of the first vertex co-ordinate for the sur part?

Oddly I have seen that different vanilla ship surs use the same offsets, and I can’t understand why that should be either

And I still can’t understand why those Type 5 parts are all centred at the origin (or have no location co-ordinates) instead of being “in place” on the ship group they are covering.

Uh - maybe we should start a new topic if this thread will continue.

Ben_Kai

adoxa wrote:

rp8.dll 	00D1FD	B802->EB4D = disable "set_material() called outside of create_buffers/destroy_buffers" spew warning ~adoxa
rp8.dll 	00FA82	B802->EB4D = disable "set_render_state() called outside of create_buffers/destroy_buffers" spew warning ~adoxa
rp8.dll 	00FBE9	B802->EB4D = disable "set_texture_stage_state() called outside of create_buffers/destroy_buffers" spew warning ~adoxa
rp8.dll 	0100ED	B802->EB4D = disable "set_texture_stage_texture() called outside of create_buffers/destroy_buffers" spew warning ~adoxa
rp8.dll 	01033C	B802->EB4D = disable "verify_state() called outside of create_buffers/destroy_buffers" spew warning ~adoxa
rp8.dll 	015403	B802->EB5C = disable "set_gamma_function() called outside of create_buffers/destroy_buffers" spew warning ~adoxa
freelancer.exe	03B348	74->EB = disable "Failed to get start location" spew warning ~adoxa

I added these hacks but had probs with the last two. The others work great! Thanks!!

Not a big deal as the….

WARNING:General:set_texture_stage_state() called outside of create_buffers/destroy_buffers
and
WARNING:General:set_render_state() called outside of create_buffers/destroy_buffers

are the ones that tend to show up in droves… Out of curiosity, figured I would post.