◄►469 Patch Discussions◄►

[Feralidragon]

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.

[sektor2111]

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]

thank you for have fixed the client-side issue with MH mod who make fake spectators. this doesnt happening anymore with the patch 469b.

[Buggie]

v469b released: https://github.com/OldUnreal/UnrealTour ... ses/latest

[Shrimp]

v469b released: https://github.com/OldUnreal/UnrealTour ... ses/latest

Woohoo

Release Notes link for the lazy.

[Neon_Knight]

YAY!

[Buggie]

You all already know it and therefore it's old news ...

Need update topic title from v469a to v469b.

Al other look like actual include link

[OjitroC]

You all already know it and therefore it's old news ...

Need update topic title from v469a to v469b.

Al other look like actual include link

Probably best to start a new thread? GIven that this is a new version of 469 and so comments made on 469a are redundant to a large extent.

[papercoffee]

You all already know it and therefore it's old news ...

Need update topic title from v469a to v469b.

Al other look like actual include link

Probably best to start a new thread? GIven that this is a new version of 469 and so comments made on 469a are redundant to a large extent.

Nah ...the Links are still up-to-date.
I've changed the Title.

[Gustavo6046]

Awh yeah! I was waiting for the day v469b would actually release.

[Buggie]

Awh yeah! I was waiting for the day v469b would actually release.

2 days ago.

The original release thread on Oldunreal.com
The thread with the first announcement

This links must be updated because oldunreal move to phpbb (finally!)

[Gustavo6046]

Awh yeah! I was waiting for the day v469b would actually release.

2 days ago.

Look, I got the news on the UT99.org Discord when they first came out, okay? I mostly paid attention to this thread when I noticed the title still had v469a in it (instead of v469b) and I told papercoffee about it.

Then I posted that reply when I remembered to remind people that I care about v469. :]

Also, let's just take a minute to appreciate how much diligence the moderator team of this website is capable of. A single letter in a title, prompts a person to put the effort of clicking the Edit button, rewriting the letter so it matches reality, and clicking Submit. It might not sound like a lot, but it does take being arsed to do it. And we are all lazy, aren't we? We're but humans!

All that because I told them about a little mismatching title i found while browsing UT99.org! Kudos to this awesome team

[papercoffee]

@Buggie
Links updated as well.

[Barbie]

Just for the record and without any judgement: I switched from 451 to 469b and noticed that duplicate actors are not detected by my code any more. This may mean that my code is not executed as before or that the loaded map does not contain any duplicate names.

code

Code: Select all

state FindDuplicateActors {

	function bool FindActorName(TDLLSB ActorListItem, string ActorName) {
	/******************************************************************************
	******************************************************************************/

		while (ActorListItem != None)
		{
			if (ActorListItem.DataStr == ActorName)
				return true;
			ActorListItem = ActorListItem.GetNext(false);
		}
		return false;
	}



	function TDLLSB FillActorList() {
	/******************************************************************************
	Returns a filled *ActorList*
	******************************************************************************/
	local TDLLSB result;
	local Actor A;

		foreach AllActors(class'Actor', A)
			result = class'TDLLSB'.static.AddData(self, result, A, A.Name);
		return result;
	}

begin:
	ActorList = FillActorList();
	if (ActorList != None)
	{
		ActorList = ActorList.GetFirst();
		Logger(LOG_Verbose, "state FindDuplicateActors", "Actorlist count=" $ ActorList.Count());
		while (ActorList.GetNext(false) != None)
		{
			if (FindActorName(ActorList.GetNext(false), ActorList.DataStr))
			{
				Logger(LOG_Error, "state FindDuplicateActors", "Duplicate Actor name for" @ ActorList.DataStr);
				ActorList = ActorList.GetNext(false);
			}
			else
			{
				ActorList = ActorList.GetNext(false);
				ActorList.GetPrev(false).Delete();
			}
			if ((ActorList.Count() & 15) == 15) // lets have 16 loops in a row
				sleep(0.001); // before taking a break
		}
		Logger(LOG_Error, "state FindDuplicateActors", "total amount of duplicate names:" @ ActorList.Count()-1);
		ActorList.DeleteAll();
		ActorList = None;
	}
	else
		warn("ActorList == None");
}

(TDLLSB is just a double linked list, derived from class'Object')

[Buggie]

My assumption: now server do not load duplicate actors. If it faced one it skipped all except first. (or last).

Currently I do not find way for check this. But I am in a progress.

--- EDIT ---

Spoiler

I see on Evelyn map on server Dice62. But on Editor such name not exists. So look like server rename all actors. And no duplicate name occurs.

I fear this destroy your patcher things based on actor names.

--- EDIT ---

Wrong. Client names different from server ones, so from client you must see different names.

--- EDIT ---

Server skip duplicate actors so no any duplicates exists.
For Evelyne map:

Code: Select all

Exists 1 'Dice1'
Exists 2 'Dice0'
Exists 3 'Dice2'
Exists 4 'Dice3'
Exists 5 'Dice4'
Exists 6 'Dice5'
Exists 7 'Dice6'
Exists 8 'Dice39'
Exists 9 'Dice8'
Exists 10 'Dice9'
Exists 11 'Dice10'
Exists 12 'Dice11'
Exists 13 'Dice12'
Exists 14 'Dice13'
Exists 15 'Dice14'
Exists 16 'Dice15'
Exists 17 'Dice16'
Exists 18 'Dice17'
Exists 19 'Dice18'
Exists 20 'Dice19'
Exists 21 'Dice20'
Exists 22 'Dice21'
Exists 23 'Dice22'
Exists 24 'Dice23'
Exists 25 'Dice24'
Exists 26 'Dice25'
Exists 27 'Dice26'
Exists 28 'Dice27'
Exists 29 'Dice28'
Exists 30 'Dice29'
Exists 31 'Dice30'
Exists 32 'Dice31'
Exists 33 'Dice32'
Exists 34 'Dice33'
Exists 35 'Dice36'
Exists 36 'Dice34'
Exists 37 'Dice38'
Exists 38 'Dice37'
Exists 39 'Dice35'
Exists 40 'Dice7'
Exists 41 'Dice40'
Exists 42 'Dice41'
Exists 43 'Dice44'
Exists 44 'Dice45'
Exists 45 'Dice43'
Exists 46 'Dice42'
Exists 48 'Dice46'
Exists 49 'Dice47'

As you see Dice 20 not duplicate anymore.

In editor I see 60 Dice. Max is Dice45. IDK from where Dice46 and Dice47.

--- EDIT ---

Dice46 and Dice47 from two Kralls which bDicePlayer = True and periodically throw and grab Dice.