Page 1 of 2

XC_Engine version 23 full

Posted: Fri Jan 25, 2019 4:01 am
by Higor
Full XC_Engine package.

You may check the documentation under each project's specific directory at https://github.com/CacoFFF/XC-UT99
XC_Core 9b changes
XC_Core version 9b update.

== FOutputDeviceInterceptor
Log interceptor no longer reset every second on listen servers (due to window title events).


== Codebase

>> Linux
Removed unused Editor code, smaller binary.
Downgraded library requirements for CacusLib. (C++14 features no longer needed)

>> Windows
Fixed broken commandlets.
Fixed a case of bad SSE instructions introduced by compiler upgrade affecting UT's network timing.


== Editor

>> Rendering
When XC_Core is loaded into Unreal Editor, the path network will be rendered differently.
Paths will be visualized in two lines (inbound + outbound) and each will contain an arrow head to
indicate their direction.

The reachspecs will be color coded as following:
- WALK/SWIM >> GREEN
- JUMP >> YELLOW
- AIR >> RED
- BLUE >> SPECIAL

>> Paths Builder.
The new Paths Builder has been rewritten from scratch to address limitations in the original pathing code.

Every pair of Navigation Points are sorted by distance prior to creation of reachspec.
This allows the builder to start with the shortest route first and completely ditch the path pruning
process which makes some path networks build faster due to the builder deciding to discard a reachspec
BEFORE it's built.

The new criteria to ignore routes is more aggresive at shorter distances which prevents
overcrowding of reachspecs in places full of Navigation Points (ex: areas full of items).
The theoretical maximum distance is 2000, but it may be lower in specific areas/routes.

Inventory and Warp Zone markers are more likely to be added near their respective object, during the
addition process if the marker doesn't initially fit the object's spot, then a walk simulation is run
from nearby paths into the objects to determine best possible spot for the marker.

The builder allows the mapper to choose whether the builder builds air routes or not, and to change
the reference pawn used to create the paths, which affects jump, movement and size.
* Insert the reference pawn in the level (hide it), add a Tag to it, then match it in the builder.

As usual, InventorySpot actors that are not hidden in the editor won't be removed during a rebuild and
setting a NavigationPoint's Event to another one's Tag will create a special reachspec from first to second.
XC_Engine 23 changes
=============================
=== 23 update:

Advanced relevancy:
- Fixed broken channel timeout code in windows.
- Bandwidth saving hack (Rotation) applied to all actors now.
- Bandwidth saving hack (Location) improved for pawns, movement just as smooth as original netcode.
- When viewing a player through F5, you no longer receive his/her entire inventory chain.
- Small improvements in performance scalability as player count increases.

Raw input (windows):
- Added MouseX1 and MouseX2 support, bound to Unknown05 and Unknown06.

Editor:
- Removed XC_PathBuilder actor, see XC_Core 9b documentation for its replacement.

Script patcher:
- Native functions with numbered opcodes can now be replaced by pure UnrealScript functions.
* See Pawn.PickTarget() replacement in XC_Engine_UT99.XC_ScriptedPawn.Pawn_PickTarget()
** Example: Rocket launchers don't lock onto Nalis, Team Cannons and Siege builds.
- ACE isn't loaded when the server is on Unreal 1 game modes (prevents crashes on clients)
Note: file replaced due to a bug in the path builder.
If you're using the path builder, redownload the package.

Re: XC_Engine version 23 full

Posted: Fri Jan 25, 2019 7:22 am
by sektor2111
doc... wrote: If Navigation Points still fail to connect when on ramps or stairs, consider moving the node closer to
the ground or using Event >> Tag linking.
Add:
1. Make sure about a navigable ramp angle - we should be able to climb there.
2. Make sure about ramp node if can be "taken" - avoid useless ramp nodes like CTF-Command has. That one is only damaging rather than helping.


Github visit

Code: Select all

if ( ReferenceTag != '' )
		ForEach LI.AllActors( class'Pawn', P, ReferenceTag)
		{
			ScoutReference = P;
			break;
}
Questions:
a. If I won't touch this who is the reference ? Default Scout or a specific internal "GunLock" type Scout ?
b. Can I use here a fly-capable pawn - Custom Scout ?

Re: XC_Engine version 23 full

Posted: Fri Jan 25, 2019 8:00 am
by Higor
You should never manually use a Scout in editor, hence the 'reference'.

The reference is that, a set of non-default collision and movement values as seen below.
You can insert the reference pawn somewhere it doesn't affect gameplay and simply use it to modify the scout's behaviour.
Aerial build depends on a different setting.

Code: Select all

FString PathsRebuild( ULevel* Level, APawn* ScoutReference, UBOOL bBuildAir)
{
	FPathBuilderMaster Builder;
	if ( ScoutReference )
	{
		Builder.GoodRadius      = ScoutReference->CollisionRadius;
		Builder.GoodHeight      = ScoutReference->CollisionHeight;
		Builder.GoodJumpZ       = ScoutReference->JumpZ;
		Builder.GoodGroundSpeed = ScoutReference->GroundSpeed;
	}
	Builder.Level = Level;
	Builder.Aerial = bBuildAir;
	Builder.RebuildPaths();
	return Builder.BuildResult;
}

Re: XC_Engine version 23 full

Posted: Fri Jan 25, 2019 8:42 am
by sektor2111
Higor wrote:You should never manually use a Scout in editor, hence the 'reference'.
I use it only in builder's task and is removed at end of whatever process. No map will ever have such thing at saving stage.
Now I'm going to crawl some maps, would be interesting to know the content...
A big THANK YOU !.

Edit: NOTES
bOneWayPath is being ignored sometimes by all DEVS (XC and original) at LiftExit nodes.
[attachment=0]OneWayNote.PNG[/attachment]
First LiftCenter2 (bottom) has indeed One-Way as I wanted, the next one LiftExit3 has Two-Way even if setup is for bOneWayPath, paths here are working as on purpose because of that first Point but... it's good to know - now this can be seen more clear.

Re: XC_Engine version 23 full

Posted: Sun Jan 27, 2019 8:11 am
by sektor2111
Another note for DevPath.
As long as I still can see created VisNoReachPaths which I think have no purpose ( MBot uses them randomly if I well recall ) I'm willing to remove all of them from all paths networks which I might do. I'm talking about building paths with aerial directives.

Re: XC_Engine version 23 full

Posted: Mon Jan 28, 2019 10:03 pm
by rdy2bz
Thanks for all those work you put into this!

MouseX1 and X2 don't work on my Linux system. As far as I've seen from the github project files, this is a Windows-only thing. Do you have any plans to support this under Linux eventually?

Re: XC_Engine version 23 full

Posted: Tue Jan 29, 2019 12:52 am
by Higor
If I learn more about Linux native launcher I may be able to do something about it.

Btw, if you use the Path Builder you want to redownload the stuff, removed a lot of log spam and a critical bug with teleporters.

Re: XC_Engine version 23 full

Posted: Tue Jan 29, 2019 7:20 am
by sektor2111
XC_Core.dll ? Good, I replaced it - that one seems the last updated file.
Edit:Confirmation.
Yes, I could figure the bug a few minutes ago... but term "critical" is a bit too abrasive - I think more suitable it's "educative", I could get used with it... protecting map against future "fixes" - but that bug gave me an idea 8) even if it's fixed and works properly, I can simulate something like this even after a debate with original Lord Goblin... :mrgreen:

Re: XC_Engine version 23 full

Posted: Sun Feb 03, 2019 11:04 am
by rdy2bz
Higor wrote:If I learn more about Linux native launcher I may be able to do something about it.
In the meantime - it works flawlessly with wine.

Re: XC_Engine version 23 full

Posted: Mon Feb 04, 2019 7:12 pm
by Higor
Well, UT's uses X11 on it's linux port.
And looking at the available sources on it (do they reflect the actual build from Loki?), we'd need to see if the current code can map MouseX1 and MouseX2 without major hooks.
Next step would be to find out how X11 input grabs those two 'keys'.

Re: XC_Engine version 23 full

Posted: Thu Feb 07, 2019 9:52 pm
by sektor2111
I don't know exactly how do other systems work but in my system I see UT_Eightball (and childs) no longer picking a target after this XC replacement. I did a configurable module and I disabled this tweak. XC function doesn't do any PickTarget for any potential pawn-target. Did anyone figure this or it's just only my problem ?

Re: XC_Engine version 23 full

Posted: Wed Mar 06, 2019 7:09 pm
by sektor2111
XC_EditorAdds bump - toward XC_Core version 9 and XC v23

I will split Editor in two pieces as follows:
- Piece 1 - using XC_Engine v21 for Mapping Paths and setting up all pathing party due to options for InventorySpot and RANGE because...

- Piece 2 - using XC_Engine v23 is very good at debugging - the range of creating reachSpecs is hilarious and made FAKE reachable spots regarding to Scout types which I used for mapping paths - testing a bunch of combinations. This thing is good for cubed big maps not for types where jumps should be computed properly. MH-DeepHallways is a sample of map where you can have great paths in tunnels but that bridge has a lot of IMPOSSIBLE jumps even if my Scout was jumping 200 height and having 250 groundspeed - slow pawn with weak movement capabilities still claiming reachable specs. DevPath was not doing really good paths at exiting from water but MORE walking routes which NO ONE will ever navigate over water from land to wooden bridge requiring a really big jump. I wanna see a sample of such a map where reachSpecs are added properly without shortcuts that are useless.
Definitely I don't like those Aerial paths with "ground" specifications.
Case 1 PlayerStarts higher
It's impossible to have these when you jump 200 - see yellow lines between playerstarts - they are entirely wrong. Location is much over ground, Scout cannot jump there, how is possible to do such a travel using Walk-Jump for reaching at them ? Let me see: It's impossible - end of story.
[attachment=1]Wrong_Specs_00.PNG[/attachment]

Then if I take in account wooden bridge, take a look at these:
[attachment=0]Wrong_Specs_01.PNG[/attachment]

Did I miss some hidden trick ?

Which means I have to update MapGarbage version with extra preparing pre-pathing stage with hiding items (ammo and items closer each-other) from Scout during calculations and preventing extra reachspecs which are not needed, then executing a removal of ALL PrunedPaths[0-15] in order to be used with XC_Engine v21.


A new optimization has benefits but I think physics calculation right over here are myths.

Re: XC_Engine version 23 full

Posted: Wed Mar 06, 2019 7:23 pm
by Higor
The new path builder requires a new way of placing navigation points.
It's not a matter of rebuilding and that's it.
In the meantime, I'll look at the 'jump' code.

Put a path node below those player starts if you're worried bots not being able to use the nearest reachable path as start anchor.

Re: XC_Engine version 23 full

Posted: Wed Mar 06, 2019 9:14 pm
by sektor2111
Hiding them during build (playerStarts) has good consequences but not the Water problems. They are trying to get shortest routes with impossible jumps when those specs have no jump defined, look well at second image. Better result are if PathNode are way higher causing Aerial links which Bot is not taking else default DevPath by orienting a single node as bOneWayPath returns this:
[attachment=0]MainOriginalDev.PNG[/attachment]

All main paths are going over bridge but they have option for moving out of water in case of some battle boosting and jumping in water at will. A bit lowered, a bit moved around, and paths are what I wanted. Else right here PreviousPath crap is NONE in all points, all PrunedPaths have been manually deleted, and they are not looping nowhere...

Edit: A mitigation - by putting lower water surface I got really better results, but I still misunderstand those default walking specs when clearly those should be Walk-Jump. Level Size went from 608 kb to 496 kb.

Re: XC_Engine version 23 full

Posted: Fri Mar 08, 2019 12:22 pm
by Deepu
This version is not working with Linux machine...

Code: Select all

Executing Class Engine.ServerCommandlet
Signal: SIGIOT [iot trap]
Aborting.
Exiting.
Name subsystem shut down
Allocation checking disabled
Still needs any library?