Higor wrote:There's only so much that can be done if you can't alter the original code.
XC_Engine is only doing 15% of the things an actual UT update would do if it were rolled by a team UT99.org coders.
If the original code was released or at least accessible by some, only the sky would be the limit in what could be done.
But UTPG ruined those chances completely for limited access at least, so only a full public release could potentially make wonders.
However, there's still a lot that can be done. The engine is still quite stable for its age and the amount of time Epic actually dedicated to it, and the public headers allow for many things to be done, so we cannot complain.
Higor wrote:
It's not about better or worse, it's about which is more convenient to use given your goals and knowledge.
This.
sektor2111 wrote:sample ? Allright, let's walk through a bad script called ScriptedPawn ruining the charm of MH game. NOT everything can be fixed with XC_GE, but you can prevent troubles by adding simple sanity checkers in STATES where they need to be.
I remember, being mentioned at least, that states could also get overridden as well.
I think someone else (Chris?) did something to replace states and posted it in one of Higor's topics about XC, although I am not sure if it was incorporated at all in it.
sektor2111 wrote:
And yes,
Feralidragon wrote:If it's to "conform" packages in the same way you have been doing privately, and having it done publicly instead, that's calling for trouble, so you're probably going to remain alone in that endeavor.
by making things to work flawless is disturbing for trash lovers, I gotta admit... I'm not convinced that some admins did not do this already and even more. Some topic with "forged object" is an evidence about this and... I have encountered this problem in my "beta" attempts, but now everything is normal, and me alone in endeavor I have a major advantage - I can test a lot of options for certain things by making WEEKLY changes without disturbing community with 1 GB of unknown packages - that's my master advantage of experimenting in a closed "lab", so here I cannot complain
. But I keep looking when coders will get pissed and will start doing the right thing. I'll point you to a community still developing things for "Win98SE" if you can believe that, there are still users doing stuff outta M$ if they don't care about their old products
. What seems to do community is exactly like buying the best spray trying harder to make a sh!t to smell better. There is a more simple solution to replace that sh!t with something else better and a good smelling, but if people are always getting the harder way or other useless way, this is not such a big issue for me.
I already mentioned this before I think, but the problem with conformation it's how messy and illegal that solution is.
For private use? Be my guest, you're free to do whatever you want privately.
For public use? It's illegal to do it in the first place, then it's a mess given that the base version of the packages are not getting increased, and they will require updates whenever something wrong is found in them, so you end up with tons of different files with the same package name, and not versioned at all from the engine perspective.
Sure, modifying the packages directly to fix them is the direct cut solution, but it has really bad implications if done as public releases, and doesn't solve anything for everyone as private (other than your own servers, and whoever contacts you to get them, of course). It would only work if we could effectively patch the game from within and increase the version (something like a v460 for example).
Otherwise, the way I see it, the best course of action is to eventually build new packages which implement the required polyfills to fix things underneath, and perhaps complement with XC stuff.
It's not as clean from a "software" point of view, but solves the problem with distribution.
sektor2111 wrote:
As a reference for 1 iterator replacing 3 there can be reasons to not mess with 3 iterators especially in maps having 4000+ actors and even more (see UTR awesome loads - 7000+) - I know what I'm saying here. A single function doesn't break execution cycles, it's increasing them, but you don't have to believe me, my way of doing has stabilized packages in my playground (at dreams stage 10 years ago) and that's why I'll keep doing things in my way without "concepts" and fancy failures.
It still depends.
Maps could have 10k actors, but if you're looking for 2 particular classes of actors, for which only Actor is the common parent, and which are not expected to exist in high numbers (singletons or just maybe a dozen of each), it's still preferable to use 2 iterator calls where internally it will transverse the 10k actors twice (20k internal iterations), rather than doing 10k and run UScript for every iteration, since 10k iterations in UScript are
at least theoretically
10x slower than 20k iterations in C++.
It comes to a point where even using linked lists to transverse a list of pawns looses its efficiency completely when the ratio between the number of pawns and the number of other actors is high enough.
That's why I asked for examples, to understand which is the case you were talking about.