Fix or Hack for persistent warning messages please
-
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.
-
Thanks guys, I’ll do it when I can get some free time and report back.
-
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?
-
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. -
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.
-
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 ~adoxaI 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_buffersare the ones that tend to show up in droves… Out of curiosity, figured I would post.
