Fix or Hack for persistent warning messages please
-
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.
-
Is your big ship’s SUR built using the SUR builder and couldn’t that be the faulty one?
-
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.
-
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.
-
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.
