Fix or Hack for persistent warning messages please

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 don't think there is any such buffer or log. If you can provide me with a crash address, I could have a look around.

in my rp8.dll on offset 0x015401 there is “75 66”

Yes, it should have been 15403, not 15401; updated the patch.

Here are instructions I made earlier to get the crash address. The second window contains the exe/dll that caused the crash (ModName), with its file offset (Offset); the third window provides the address in memory (Address).

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.

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

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

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.

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.

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

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.

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.

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.