XC_Engine version 25c for UT v469c (includes FerBotz)

[debilman69]

possible to have an ini or an empty server 469c with Last xc engine already mounted ?

[sektor2111]

Bump - I've done a little investigation. Trying XC25c for 469c under XP - it doesn't work. I can use 469c for a bit of testing and editing geometry, just as a clean UT base, for the rest I work with previous v24, that's all. Which means that I cannot update any sort of server because XC assets won't run.

[SC]-[WARTZ_{HoF}]

Seems not everything is compatible.

[sektor2111]

I have no clue about what and where is said compatibility/incompatibility...

ItDoesn_tWork.PNG (9.29 KiB) Viewed 1685 times

All I have to say is that I can work with prior versions in prior UT versions allowing me to polish "Levels" aka maps.
XC_EditorAdds_ 24 does some ugly paths (incompatible with run-time movement) but it comes that XC_PathsWorker (not recommended such UScript builder somewhere for no reason) can help in flushing fake paths. Yes, it was a problem at cutting Distance for a defined range. I thought that something it's bugged but nope, it was me (amnesia maybe), I simply forgot that paths in water are declared twice longer than their real distance. And then ? And then I had to update Builder and next month I'll drop it in public (after a plenty of testing).

I have no warranty about integrity and operation in this last version as long as results from 469c + XC 25c I pointed above. In other hand XC25b and 469b to me have no use. Builder does a sh!t load of PrunedPaths and doesn't follow "Range" rules for them. Actually method is changed because XC optimization causes paths pruning to not be needed and old stock code won't prune mainly anything.

[Higor]

Finally found some time and resources to pic kup v469 and XC_Engine in general again (working in cloud rendering and vulkan graphics in your 9 to 5 keeps you busy and burned out!), most of the future changes will be structural starting with how it's built.
There won't be much going to the public github repository yet but I'm running a full code audit and making certain ports of the entire XC_Engine codebase.

Because of that it's a perfect opportunity for feature requests or bug fixes.
I'll be enumerating some of the planned stuff and will add more as well, feel free to point out if any of the script compiler hooks is outdated or useless because I'm very interested in removing a lot of ancient and useless code.

And if you see any bot pathing issues in stock/bonus pack content, those may be fixed as well.

[DONE]
- (Win32) Move EditObject property window creator to XC_Core, no hard linking to Window.dll
- Remove 32 bit-only code (and ASM blocks)

[WIP]
- CMake build system (XC_Core and XC_Engine already ported)
- 64 bit Windows port (for fun, UT doesn't ship 64 bit Windows)
- Rewrite the script compiler hooks to not be version or platform dependent.
- Move Editor specific code to new XC_Editor.dll (needed to avoid linking XC_Core to editor)

[PLANNED]
- 64 bit Linux port.
- ARM64 Raspbian port.
- Cleanup various UnrealScript hooks (need feedback on what whacky stuff can be done here, serverside/local only though)
- (Editor) Parametrize Path Builder for more customization.
- Make a clone of LZMA server for UZ handling (v469 can fast compress UZ now, but channels can't download it yet)
- Turn the abandoned collision actors into UPrimitives (where changing a bool would enable such collisions on any actor)

[ShaiHulud]

That's timely, was just looking at XC_Engine again because the fast ViewClass (or however that's handled internally) switching would be a valuable resource on our 469 server. Glad you're getting back into it.

Finally found some time and resources to pic kup v469 and XC_Engine in general again (working in cloud rendering and vulkan graphics in your 9 to 5 keeps you busy and burned out!), most of the future changes will be structural starting with how it's built.

[Gustavo6046]

Can't believe I'm here again, but I'm still looking forward to the amd64-linux version lol. Might wanna build it in a separate System64 folder, both when building and when distributing, to avoid mix-ups and keep it neatly organized.

[fudgonaut]

Because of that it's a perfect opportunity for feature requests or bug fixes.

I would like to request updated / easy-to-follow install instructions for the next release, for XC n00bs like myself

Thank you Higor for all your hard work!

[a9902957@nepwk.com]

Great bot support for UTR / BRUT? ^_^
Or means to help with that (like less hardcoded item attraction [sure it's what makes them move around
in absence of objectives] but items / pathondes that are outside of the zone need to be made less attractive in those gamemodes, so some more easy hook to
realize that maybe).

[sektor2111]

PathNodes that are no supposed to be part of routing list can be simply deactivated similar to TranslocDest in games without Translocator, it's not needed anything else that stock UT. If game Mod is not that advanced that's another story. To not forget that a Navigation Node can be unlinked from Navigation chain using some smarter compiling solution (like in OldSkool, NaliWeapons, etc.).

[a9902957@nepwk.com]

Things is, it should not be a simple on/off situation.
More like just a higher price during A* pathing.
Because otherwise some bots would get stranded with no chance to get closer to the center of the zone again.

And as said you need to be able to make items outside of the zone much less (or not at all) desireable to the bots.

[sektor2111]

And as said you need to be able to make items outside of the zone much less (or not at all) desireable to the bots.

Are simple things so... complex ? Funny...
- Getting rid of them;
- Disconnecting them from their "marker";
- Replacing them with similar items with no desire - A Place-Holder item cloning mesh and skins but having no desire added and linked.

On Topic
- XC support - replacing desire function when item comes in "Zone".

Usually a mod needs A LOT of work before claiming it "Ready", "Brut" is not an exception.
XC_Engine doesn't have as purpose fixing lousy things but bringing a bit of help for polishing what is poorly coded.

The rest: XC_Engine will help only if you can hook only good things from it because XC_Engine itself needs completions and fixes. At least here is more freedom which doesn't exist in stock assets.

[ShaiHulud]

One thing that would be nice to have is some kind of a "PlayerDisconnected" event in the Mutator class. I've switched to other strategies for things like this, but still use a lot of packages that resort to polling in tick or timer to detect departed players.

[Higor]

One thing that would be nice to have is some kind of a "PlayerDisconnected" event in the Mutator class. I've switched to other strategies for things like this, but still use a lot of packages that resort to polling in tick or timer to detect departed players.

The GameInfo's logout catches every pawn considered a player leaving the game but unfortunately it does not dispatch and event.
Adding a mutator notification would be something that fits the actual game patch best, in XC_Engine you have a very different tool which is the script patcher.

There's a trick you can use to wrap any function while preserving original functionality which should work in any XC_Engine version:

// This code should be in a separate package, the client MUST NOT download this
// It uses XC_Engine.u as a dependency

Code: Select all

class GameInfoHookInstaller expands FV_Addons;

//
// Apply script patcher modifications
//
function ScriptPatcherInit()
{
    // Backup Logout onto our Logout_ORIGINAL
    ReplaceFunction( class'GameInfoHookInstaller, class'GameInfo', 'Logout_ORIGINAL', 'Logout');
    
    // Replace Logout with out wrapper
    ReplaceFunction( class'GameInfo', class'GameInfoHookInstaller', 'Logout', 'Logout');
}

//
// Contents of this hook
//
final function Logout_ORIGINAL( pawn Exiting )
{
    // No code here
    // XC_Engine will populate this with the contents of the original Logout function
}

function Logout( pawn Exiting)
{
    // This is the code that will wrap the original Logout function
    local ActorThatDetectsLogouts A;
    foreach DynamicActors( class'ActorThatDetectsLogouts', A)
    {
        A.PlayerLogoutEvent(Exiting);
        break;
    }
    Logout_ORIGINAL(Exiting);
}

Then open XC_Engine.ini, add a new entry to the GeneralConfig section:

Code: Select all

[GeneralConfig]
....
XCGE_Actors=MyGameInfoHook.GameInfoHookInstaller

   
Auto merged new post submitted 11 minutes later

---

The script compiler hook had to be reimplemented entirely ... adding code into v469d
Although I have to say this means modders have access to a couple more script compiler features without needing XC_Engine.

The script parser will prioritize this class over other non-super classes
This will probably never be of use to you

Code: Select all

class TestClass expands Object
    dependson(Priority);

This class can be used to define an interface
On its own it has no use

Code: Select all

class ExtendedPawnInterface expands Pawn
    abstract;
    
// You must not define any variables
    
function FancyCodeThatRunsOnAnyPawn(etc)    
{
    //....
}

And this class can call the function from the above class on any pawn, by importing it as an interface

Code: Select all

class TestClass expands Actor
    imports(ExtendedPawnInterface);
    
event PostBeginPlay()
{
    local Pawn P;
    foreach AllActors( class'Pawn', P)
        P.FancyCodeThatRunsOnAnyPawn();
}

   
Auto merged new post submitted 1 minute later

---

This is not going to release at the same time as v469d, some the very same uscript code that improved bot behaviour that was running in v469c stopped working in v469d. And that'll take some debugging.

[ShaiHulud]

Thanks Higor, that's extremely helpful.