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

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

Postby Chamberly » Sat Jan 06, 2018 1:50 am

I do need to update that tutorial for the new stuff and other that I have not included.

Feel free to let me know what I should include making it easier. A simple PM will do and once I have it updated I'll post some update on this reply.
Image
Image
irc.globalgamers.net #uscript
http://irc.lc/globalgamers/uscript
Image
User avatar
Chamberly
Godlike
 
Posts: 1580
Joined: Sat Sep 17, 2011 4:32 pm
Location: TN, USA
Personal rank: Dame. Vandora

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

Postby Higor » Mon Jan 15, 2018 11:34 pm

After some tests I'm gonna have to move the converter code into a yet another package, starting from release build.
XC_Core should be loadable in all possible UT instances, and some Linux servers don't have Editor.u in them.
I have to be very careful of what dependencies each XC_Core has, by keeping it dependant on only Core and Engine it'll take far less time to load and stay compatible with TacticalOps.

The good thing is that nothing will be broken if the converter is moved into a separate package, instead you'll just have to add anothe EditPackage to the editor engine.
And that package could be extended with more native/special builders.

And before moving on from the converter, has anyone managed to succesfully build something of use with it?
Got any maps with these new decorations?
Higor
Godlike
 
Posts: 1571
Joined: Sun Mar 04, 2012 6:47 pm

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

Postby Higor » Wed Jan 17, 2018 4:06 am

If I'm gonna move the builders outside of XC_Core.u, I might as well make this new package contain a lot more useful tools.
In this case, added a shortcut to the XC_PathBuilder which is easier to setup.

I may add an extra button something that will fill a line between two distant NavigationPoints with PathNodes at the maximum possible distance, good for pathnoding maps with long tunnels in just minutes.
I also have something in mind that would allow the mapper to build brushes with ANY shape...

PathShortcut.PNG



=============
This is possible thanks to XC_Core's natives!
//====================================================
// XC_Engine path rebuilder shortcut
//====================================================
class PathRebuilder expands BrushBuilder;

var() class<InventorySpot> InventorySpotClass;
var() float MaxScanRange;

event bool Build()
{
local LevelInfo LI;
local class<Actor> AC;

ForEach class'XC_CoreStatics'.static.AllObjects( class'LevelInfo', LI)
if ( !LI.bDeleteMe )
break;

AC = class<Actor>( DynamicLoadObject("XC_Engine.XC_PathBuilder",class'Class') );
if ( AC == None )
return BadParameters("Unable to load XC_Engine.XC_PathBuilder");

if ( InventorySpotClass == None )
InventorySpotClass = class'Engine.InventorySpot';

LI.ConsoleCommand("set xc_pathbuilder inventoryspotclass "$InventorySpotClass.Name);
LI.ConsoleCommand("set xc_pathbuilder maxscanrange "$MaxScanRange);
LI.Spawn( AC);

return BadParameters("Paths rebuilt [Dist="$int(MaxScanRange)$"]");
}
Higor
Godlike
 
Posts: 1571
Joined: Sun Mar 04, 2012 6:47 pm

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

Postby sektor2111 » Wed Jan 17, 2018 7:29 am

Higor wrote:Got any maps with these new decorations?
Nope, I was trying to do a box which resulted in a box with texture scale in default size screwing box. Another time I was trying to do a lamp from a brush using a MyLevel texture and some funky stuff was showing up, another time worked with some decoration pillar part using stock textures... I got used with MeshMaker for doing run-time "mapping". I need time to figure what's the whole deal.

XC_PathBuilder
Oh, well, this is a default like stuff for latest maps fixes/adds which I did, and this is what I used in MH-Sk_BattlingLottery.

I had some questions about run-time paths where I did not see more answers, so I went to other research for figuring what's the deal with that stuff by myself because I did not see other participants at debates. What I could figure so far:
- New nodes have to be registered with that native into Network and they have to be spawned - never bStatic;
- New nodes need a trace check and reaching capabilities test using some "cute scout" else small spots are not linked;
- New nodes needs special child classes because doors will not allow links in Run-Time - only in Editor where mover is like None - these nodes will need a short link range for preventing dumb things because are brute forced with no reach testing;
- New Nodes can get links even "very late" - I don't need prebegin postbegin here to load iterators;
- New Nodes I think can get links even triggered in a later game moment (for preventing dumb roaming) - I have to try/do this when situation recommends this - did not do yet;
- I had to build some small tool-mutator that I use at random in game in order to spy heavy loaded InvSpots which I might fail to see in Editor due to the stupid initial load and to attack new paths with toggling tools needed later in game and figuring their location/name for blocking/unblocking them - I did not do any default PathSwitcher - doesn't look like it's necessary - even a default PathNode can be locked/unlocked based on a map event being tracked by whatever keypoint;
- Evil Nodes from map which have to be discarded will need some testing around as long as the spot unlocked from Network is not always the best ever deal, it looks like such a node will have problems if we want it connected different a bit later discarding old connections or I've failed to figure the deal in changing paths with it;
- if map it's really BAD not even the father and the God of run-time paths will not help here - sample can be one of those 24h build time taken maps creating useless Levels for A.I. and even for human player as long as I did not see them that popular because they are beyond engine boundaries.
User avatar
sektor2111
Godlike
 
Posts: 3284
Joined: Sun May 09, 2010 6:15 pm
Location: vect(1,1,1)

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

Postby Higor » Wed Jan 17, 2018 8:57 pm

XC_Engine will be able to better manipulate HTTP downloaders.
It will do so by either removing the unnecessary IpDrv downloader, or by upgrading it to XC_IpDrv.
I noticed that XC_Engine clients will be able to access TWO redirect servers if the addresses for IpDrv and XC_IpDrv are not the same.
Spoiler: show
DevNet: PendingLevel received: DLMGR CLASS=XC_IpDrv.XC_HTTPDownload PARAMS=http://***/ COMPRESSION=1
DevNet: PendingLevel received: DLMGR CLASS=IpDrv.HTTPDownload PARAMS=http://***/ COMPRESSION=1
DevNet: PendingLevel received: DLMGR CLASS=XC_Core.XC_ChannelDownload PARAMS=Enabled COMPRESSION=1
DevNet: PendingLevel received: DLMGR CLASS=Engine.ChannelDownload PARAMS=Enabled COMPRESSION=0
DevNet: PendingLevel received: XC_ENGINE VERSION=20
DevNet: Welcomed by server: WELCOME LEVEL=CTF-BT-(B)Distanc3_nb2 LONE=0
DevNet: Removing DownloadInfo(1) due to redundancy with XC version
Log: [XC] Resolving ***...
DevNet: Receiving package 'CTF-BT-(B)Distanc3_nb2'
Log: [XC] Resolved *** (***)
DevNet: [XC] Requesting: http://***/CTF-BT-&#40;B&#41;Distanc3_nb2.unr.lzma
DevNet: Compressed filesize: 916810
Log: [XC] Resolving ***...
DevNet: Receiving package 'ACEv10e_Cdll'
Log: [XC] Resolved *** (***)
DevNet: [XC] Requesting: http://***/ACEv10e_Cdll.u.lzma
DevNet: [XC] Requesting: http://***/ACEv10e_Cdll.u.uz
DevNet: [XC] Requesting: http://***/ACEv10e_Cdll.u
DevNet: Package not in redirect, switching to next download method

The log prints less crap and actually informs of what's going on, the redirect timeout can be changed (defaults to 4 seconds) and the INI entries are autogenerated if you download at least one file.
I was thinking with writing a GUID validator to run post-download, and to not mark the package as 'downloaded' if it fails.

sektor2111 wrote:Nope, I was trying to do a box which resulted in a box with texture scale in default size screwing box. Another time I was trying to do a lamp from a brush using a MyLevel texture and some funky stuff was showing up, another time worked with some decoration pillar part using stock textures... I got used with MeshMaker for doing run-time "mapping". I need time to figure what's the whole deal.

Try enabling the texture tiling, it'll subdivide the faces into squares.
It's not perfect but it'll work wonders with terrains and other meshes that use small textures.
You should always use the final textures on the mesh, not placeholders.

sektor2111 wrote:- New nodes have to be registered with that native into Network and they have to be spawned - never bStatic;

Nodes ALWAYS have to be on the NavigationPointList chain, no exceptions.
That's why XC_Engine_Actor.LockToNavigationChain() is there.

sektor2111 wrote:- New nodes need a trace check and reaching capabilities test using some "cute scout" else small spots are not linked;

Linking is 100% arbitrary, you can link two nodes even if they're not visible and their distance is 60000.

sektor2111 wrote:- New nodes needs special child classes because doors will not allow links in Run-Time - only in Editor where mover is like None - these nodes will need a short link range for preventing dumb things because are brute forced with no reach testing;

The brush tracker will turn doors into BSP, your traces will only go through doors during level initialization, before the first tick. See: FerBotz.
Higor
Godlike
 
Posts: 1571
Joined: Sun Mar 04, 2012 6:47 pm

Previous

Return to Discussions

Who is online

Users browsing this forum: No registered users and 1 guest