XC_Engine [20] - XC_Core [7b] - XC_IpDrv

[sektor2111]

I have unlocked some XC_IpDrv.XC_HTTPDownload properties for being visible/configurable. I found some news. Are they operational ? If yes, how goes the syntax ?

[attachment=0]XC_IpDrv.JPG[/attachment]

[Higor]

That's a hack'ish option for clients playing behind proxies.
That allows you to add an arbitrary string in the HTTP request, good enough to simulate an auth request of any kind if you know how to.

[sektor2111]

Okay, a few words about Dark Side of the SCHforze...

Went busy chatting and testing whatever NewNet. Apparently looking functional

Code: Select all

ScriptLog: Login: Nelsona
Log: Possessed PlayerPawn: bbTFemale1 DM-FraggaloniaHoliday.bbTFemale0
DevNet: Join succeeded: Nelsona
ScriptLog: Nelsona ModMenuItem: MultiMesh.MultiMeshMenu False
ScriptLog: Nelsona ModMenuItem: AdvSetGUI.AdvSetGUI_ModMenu False
NetComeGo: Close TcpipConnection0 12/11/16 18:17:27

However, a session with XC_Engine - I'll quote a few "funny" lines

Code: Select all

ScriptLog: Attempted to use illegal skin from package FCommandoSkins for FCommando
ScriptLog: Failed to load FCommandoSkins.daco1 so load FCommandoSkins.cmdo1
ScriptLog: Failed to load FCommandoSkins.daco4Tanya so load FCommandoSkins.cmdo4
ScriptLog: Failed to load FCommandoSkins.daco4Tanya so load FCommandoSkins.cmdo4
ScriptLog: Failed to load FCommandoSkins.cmdo1T_1 so load FCommandoSkins.cmdo1
ScriptLog: Failed to load FCommandoSkins.cmdo1T_1 so load FCommandoSkins.cmdo1
ScriptLog: Failed to load FCommandoSkins.cmdo2T_1 so load FCommandoSkins.cmdo2
ScriptLog: Failed to load FCommandoSkins.cmdo2T_1 so load FCommandoSkins.cmdo2
ScriptLog: Failed to load FCommandoSkins.cmdo1 so load FCommandoSkins.cmdo1
ScriptLog: Failed to load FCommandoSkins.cmdo1 so load FCommandoSkins.cmdo1
ScriptLog: Failed to load FCommandoSkins.cmdo4 so load FCommandoSkins.cmdo4
ScriptLog: Failed to load FCommandoSkins.cmdo4 so load FCommandoSkins.cmdo4
ScriptLog: Attempted to use illegal skin from package FCommandoSkins for FCommando
ScriptLog: Failed to load FCommandoSkins.cmdo1T_1 so load FCommandoSkins.cmdo1
ScriptLog: Failed to load FCommandoSkins.cmdo2T_1 so load FCommandoSkins.cmdo2
ScriptLog: Failed to load FCommandoSkins.cmdo2T_1 so load FCommandoSkins.cmdo2
Log: Possessed PlayerPawn: bbTFemale1 DM-FraggaloniaHoliday.bbTFemale0

Lines triggering me in being 10 times confused

Code: Select all

ScriptLog: Failed to load FCommandoSkins.cmdo1 so load FCommandoSkins.cmdo1
ScriptLog: Failed to load FCommandoSkins.cmdo4 so load FCommandoSkins.cmdo4
ScriptLog: Failed to load FCommandoSkins.cmdo4 so load FCommandoSkins.cmdo4

It sounds like I don't have RED but we load RED.
I don't know what's wrong but for sure without XCGE these things doesn't exist.

I have started a test server with ActorCLP. Other way seems not that friendly with NN things...

[Higor]

Way ahead of you, check this pull request:
https://github.com/CacoFFF/NewNet-for-U ... 7d947ccb33

[sektor2111]

Btw, NewNet ruins teleporters, Bot won't use them any more... lol... NewNet...

Probably will be recommended a code suggestion for properly replacing them without to mock A.I.

[Chamberly]

Newnet have a lot of weird settings. It was seen to only designed to work with stock (or almost) stock actors and if anything else, may not work or may will.
I'm not too tempted to have XC_Engine with newnet based on a hasty experience before lol. But I guess I'll try it again in a few and start writing up things.

[sektor2111]

At a moment I had in mind a sort of "NewNet" like I did with "Push-Old-Weapon" but I'm not that sure about this as being so easy... Anyway, Teleporter in NewNet for me is a NO GO, I think I can "disable" a teleporter without to mess navigation around if I have to spawn an alternate Teleporter. This way in fixing never fascinated me, eh...

Now I understand what's the problem; XCGE works for a good UT server, "Players" wants NewNet because in old times we were playing on a smoother Internet than nowadays, LOL stupid NFS crap - in 2016 we speak about GigaByte Net but still messing customers with stupid lags. Then, NewNet is a mess in how many errors are left everywhere and this doesn't help XCGE at all.
So... stabilizing a server and running NewNet are different things, they don't like each-other.

[Chamberly]

True. There are still plenty of bugs occurring in NewNet including some tweaks that allows players to take advantage in the game.

[sektor2111]

ConnectionHandler, TickSpy and all those things having bAlwaysTick seems to block IpToCountry after a short life especially when we are mixing all sort of Pawns.

After removing ConnectionHandler, IpToCountry works more time, even after killing some creatures, later it will not respond at mutate command but it do seems to live longer. This http based tool looks affected by aggressive ticks, it's all I have to say about Country magic.

I'll do a revision at server stuff which I'm using with heavy ticks and probably I'll send them to a state code...

[sektor2111]

I'm currently using this one - Probably I'll rewrite with original one because this iterator is being already in "killed" somewhere, so it's pointless if creature did not see enemy in that time, to see something a few milliseconds later - just increasing iterators useless.

Code: Select all

function Tw_WhatToDoNext(name LikelyState, name LikelyLabel)
{
	local Pawn aPawn;
	local bool bEnemyFound;
/*
	aPawn = Level.PawnList;
	while ( aPawn != None )
	{
		if ( aPawn != Self && !aPawn.bHidden
			&& aPawn.bCollideActors && aPawn.DrawType == DT_Mesh
			&& aPawn.Mesh != None && LineOfSightTo(aPawn) )
		{
			if ( SetEnemy(aPawn) )
			{
				GotoState('Attacking');
				GoTo NoFurtherAction;
			}
		}
		aPawn = aPawn.nextPawn;
	}
*/
	foreach VisibleCollidingActors (class 'Pawn',aPawn,1000,Location,True )
	{
		if ( AttitudeTo(Apawn) < ATTITUDE_Ignore && aPawn.Mesh != None
			&& aPawn.bCollideActors && aPawn.DrawType == DT_Mesh && aPawn != Self )
		{
			LastSeenPos = aPawn.Location;
			Enemy = aPawn;
			Hated = aPawn;
			bEnemyFound = True;
			break;
		}
	}
	if ( bEnemyFound && !IsInState('Attacking')) //Trying to prevent recursive attack if already attacking
	{
		GoToState('Attacking');
		GoTo NoFurtherAction;
	}
	bQuiet = false;
	Enemy = None;
	if ( OldEnemy != None )
	{
		Enemy = OldEnemy;
		OldEnemy = None;
		GotoState('Attacking');
	}
	else if (Orders == 'Patroling') 
		GotoState('Patroling');
	else if (Orders == 'Guarding')
		GotoState('Guarding');
	else if ( Orders == 'Ambushing' )
		GotoState('Ambushing','FindAmbushSpot');
	else if ( (LikelyState != '') && (FRand() < 0.35) )
		GotoState(LikelyState, LikelyLabel);
	else
		StartRoaming();
NoFurtherAction:
}

If a single time will crash I'll remove all sh!t out replacing with original code because this berserk code has no meaning really. It is being executed see the rest of codes + we have a long story involving Pawnlist chain multiple times:
Pawn Died >
ScriptedPawn Killed >
WhatToDoNext >
All these are crapping out iterations - and NO this UT Engine is not helped by a stronger CPU at this chapter - more fine tuning and speed at codes = more chances to develop iterations because... engine has a new time for them.
An old doc was saying about: stronger CPU technically heads to more actors handled in U Engine. I think it was speaking about barrels, lamps and the rest of "nothing-executed" stuff . Because Handling more pawns is a story for kids - it's not hard to reach at limit especially with a faster CPU.

Edit:Just a quick note. If pawn has an enemy set in function killed and it is attacking, then this new iteration doesn't make sense...
Edit2:Other fact. If pawn did not see a nearby enemy after killing something, for sure repeating what it was looking for doesn't make sense, it's just increasing iterations count affecting the rest of things and adding another useless processing. Whoever is using this type of code for any scriptedPawn child it is only causing a bad time - those "pawns" are just trash rewritten and not fixed.
The only "better" berserk occurrence it's happening in case when Pawn is hunting for a very long time (Hunting - PickDestination). It will quit tracking enemy doing another thing VIA "WhatToDoNext".
If map is very "smart", pawn won't reach in any NavigationPoint then PickDestination won't get called (unless pawn falls, hits a wall or such) - PickDestination is used when pawn has reached somewhere and it will be interested for Next "Step".

[Higor]

Proudly announcing two big upgrades for v19

XC_PathBuilder actor
Available for Unreal Editor, when inserting this actor into the map a full path rebuild will run (status box doesn't appear).
This path rebuild will follow these particular rules

- Max scan distance changes from 100 to XC_PathBuilder.MaxScanRange (set in default properties via editor)
** Increasing scan distance may make path pruning impossible.
** Make sure you keep node distances consistent across the ENTIRE map.

- InventorySpot class changes from InventorySpot to XC_PathBuilder.InventorySpotClass (set in default properties via editor)
- InventorySpot paths that are visible in the editor aren't removed.
- Inventory items that aren't visible in the editor don't get a InventorySpot marker
** Object groups can be used to quickly hide batches of items that aren't intended to receive InventorySpot markers.
** If you rebuild paths once, then hide the item and show the InventorySpot marker you can 'manually' keep this marker on this item without being touched by the path rebuilder, this is useful to force a connection onto this individual marker.
- The 'Event' field of any NavigationPoint actor will force a direct connection to any other NavigationPoint whose Tag or Name matches.



SuperClass replication flag
Actors get a new network variable named bSuperClassRelevancy which needs to be set using SET or SetPropertyText(string,string).
When an actor type that isn't in the network translation table (not specified in ServerPackages) and this flag is set to True, the game will attempt to use the nearest available base/super class of said actor to send to clients.
**XC_Engine.bUseNewRelevancy=True is a required option.
**SuperClassRelevancy will fail to replicate an actor if all of it's super classes are either abstract or not in the network table (ServerPackages).

Example:
- Subclass monster Queen into QueenExtra and add a few more AI variables to improve behaviour/combat.
- Make sure said QueenExtra has bSuperClassRelevancy=True set (either via default SET or SetPropertyText on spawn)
- Do not setup the package QueenExtra resides in as a ServerPackage
- Spawn the monster in a XC_Engine v19 server with bUseNewRelevancy=True
- All clients will receive a default 'Queen' instead of not receiving anything.


This feature even works with a client's main player, you can totally replace their player pawn serverside without them noticing.
Will be using this to make FerBotz run online without the need of dummy pawns or weird replacements.

[sektor2111]

From where do I download these ?

[Chamberly]

To anyone out there that don't know how to set this up, we can set it up for you. Just send me your ini and I'll give it back to you.

Tutorials being added...
Installing on server -
https://sites.google.com/site/ut99gotyd ... stallation
With 451 patch, you can still use it for any other patch but you would have to read carefully what to set up.

Installing on client -
https://sites.google.com/site/ut99gotyd ... nt-install

I'll have an advanced setting set up later.

If anyone have any question, let me know and I can help you with anything.

Edit: Medor has updated his hosting website. http://unrealtournament.99.free.fr/utfi ... XC_Engine/

[sektor2111]

I'm curious if XC_Pathbuilder is ready to rock...

[Higor]

Version 19 update.

XC_Core 7 is required.

Relevancy loop priority uses faster sorting algorithm and has additional flags.

XC_PathBuilder actor for unreal editor.

Patched various server exploits.

Created class XC_Engine_Actor:
- Spawned automatically at map start (before InitGame).
- Can spawn derivates of this type of actor depending on loaded gametype, useful for modifications.
- Contains useful code for serverside/local function replacement in runtime.
- Added DynamicActors native.
- Added PawnActors native (from FerBotz).
- Added NavigationActors native (from FerBotz).
- Added InventoryActors native.
- Replaces buggy/spammy script functions (engine/core) in the original game.
** Almost all of the hardcoded features have been ported to this system.
** Most notably the PreLoginHook.
- Added reachspec/path manipulation capabilities.

Added XC_Engine_UT99 package, with XC_Engine_UT99_Actor (derivate of XC_Engine_Actor)
- Replaces script functions (unreal/unreal tournament).
- Improves bot navigation in:
** DM-Agony
** DM-ArcaneTemple
** DM-Bishop
** DM-Deck16][
** DM-Liandri
** DOM-Bullet
** DOM-Cinder
** DOM-Ghardhen

Added new documentation: XC_PathBuilder, Relevancy loop.