XC_Engine version 23 full

Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

XC_Engine version 23 full

Post 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.
Attachments
XC_Engine_Full_23.7z
See Documentation\Readme.txt
(726.05 KiB) Downloaded 568 times
Last edited by Higor on Tue Jan 29, 2019 1:22 am, edited 2 times in total.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine version 23 full

Post 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 ?
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine version 23 full

Post 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;
}
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine version 23 full

Post 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.
Attachments
OneWayNote.PNG
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine version 23 full

Post 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.
rdy2bz
Novice
Posts: 22
Joined: Thu Nov 26, 2015 11:42 am

Re: XC_Engine version 23 full

Post 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?
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine version 23 full

Post 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.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine version 23 full

Post 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:
rdy2bz
Novice
Posts: 22
Joined: Thu Nov 26, 2015 11:42 am

Re: XC_Engine version 23 full

Post 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.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine version 23 full

Post 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'.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine version 23 full

Post 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 ?
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine version 23 full

Post 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.
Attachments
Wrong_Specs_01.PNG
Wrong_Specs_00.PNG
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine version 23 full

Post 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.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine version 23 full

Post 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.
Attachments
MainOriginalDev.PNG
User avatar
Deepu
Adept
Posts: 350
Joined: Mon Nov 11, 2013 7:56 am
Personal rank: Average
Location: India
Contact:

Re: XC_Engine version 23 full

Post 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?
Post Reply