Hijacking default Actor variables....

Discussions about Coding and Scripting
MrLoathsome
Inhuman
Posts: 958
Joined: Wed Mar 31, 2010 9:02 pm
Personal rank: I am quite rank.
Location: MrLoathsome fell out of the world!

Hijacking default Actor variables....

Post by MrLoathsome »

Opinions needed.

Been working on a small project, and was wanting to avoid the sub-classing/spawning/destroying etc on these actors.

But it needs just 1 extra bool....

In initial testing I was just using the bUnlit actor var for my switch, but that is really terrible practice as a lot of other
classes are using that and it is probably relevant at runtime. Not good at all.

Was scanning thru the Actor.uc code, looking for something else that I might use.

Noticed the little Editing Flags section.

Can anybody tell me a good reason why I can't hijack one of those booleans for use in a mutator acting on an actor that
get spawned in realtime during games?
blarg
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: Hijacking default Actor variables....

Post by Higor »

You either use one of the existing bools, or 'inject' a new bool property into actor using a native package.
User avatar
PrinceOfFunky
Godlike
Posts: 1200
Joined: Mon Aug 31, 2015 10:31 pm

Re: Hijacking default Actor variables....

Post by PrinceOfFunky »

MrLoathsome wrote:Been working on a small project, and was wanting to avoid the sub-classing/spawning/destroying etc on these actors.
When I made the AdvancedMutator, as a workaround to the problem you said I thought of making this:
PrinceOfFunky wrote:New "meta-variables" can be created at run-time.
PrinceOfFunky wrote:- A new class called "ValueSaver" is the manager of saved values. It will save whatever value of an actor which owns an ActorInfo, the ActorInfo can then check those values costantly or just leave them in the ValueSaver without checking them, if it does tho, value changes or "unchanges" will be notified to the mutator who requested the saving of the value(or its subclasses).
- ValueSaver has a variable called "channel" which will let mutators to save more than one value of the same property.
"Your stuff is known to be buggy and unfinished/not properly tested"
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: Hijacking default Actor variables....

Post by sektor2111 »

MrLoathsome wrote:In initial testing I was just using the bUnlit actor var for my switch, but that is really terrible practice as a lot of other
classes are using that and it is probably relevant at runtime. Not good at all.

Was scanning thru the Actor.uc code, looking for something else that I might use.

Noticed the little Editing Flags section.

Can anybody tell me a good reason why I can't hijack one of those booleans for use in a mutator acting on an actor that
get spawned in realtime during games?
Maybe you want to use some of those things which actor has but actually without having support at all so to speak useless bool values untouched anywhere, by example "bActorShadows" has no effect, UE1 has nothing to deal here exactly as that "bLensFlare" which I could not see if does something VIA natives, so to speak are just result of rushing the work leaving them unused.
Also I think you might use Editor Specific stuff which is not linked that much in run-time game play "bEdShouldSnap" or such, bEdLocked, bSelected. I don't see them as constants so probably you can link then with some testing stuff.

If None of these are helping, try what Funky said but more simple, using another actor owned storing data and having a parent for chained list deal or... Iterator using a specific Tag (as monster does when dies).
User avatar
Feralidragon
Godlike
Posts: 5489
Joined: Wed Feb 27, 2008 6:24 pm
Personal rank: Work In Progress
Location: Liandri

Re: Hijacking default Actor variables....

Post by Feralidragon »

While it may sound a good idea at first, using "unused" variables is always a bad idea in the end, because other developers may have had the same idea as you and use those same variables for something else, and then when you join your and their mods together:
:redeemer1:

If I recall I did the same thing in some mods, although I don't really recall which ones and for what exactly, but I think I only did this in very old ones.

From here, following a bit the previous suggestions above, you should have something else on the side to specifically store what you want, and have that reference the actor it's meant to track.
However, depending on what you want to do, it may be preferable to extend the Object class instead of the Actor class, and do normal object instantiation rather than "spawning", because Actors are very heavy CPU and memory-wise compared with simple Objects, but this would only be preferable if you do not need to have replication (run only in the client or only in the server), otherwise it needs to be an actor.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: Hijacking default Actor variables....

Post by sektor2111 »

Feralidragon wrote:because other developers may have had the same idea as you and use those same variables for something else
And ?
We have such things done in a ShowDamage mutator - using SecretCount, to light things a bit, if admin doesn't have a clue what does inside his "server" that's a different story, UTJStrongMonster or such also uses whatever property for figuring monsters powered up. Shrimp uses Shadow for testing skill of monster - since 2002 - here if mapper wants to prevent a monster to be touched in Original MH he/she might use an embedded shadow owned and then monster won't be changed - this is advanced map editing not default cube drawing. That's why if you are using some mutator in server, reading that "read-me" is not optional, it's a must. If "read-me" is written by some "copy-paste coder" - claiming that it was helping people older than his ass - then discard whatever moron says, and use original stuff (not gonna bring more dead posts to surface as an off-topic trash hijack... ).

Objects... he, he, if you are handling them wrong, Garbage Collector will bite you... Good luck, there, I have a recall about a question around asking for opposite of "New" - there is no any opposite function, it's just ... something like "This = None" - then "Obj Garbage" or whatever might help.
I have never messed up with objects and my server it's fine thanks, even if I have a map doing default monster modifications, used intensive, at server-travel I have a clean ground for next map where monsters have ORIGINAL default properties without to remain screwed up like in other server where Garbage Collector does nasty things - and... I LIKE this way of doing without a mods-soup, without using any "opposite of new" and useless damaging objects floating around... if I'm loving something at UT, that thing is Actor which is having "Destroy" stuff, happily getting vanished at once with the Level when server does a travel to another one.
As a mapping hint, when you do not use monsters at special task, you, mapper can use even their TAG (MH doesn't use it nowhere) for tweaking them in run-time (map specific MyLevel stuff) for preventing recursive modifications.
User avatar
Feralidragon
Godlike
Posts: 5489
Joined: Wed Feb 27, 2008 6:24 pm
Personal rank: Work In Progress
Location: Liandri

Re: Hijacking default Actor variables....

Post by Feralidragon »

sektor2111 wrote:
Feralidragon wrote:because other developers may have had the same idea as you and use those same variables for something else
And ?
We have such things done in a ShowDamage mutator - using SecretCount, to light things a bit, if admin doesn't have a clue what does inside his "server" that's a different story, UTJStrongMonster or such also uses whatever property for figuring monsters powered up. Shrimp uses Shadow for testing skill of monster - since 2002 - here if mapper wants to prevent a monster to be touched in Original MH he/she might use an embedded shadow owned and then monster won't be changed - this is advanced map editing not default cube drawing. That's why if you are using some mutator in server, reading that "read-me" is not optional, it's a must. If "read-me" is written by some "copy-paste coder" - claiming that it was helping people older than his ass - then discard whatever moron says, and use original stuff (not gonna bring more dead posts to surface as an off-topic trash hijack... ).
Advanced map editing you say? It sounds more like a required hack caused by poor software engineering to me.
Nothing more and nothing less. And it's a surprise to me how you would even promote such a trashy practice...

If 2 different mods use and change the same resource in different ways, at least one of them is bound to break, it's a similar principle of concurrent programming, making them incompatible with one another, and breaking one another in unpredictable ways, depending on which mod changes it first.
A good mod doesn't break other mods, period (the same for any software), and while it's not always something that can be guaranteed due to several factors, if there's a way to do something to ensure mod compatibility, that way should be pursued, it's that simple.

To not even mention that some mods actually implement those properties the way they were meant to, such as foot step sounds in textures for example.
So what if someone ends up implementing those properties properly?
Many of those properties can be properly implemented through UScript alone.
sektor2111 wrote: Objects... he, he, if you are handling them wrong, Garbage Collector will bite you... Good luck, there, I have a recall about a question around asking for opposite of "New" - there is no any opposite function, it's just ... something like "This = None" - then "Obj Garbage" or whatever might help.
I have never messed up with objects and my server it's fine thanks, even if I have a map doing default monster modifications, used intensive, at server-travel I have a clean ground for next map where monsters have ORIGINAL default properties without to remain screwed up like in other server where Garbage Collector does nasty things - and... I LIKE this way of doing without a mods-soup, without using any "opposite of new" and useless damaging objects floating around... if I'm loving something at UT, that thing is Actor which is having "Destroy" stuff, happily getting vanished at once with the Level when server does a travel to another one.
As a mapping hint, when you do not use monsters at special task, you, mapper can use even their TAG (MH doesn't use it nowhere) for tweaking them in run-time (map specific MyLevel stuff) for preventing recursive modifications.
It's normal to be afraid of objects if you never used any other OOP language before.
In fact, the handling of objects in Unreal Engine is not very different from how objects are handled in other languages, and in them too, there's no "Destroy" method, you just assign "null" to whichever reference you have, or you just let the stack do it for you if the reference only exists locally within a function.

The only problem that I know of with objects in this engine concerning GC is if they are referenced by actors which are not destroyed upon map change, and they avoid some actors to be garbage collected if they are still referenced by a live object as well (so the object should check this as well, but the same applies to actors so there isn't much different as far as I am aware).
They don't have any replication either, but that's a plus in my book, since you don't use objects for replication purposes, there's where you use an actor.

Other than that, they are the simplest and cleanest entities in the Unreal Engine, do not hog your memory with unnecessary properties, are fast to initialize (because they don't run the entire chain of events and whatnot an actor does), they are not ticked and reside outside the actors list (because they are not actors), so the engine is only aware about their existence but doesn't really need to employ a single shred of CPU power to process them, and thus for all intents and purposes, they are perfect for things like tracking and whatnot.
At most, they may only cause memory leaks and a few other problems if not handled correctly, but the handling is not very different from any other language, and their GC problems are not very different from actor GC problems in this engine.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: Hijacking default Actor variables....

Post by sektor2111 »

Feralidragon wrote:Advanced map editing you say? It sounds more like a required hack caused by poor software engineering to me.
Nothing more and nothing less. And it's a surprise to me how you would even promote such a trashy practice...
Probably FALSE. As a proof, all I have to say is that whatever actor having an owner it's doable directly in map, yeah, actor it's "educated" for having an embedded owner BEFORE RUN-TIME, and it's nothing that special than using a default command called "EditActor" or Editor's console at random. If you did not use these and never gain additional properties of an actor the term for this editing is "required hack" and "trashy" ? May I ask how did you draw such a conclusion - are you getting older ? You can even figure if certain node has whatever links/paths, but hey, I don't need to recall Bot things for people which are defaulted against poor Bot... And YES I'm promoting these as long as they are part of Unreal Editor and nothing else.

Did I say that I could fix some BSP bugs using NotePad++ ? Nope ? My bad, probably fixing BSP problems from a bad map is a hack and a trashy thing.... :ironic: suuure... especially when 8+ versions of the same crap are still floating around and nobody has fixed it, but making another copy...

@LoathSome - probably term "hijacking actors variable" it's not suitable in this environment where everything needs to be clean not "trashy" and without "required hacks". We need to hijack objects as a total object addiction...
User avatar
PrinceOfFunky
Godlike
Posts: 1200
Joined: Mon Aug 31, 2015 10:31 pm

Re: Hijacking default Actor variables....

Post by PrinceOfFunky »

Well, to avoid the concurrency problem, I guess the best way is to create somthing that acts as intermediate between a variable and an actor/object, just like in relational dbs.
What kind of intermediate you want to create is your choice, you can even make uscript write an int with the value of that variable and then read it later.
"Your stuff is known to be buggy and unfinished/not properly tested"
User avatar
Feralidragon
Godlike
Posts: 5489
Joined: Wed Feb 27, 2008 6:24 pm
Personal rank: Work In Progress
Location: Liandri

Re: Hijacking default Actor variables....

Post by Feralidragon »

@sektor2111: Are we still talking about the same thing?
Like, for example, turning the actor bLensflare property to True to mean something other than actually enabling a lens flare?
Because you're completely drifting away from the original subject, and bringing things like BSP fixing and whatnot, which have absolutely nothing to do with this and what I was talking about.

Maybe if I put it this way: imagine 2 different unrelated programs sharing the exact same memory space, and imagine the clusterfuck of bugs and crashes it would cause to both.
There's a proven reason why each program must have its own memory space, and it's because each program expects any memory allocated to it to be only its memory and not have any data stored in it changed by other programs, this is why you can have a virtually infinite amount of programs running in the same system, and have them working together without issues regardless of what they do by themselves.

Similarly, using and setting a property in a actor for any purpose other than what it was originally intended, will always cause problems when at least 2 mods use it for completely different things, especially if one of the mods actually means to implement the missing functionality as originally intended (and I gave at least one example of this).
From here, if you do not get why this is a bad thing to do by now, I don't know what else to say to you.


@PrinceOfFunky: You mean something like a single object which is the one making the control, and is used by other objects?
I am not sure what that has anything to do with a bridge table, but I understand what you mean if that's the case.
However that wouldn't solve anything here either, because that's not exactly the problem here.

The problem here is to use resource or property X for a different purpose than it was first designed for, and other modules/mods have no way to expect that change in behavior, and that's an anti-pattern all in itself.

One thing is to change a property, but change it with the right expectations of what changing it means, such as changing the zone gravity for example: in NW3 I have a central actor responsible to affect the zone gravity over the course of one specific effect (the "sun weapon" let's call it), so that if there are many instances trying to do the same thing, it's this single actor which mediates that change, but in the end this property will change the zone gravity and that's what is expected to happen.

It's a completely different thing to change the the kind of property sektor2111 is advocating, which is meant to do one thing (even if it was not implemented) but to mean something else, that's a prime example of bad coding.
User avatar
PrinceOfFunky
Godlike
Posts: 1200
Joined: Mon Aug 31, 2015 10:31 pm

Re: Hijacking default Actor variables....

Post by PrinceOfFunky »

Feralidragon wrote:The problem here is to use resource or property X for a different purpose than it was first designed for, and other modules/mods have no way to expect that change in behavior, and that's an anti-pattern all in itself.
Are you sure he wants to use an already existing variable? He wrote "extra":
MrLoathsome wrote:was wanting to avoid the sub-classing/spawning/destroying etc on these actors.

But it needs just 1 extra bool....
So I guess if he knows of a way that doesn't need to use an already existing variable, he would pick it.
"Your stuff is known to be buggy and unfinished/not properly tested"
MrLoathsome
Inhuman
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 »

Great replies from all.

Feralidragon is of course 100% in his statements, and that is exactly the reason I chose this thread title.
In some cases you can get away with such antics with UT, but it does add the possibility of issues later.

@sector2111 - bEdLocked is exactly the var I was thinking of Hijacking. I can't think of anything really that
would be using that on a runtime type temporary actor.

But as The Dragon points out, some other joker who thinks he is as clever as me could possibly use the same
var for something else acting on the same actor in-game. :loool:

Looking closer at the code that prompted this post, I believe I can check the state of a variable this class does use
normally and eliminate the need for an extra bool. It is safer.

However. If in the future I ever do need to hijack a var for runtime use, bEdLocked is much safer to use than say
something like SecretCount... :idea: :omfg: :wth:
Maybe. Perhaps....
blarg
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: Hijacking default Actor variables....

Post by sektor2111 »

Yep.. if anyone else uses the same variable.

Excuse me Ferali for not understanding what I said with variables and preventing something.
Once again shortly this time, MonsterHunt USES SHADOW for pawns to test skilled vs un-skilled ones. Monster getting a shadow (in server :loool: ) won't gain recursively skill. Mapper if is a smarty one and using advanced map editing can setup a monster with Shadow and then SetPawnDifficulty won't get called for it leaving it in original - was a question somewhere about preventing MH to screw creature - you have to be new in MH as I see.... THIS IS What I was trying to say, and yes, this has a relevance toward some actor properties and how mapper can mess such strategy if he doesn't know what it's doing in Editor or it's doing this on purpose.
Okay more shortly: Pawn >> Shadow >> SetPawnDifficulty >> Editor >> Monster tweaked in map is being left original (not in my MH versions :P ).
Feralidragon wrote:@sektor2111: Are we still talking about the same thing?
Like, for example, turning the actor bLensflare property to True to mean something other than actually enabling a lens flare?
Enabling an A$$. IT'S USELESS, yeah, truly USELESS.
Perhaps you want to talk about bCorona which is another chapter (btw, I won't use that from now on - I have another deal better for rendering and even I can tweak maps in run-time). Are you here ? Good, take a breath then read again >>>
bLensFlare is USELESS (consuming memory as you said :agree1: ) as bActorShadows because I TESTED both of them. - THEY AREN'T USED NOWHERE in natives but nowhere.
Watch this for bActorShadows and bLensFlare, :P at what Wiki says.
MrLoathsome
Inhuman
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 »

Well. Don't trust Epics code, or what the Wiki says.
(Although those are the only 2 things I have been looking at for this months project, other than the original DecalStay source... You can trust most of it. But test and log stuff if you want to be sure...)
bLensFlare is USELESS (consuming memory as you said :agree1: ) as bActorShadows because I TESTED both of them. - THEY AREN'T USED NOWHERE in natives but nowhere.
Well, I have done similar tests on various things, and was sure for a brief time there would be no issue. But then when testing with something else
running that wasn't there in the previous testing, suddenly an "issue" would crop up. No way to test with everything.

Just one of the reasons I am currently trying to write my stuff on a mostly bone stock 436 install, and still write it in such a way that it wont conflict with
anything it doesn't work with if possible. Trying to work with the engine, rather than fight it.

And I would certainly use the bEdLocked actor var before either of the other 2 you mentioned there.
Shadows are one of the major reasons I have this rewrite still working on Scorch classes and not all Decals.

I wonder if anybody around here knows if those extremely cool NaliWeapons and NaliGore thingys are subclassing
Botpack.Scorch or Engine.Decal? If they subclass Scorch, and don't have their own built in decalmanager running, my DecalStayPlus
update will work with them. My guess is that might all be built right into it already. (Haven't installed the NW stuff yet on my new pc.... :oops: )

I am about to post another thread with a new cool question regarding code optimization.
Will have a nice code snippet there that will show what I did in that specific case to eliminate my "need" for an extra bool.
blarg
User avatar
Feralidragon
Godlike
Posts: 5489
Joined: Wed Feb 27, 2008 6:24 pm
Personal rank: Work In Progress
Location: Liandri

Re: Hijacking default Actor variables....

Post by Feralidragon »

sektor2111 wrote:
Feralidragon wrote:@sektor2111: Are we still talking about the same thing?
Like, for example, turning the actor bLensflare property to True to mean something other than actually enabling a lens flare?
Enabling an A$$. IT'S USELESS, yeah, truly USELESS.
Perhaps you want to talk about bCorona which is another chapter (btw, I won't use that from now on - I have another deal better for rendering and even I can tweak maps in run-time). Are you here ? Good, take a breath then read again >>>
bLensFlare is USELESS (consuming memory as you said :agree1: ) as bActorShadows because I TESTED both of them. - THEY AREN'T USED NOWHERE in natives but nowhere.
Watch this for bActorShadows and bLensFlare, :P at what Wiki says.
I think you've missed my point: I used the bLensflare example exactly because it's not used anywhere.
My point was that, although it's not used, when enabled it's meant to show a lensflare. I know it's not natively implemented, but my point is that regardless of that, it still is for all intents and purposes a setting to enable a lens flare.
And the thing is: this is also another prime example of a property which can actually be implemented through UScript alone, to actually work the way it was originally meant to.

Now imagine if another mod uses it as a flag for something else... completely non-intuitive behavior, and not a good thing to have.

MrLoathsome wrote:And I would certainly use the bEdLocked actor var before either of the other 2 you mentioned there.
Even those, although as harmless they may look in-game (outside of the editor), may still be used in-game to still mean what they mean in the editor.
For instance, I remember a mod which would show all hidden actors in-game, not to be actually used in servers for normal gameplay, but as a way to debug a map and other things when in-game and interacting with stuff, since UScript doesn't run normally within the editor (it can be triggered to run, but it's not advisable since the effects are permanent).

MrLoathsome wrote: I wonder if anybody around here knows if those extremely cool NaliWeapons and NaliGore thingys are subclassing
Botpack.Scorch or Engine.Decal? If they subclass Scorch, and don't have their own built in decalmanager running, my DecalStayPlus
update will work with them. My guess is that might all be built right into it already. (Haven't installed the NW stuff yet on my new pc.... :oops: )
Had to check the source (I didn't remember to be honest :lol2: ), and all normal decals extend from NWDecal, which extends from Scorch indeed.
I have another decal class just to detect the BSP surface textures (for the debris effects), but that one extends Decal directly, so yeah, your mod should work with it without issues.

They however have also their own "decal stay" kind of feature (you can set the decals lifespan in the ini, and if set to 0, they will last forever, and I also disable the timer at that point), but shouldn't conflict with yours I believe.
Post Reply