Battlezone Forums

I can't contain my excitement at having fixed the biggest QF2 problem I have ever had!!!!!!

The excessive FPS drops had been bugging me for the past 3 years.

I had always believed that they were a result of the high poly models or HD textures I was using.

It turns out that it was all down to this ODF entry: "isStealth = 1".

Every one of my units was using it, and it never even crossed my mind that it could be responsible for the FPS drops.

I highly recommend that all modders avoid isStealth = 1 like the plague.

THIS IS FRICKING AMAZING!!!!!!!!!!!!!!!

One of the creepiest things about this is that in some units, that line was commented out, but still causing the lag.

It only disappeared once I deleted that line.

oh, yeah, we've known about that for a few years now; should have asked...

*pictures bbb's head exploding*

kidding, congrats

May want to let GSH know so he can look into it.

This means that QF2 is actually a playable mod! At last!!

3 Races are complete, and the missions are underway.

It looks like a 2013 release is more likely than ever.

Red Devil wrote:*pictures bbb's head exploding*

...Destroying the entire city with it.

Commando wrote:May want to let GSH know so he can look into it.

Would he though? It's not an MP issue.

hands bbb a Mug O' Beer™

cheers!

"™" ?

Cheers, I think...

hmmm, might want to do some more tests in the editor. i just placed 10 units with isStealth = 1 and only noticed a 20 fps drop from 228 to 209

It only occurs when they are clustered around buildings, as in 'bases'.

I have never been able to reproduce this with stock assets.

I use V-Sync too, so the FPS is capped to 60. It would easily drop from 60 to 20 FPS whenever I was near a base with units around it.

A base by itself or the units by themselves caused no lag.

I have theorised that the lag is due to all of the units being watched for their position relative to the player, and whether or not they were behind buildings.

Probably just some bit of code going nuts & looping forever. There may be a 3rd factor contributing to it if the stock units don't do it, could be very hard to pin down though.

MrTwosheds wrote:Could be very hard to pin down though.

Yeah... it took me 3 years to figure THIS out.

It could be that I never tested stock units with "isStealth = 1" set, and that is why I couldn't repro it.

TBH, I'm not even interested anymore. I'll just avoid isStealth. I'm just glad that the problem is gone, at long last.

I just realised the pun; "isStealth" -- that is the name of the fricking ODF line that was hiding in plain sight for years.

How bloody poetic.

bigbadbogie wrote:I just realised the pun; "isStealth" -- that is the name of the fricking ODF line that was hiding in plain sight for years.

How bloody poetic.

I love this.

I would suggest whoever reports this proper to 1.3's bug tracker made note of isStealth's methods being the problem. I suspect that it must do a raytrace to detect when objects (mainly terrain) are in the way thus making the craft invisible (to targeting). There might be an error, optimization, or other option we can use, maybe even simply making the isStealth raytrace (if it is a raytrace) happen less often.

It actually makes a lot of sense that isStealth could cause this error, if ray-traces are going off when they shouldn't or are somehow leaking or un-optimized. This should be a relatively easy fix if it is an error in the code, and a harder fix if it needs some form of optimization instead (again,a assuming it is indeed a ray-trace).