◄► Unreal Tournament v469a Patch Release ◄►

General Announcements about Unreal Tournament and UT99.org
User avatar
sektor2111
Godlike
Posts: 5059
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: ◄► Unreal Tournament v469a Patch Release ◄►

Post by sektor2111 » Sun Feb 07, 2021 5:25 pm

The fact said before it's actually more simple, if you don't get what is about you can keep talking about anything else OUT of 469 subject bringing discussions about people not about the UT patch - I'm not sure if I need to read anything else which is not UT related not even for 227 if it's useless for UT..

If anyone will request over there adding "functions replacement" then nobody from developers will not need to fix anything from X bugged functions, but user will do that or turning packages after needs. Anyone using similar broken tools will have the same results. By Not using these packages this doesn't mean that they don't have bugs - which CAN BE SOLVED this way or I can think at whatever Remapping Packages feature, a class from a Level pointed to another package, perhaps configurable, using ScriptedPawn from UnrealShareII not UnrealShare or such. But if these are not interesting to be posted here, okay I won't talk about anything for 469 or whatever, me one I can live with my adjusted stock and XC 24 so I think I'm not going to bother you with ideas - as I can see, this is not a good thing, and I'll move things in private for fixing these "assets" until some powerful patch will be shared some day. In other hand I can use my default strategy, if I don't like what is being said in a topic, I'm not reading it - I think this one is easier, and then I won't need to share any ideas which I'm thinking about.
Cya another time !

User avatar
Feralidragon
Godlike
Posts: 5265
Joined: Wed Feb 27, 2008 6:24 pm
Personal rank: Work In Progress
Location: Liandri

Re: ◄► Unreal Tournament v469a Patch Release ◄►

Post by Feralidragon » Sun Feb 07, 2021 6:13 pm

OK... let's then talk about function replacement for a moment.

First off, if there are problems with existing UScript functions, rather than a new function to replace these functions, why not simply fix those functions directly at the source as part of a new patch?
UScript is open for anyone to make changes and submit pull requests to make them into the patch, no one is stopping you from doing it.

Secondly, that's a fairly dangerous feature to have in general, and I am not sure if a patch should actually have that kind of thing in the first place (not up to me to decide, just my opinion).
Replacing any function directly by your own is something that should not actually be allowed at all, as that amounts pretty much to hacking, and it would be abused to no end if it was part of the base game.

Thirdly, the introduction of new native functions is not something that can be easily made available in future patches, and that's because new patches must be compatible with previous versions of the game, down to 436 (the last official version), thus if they introduce new functionality like that, and if something uses it, their stuff will not work in previous versions of the game, as it will downright crash.

It's a gray area on whether mods only compatible with new game versions is something Epic would allow or not, even if the base patch was itself compatible, but just in case, even new functions which were introduced in 469a are not really allowed to be used by mods for now (Anthrax makes an automatic check for those during compilation, to make sure no one uses them).

For this I have personally written a fairly complete technical specification on how this problem could maybe be solved a long while ago (long before the patch was publicly released), in such a way that new native functionality could be introduced without crashing previous versions of the game, including new functions, properties, etc.

This spec is not something available to the public for now, as it's not known yet if it will ever be pursued at all, since it involves some modifications in the UScript compiler itself and would need to be very well tested to make sure the engine performance stays about the same for new features like this.

Considering that the focus for now in 469 is bug fixing and performance improvements, new features are hardly a priority for now, so it's very likely you won't see anything like that for now, maybe ever, so if you want anything fixed, you have better chances by fixing it directly (my first point).

Furthermore, function replacement is a functionality that XC_Engine provides already, which you likely already know, so you can use that already instead if you want, as long as those replacements are server-side, which seems to be your major concern to begin with.

User avatar
sektor2111
Godlike
Posts: 5059
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: ◄► Unreal Tournament v469a Patch Release ◄►

Post by sektor2111 » Mon Feb 08, 2021 1:09 am

Replacing functions won't affect too many things if are addressing a main target: server-side. Like decals are exclusive only for Client I believe in C++ you can see if you are server and allow replacements only there, or if it's about client - limited level in clients for preventing exploits of this feature. Of course, they need time to be tested well. Yes, XC_Engine has this feature which I used in my main tweaker mutator (I wanted my own way with replacements) - XC_MonsterHunt is based on such replacements as a sample and is a game-type running in server compatible with all 436 clients - all XC executions are operated in server otherwise client is crashing instantly for a "bad Token" or such. But XC25 is not like it works with 469b and XC24 has no deal with 469a - NfoServers have screwed up here - Monster Gaming Server - they decided later to no longer mess with updates untested properly - I had some chat with them around this subject as long as that server uses intensive new XC assets.

Else... by triggering new packages for whatever "class" this would allow another package for said map - for client of course and then all calls should go into new files not original ones, even unloading those junks out of memory. I have to admit that such things might be very difficult to implement. I'm thinking at that duplicate TriggerLight the same name in two places, it would be needed altering pointer of the class and dealing with the second package... I'm not sure if I'm not mistaking here. Probably people unhappy about whatever expected reactions of engine will do their own deal - I recall the thread "How to replace a Zoneinfo" or such. How about a ZoneInfo coming from elsewhere and reacting other way not from Engine.u ? Of course that problem was solved by using another conformed package but... this solution is limited at compatibility, while loading another package for is another thing... just saying.

Also for DevPath perhaps would be welcomed an actor operational in Run-Time/Editor capable to do certain calls in whatever natives if "Engine.version >= 469" solving a lot of server-side/mapping problems. UT has even TIME functions left in natives (they were clocking a lot of stuff there) without many doors to UScript - all I want is opening some of these native "Doors to C++" declaring these in an add-on which can be accessed from UScript, Similar with XC functions "SetReachSpecs" "AddReachSpecs" and others for floors vertexes etc. At this moment I can read more data in Run-Time than in Editor and this is not making me very happy, I would like to see more data from reachSpecs in Editor not in run-time. I did all sort of stunts with paths but... I don't have everything like in C++ for writing a replacement for command "Paths Build". There is are needed to see more: Floors, Walls, Knee obstructions. UScript has NOTHING not even unlimited iterations in Editor which is BAD and out of logic. In some maps I cannot see duplicated actors if they have 10000 actors due to this dumb limitation which should not be there in Editor... I could do more without these limits - it's crashing without any valid logic.

Not the last thing is... DOCUMENTATION - wiki lacks in explanations for certain natives, there are assumptions - this is not the way.

These were ideas about extra-patching in 469 - the rest are ideas... off-topic here - fore mentioned bad assets have now replacements (I finished primary stage) for being used in the same maps - it's another story.

Letylove49
Average
Posts: 75
Joined: Tue Feb 28, 2012 7:47 pm
Personal rank: <[MHA] >Admin
Location: Retired

Re: ◄► Unreal Tournament v469a Patch Release ◄►

Post by Letylove49 » Wed Feb 17, 2021 2:26 pm

thank you for have fixed the client-side issue with MH mod who make fake spectators. this doesnt happening anymore with the patch 469b.
<[MHA]>Letylove49 aka Shado170