Ya, the cpu drain from DTAS seemed to get worse as the match progressed. Towards the 7th or 8th round, it was almost unplayable at times.
SGServers DTAS Server
- Thread starter shan
- Start date
-
Two Factor Authentication is now available on BeyondUnreal Forums. To configure it, visit your Profile and look for the "Two Step Verification" option on the left side. We can send codes via email (may be slower) or you can set up any TOTP Authenticator app on your phone (Authy, Google Authenticator, etc) to deliver codes. It is highly recommended that you configure this to keep your account safe.
It's not really CPU usage and there's nothing wrong with the server. It's just that everyone's log file is being frequently updated because of the script warning. The longer the log file gets, the longer it takes to save it on the hard drive. This is why you really don't want accessed nones.
So that's what was happening. I noticed some hesitation in the framerate, but I figured I would look into it later and bailed. Been a while since I was on Inf so I figured my machine was hosed or something.
Crowze, InfilDTAS_111 is still producing access nones and slowing down.
Specifically, the erroneous function is in DTASHUD. Find this line and try adding this if statement:
The previous line was where you spawned MyFonts. In the case where the code gets ahead of itself and tries to access a property in a spawned object (ie. MyFonts.GetSmallFont() ) before it has spawned, an error will be produced known as accessed none becuz it's trying to access something that's not there. That's why you must always check spawned objects before accessing their properties.
Specifically, the erroneous function is in DTASHUD. Find this line and try adding this if statement:
Code:
if( MyFonts != None ) //Duke: check in case access none
Canvas.Font = MyFonts.GetSmallFont (canvas.ClipX);The previous line was where you spawned MyFonts. In the case where the code gets ahead of itself and tries to access a property in a spawned object (ie. MyFonts.GetSmallFont() ) before it has spawned, an error will be produced known as accessed none becuz it's trying to access something that's not there. That's why you must always check spawned objects before accessing their properties.
Last edited:
I don't know exactly why this happens... There may be unforseen lag issues or it's just the nature of code reading and engine processing. You can think of it as reading text really quickly and not fully understanding what you just read. Ok, maybe it's not that drastic, but there may quite possibly be a delay between the engine reading the code and realizing it in-game. The old unrealtech site gave a rather crude explanation of this something to the effect of ...in the case of a spawn failure, you always want to check if these actors exist before modifying them...
Just add that check to a spawned object ALWAYS before accessing anything from them, trust me. i've dealt with this during my ventures into yurch's rav2 till i tracked down every spawned object i could and made sure to eliminate all accessed nones that i found in the log file.
Just add that check to a spawned object ALWAYS before accessing anything from them, trust me. i've dealt with this during my ventures into yurch's rav2 till i tracked down every spawned object i could and made sure to eliminate all accessed nones that i found in the log file.
Crowze said:
MP_Duke said:
Could it have something to do with replication? (variable doesn't exist where you expect it to exist) Either way, what you said sounds right.
While i don't remember if this happens offline, i'm pretty sure replication won't solve this. If you take a look at other INF source code or even the UT scripts, you'll notice checks like if( ... != None ) everywhere.
Fat Marrow said:
Well, since UT uses UDP which is inherantly unreliable, that might be causing this to happen. It would explain why I don't get any accessed nones during my offline testing, too.
Once I get round to writing it as a HUD mutator, hopefully all this crap should be fixed as I won't have to mess around with HUD fonts etc..
Once I get round to writing it as a HUD mutator, hopefully all this crap should be fixed as I won't have to mess around with HUD fonts etc..
Last edited:
Don't look at it like a major bug that should frighten you to try to find a way to avoid it. It's just a simple check.. it's standard procedure after spawning actors, that's all.
Crowze said:
I have reverted back to 1.0 on the DTAS server. I will put 1.12 on as soon as it is released.
Shan
Shan
If shan updated the XM8/M16A4 to the latest versions, Crowze you can remove those lines of code i sent you for DTASHUD that accomodates new weapon icons.
shan said:
Are there FPS drops due to dtas? I read that in the other dtas thread. Or was that the previous dtas version?
Well i guess ill find out soon enough.
cya on dtas
Well i guess ill find out soon enough.
cya on dtas
1.12 is still having problems. I pulled the DTAS server off-line last night because of it. I will bring it back up today with the 1.0 version.