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.