Hijacking default Actor variables....

Discussions about Coding and Scripting
User avatar
Posts: 6410
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: Hijacking default Actor variables....

Post by sektor2111 »

MrLoathsome wrote:Well. Don't trust Epics code, or what the Wiki says.
I'm entirely agree here and that's why I'm always writing tools for testing/debugging, I could do nice hacks getting even over some recommendations from Polge and... firing XCGe is stage more things will dance as you sing.

Decals - my notes - observations
I was testing a map with... way more pupae easy to be killed with combos - spreading decals.
I figured that If you keep looking at them they stay there nice - running their stupid timer. When I was looking into another direction and then back to them they went vanished.
First time I thought it's PlayerCanSeeMe - which normally if is called authoritative in client I believe won't crash nothing here. But surprise... it was a relation with some variable "LastRenderTime" or such computed. When decal was not rendered at all for a while, it went to a self destruct task - yes, these are timer consumers in client and probably a delayed external call to a null timer and setting up a LifeSpan would be better than leaving them to mess up around. I would go also for a track in client spawned Via SpawnNotify and leaving a client guard to ruin them from time to time if their number is let's say 100 pieces splashed around. Probably those under track/not track are managed using some of those useless bools which are not that replicated anyway.
Another point, assign them a tracker (owner/owned) with a LifeSpan. When tracker dies it will get Decal in the grave with him. All these probably are recommended ONLY in client.
Posts: 958
Joined: Wed Mar 31, 2010 9:02 pm
Personal rank: I am quite rank.
Location: MrLoathsome fell out of the world!

Re: Hijacking default Actor variables....

Post by MrLoathsome »

hmmm. Interesting observations. I have seen PlayerCanSeeMe crash servers at times, and yet client does not actually crash, although the game
pretty much stalls out. It is odd when it happens. (Been seeing that from time to time long before this little decal project...)

If by assigning them a tracker, you mean spawn an actor that owns each decal, that is not going to help performance much I would not think. (Haven't tried it...)
It might, but would double the number of actors involved which might be an issue if the numbers get large.

One of the primary optimizations I am making to the old DecalStay code is to eliminate all of the spawning/destroying that was going on in the tick code.

Note, I was able to use one of the default timer variables as a "boolean/bInit" sort of indicator eliminating the need to hijack a non-related default actor variable.
Deleted my other thread on that. It was all old news to most of you, and the code fragment was a bit broken. (I think I have fixed it tonight...)

I suspected you may have had something similar built into your stuff. Glad to see you did it the "right" way. (Unlike how I did my Laser Scorches....) :what:
Will have to test that to see exactly what happens, but it sounds like they may be compatible.