CEONSS

So, as I promised, here is a report on creating a moving node. No technical details are provided, so I guess this doesn't belong to Creative Corner.

I drank 0.25l of whiskey, then 0.125l of liquer, and then polished it all up with 0.5l of dark beer and a glass of champagne (~0.2-0.25l i guess, didn't measure it).
Adding the moving node was pretty easy (just linked it to a moving actor in UE), but there were some problems with using it in-game.

First of all, i couldn't connect a waypoint to same moving platform where node was attached. The "group items" menu entry just disappeared, couldn't find it nowhere.

Then, a minimap scheme of nodes connections became a mess. All the lines were doubled, some even tripled, and I couldn't figure which nodes they link in some cases.

When I opened UT and started the match, for some weird reason the mode switched to CTF on same map mid-game, but flags did not spawn (or I couldn't find them). Stupid bots still tried to build nodes, while losing by frags with a big margin.

The node I added on moving platform did not move, but map walls did - I ended up running into wall couple of times, while I didn't intend to do it. Also, bots seemed to cheat - every time i fired in them with rocket launcher, the flack appeared all right, but they escaped the bullets somehow.
Also some vehicles tweaking is needed: one time a friendly bot took the ball and escaped with it on Raptor to enemy flag. So, he just gave enemy team free 10 points: 1 for a captured flag, and 3 for bringing the ball to core.

To sum it all up: adding moving nodes is not recommended, because it breakes the game and gives you a colossal headache the next morning.

Heh, considering the entirety of the account given above, I'm not sure whether I should attribute this rich assortment of glitches to a particularly awry implementation attempt or to a high enough blood alcohol level ( ).

In any case, I think it bears reminding that ONS objectives, both as a gameplay element as well as a Uscript class exchanging data (and interacting with the rest of the gaming world in general), are a pretty complex part of the game[type] and, thus, a modification of the sort attempted above to them should not be approached lightly or without the necessary amount of forethought and technical understanding.
To compile a short list of associated baggage that making an ONS node properly movable would bring along with it just from my own (probably still incomplete) understanding of it, one could easily imagine that such an extended subclass would have to address, say, the node's disc needing to be repositioned (and reoriented) in relation to the node base and whatever mover it's attached to at every tick, as well as the same for its shield or skybeam; the radarmap's node graph would also need to be tied to the tick function so as to be redrawn with the same frequency, and the same would need to apply for the nodes' state icons (attackable, locked, under attack). Playerstarts, vehicle factories, stationary turrets and other (custom) actors (think OnslaughtSpecials' link beam catcher) that ordinarily become associated with a node by virtue of a simple proximity check would also need to be subclassed so as to be able to move/rotate (and replicate that info to clients), but also would need to provide a different way to be manually tied to a moving node too (likely though a new, mapper-assigned parameter) since a pre-match proximity check would no longer suffice. Lastly, there's also the briefly touched upon issue of bot logic to consider vis-à-vis the NavigationPoint network and how something as innately pre-built (into the game's code) and pre-baked (into each map by way of building paths) could be adapted to facilitate changing locations - if that's even possible, which I'm not confident enough to make guesses on, what with only being 3-4 years into Uscripting. Basically, I just dunno if the game would throw a fit if one tried to make movable versions of PathNodes, RoadPathNodes and FlyingPathNodes and stuck some of those in a map, never mind if bots would be receptive to that to make the whole thing worthwhile, considering they expect to work through a tree of constant/fixed nav points in order to determine their next move. In an unfavourable scenario arising from the previous questions, subclassing the bot class just wouldn't be worth it IMO, and would mean leaving behind bot support for maps sporting movable nodes (or just around the regions within which they roam).
Of course all of the above would need to be accounted for, planned, implemented and carefully/exhaustively (beta) tested - ideally by more than just one Uscript dev to increase the chances of catching any occurring bugs early on - meaning, such a project would represent more an extensive and quite serious undertaking, possibly needing prior coordination too, rather than a simpler job one person could code in a caffeine-fueled afternoon.

Nevertheless, in terms of the bigger picture, if there's any meaningful future development still left to be done for ONS as a gametype within UT2004 (I wouldn't bet my bottom euro on Epic taking care of that with UT4 if I were you, btw), a path towards an "ONS 2.0" if you will, it's been an ardently held conviction of mine for years now that this should be towards the direction of creating a movable version bundle of all those essential ONS assets - I'd been secretly hoping Wormbo's OnslaughtSpecials3 would focus on that when development on that started in earnest - and allowing mappers to let their imagination and skills loose with such a toolset to create novel and compelling gameplay experiences for the remaining community to enjoy. Even though I'm well aware I still lack the experience to attempt anything of that scale myself (currently working on something much more modest and suited to my coding level), I have been toying with several gameplay ideas based on such a project getting realized for awhile now that I'm definitely still looking forward to be able to try sometime in the future, so here's hoping, I guess.


Anyway, good job getting that conversation going, Mani .

Thanks a lot for all those thoughts, mr.Pegasus, and now this post is absolutely to be mved to creative corner.

I myself only opened UEd couple of times and not to be considered a moder (yet), but this post is not a result of creatibe work.
That is, yesterday i asked question about movable nodes in chat, and someone (AFAIR it was Hyden) suggested that nodes can move if you drink enough... and I promised post a report on this idea on forums. So, here it is

Now, what can i say about it with a (relatively) sober mind. Of course, all of this is very optimistic and have to be tried and tested.

1. Disc is just another actor, so I hope it's possible to make it moving via same methods;
2. I hope that skybeam and shield are linked to node automatically (e.g. shield is listening for node locked/unlocked status and skybeam is listening to node taking damage right now);
3. The radar image and links lines seems to be terra incognita, but probably there is a way to override them (there are radar mods already; also, lines are updated on node setup change);
4. The question of linking vehicles, turrets etc to nodes is a tricky one, but we can dig into AS-Convoy (Assault map with Nexis missiles trailer with moving surroundings)
5. Yup, the bots would surely have hard time comprehending this new situation and probably will die of head explosion;