ONS-Tanks-a-Lot-)o(-V5

Anything about UT2004 mapping, Uscripting & more
User avatar
Pegasus
Posts: 1022
Joined: Wed 4. Nov 2009, 23:37
Description: ONSWordFactory
Location: Greece

ONS-Tanks-a-Lot-)o(-V5

Postby Pegasus » Sun 31. Jan 2016, 02:29

Alright, alright, I can already tell what some of you might be thinking just from reading the title, so before moving on to the juicier parts of the post, lemme just take a moment here to clear up a few important things first. Yes, Tanks-a-Lot is, and has always been, a predominantly vehicular combat-focused map - and frequently a spammy one at that because of its narrow geometry and "splashy" artillery-centric loadout - to the unashamed degree, in fact, that it practically wears that distinction on its sleeve (if not its title) as a badge of honour rather than a label. Also, yes, it's understandable how among a crowd with a significantly duel-leaning n' skill-oriented component to its collective playstyle sensibilities, as the CEONSS community is, said map might have acquired a less than universally acclaimed reputation over its time on the server's roster, despite that same map having managed to attain a consistent patronage even among competent hitscanners elsewhere. All that is both true and well understood, but, as I've argued in other threads in the past, one should also not overlook facts such as that TaL also offers plenty of areas where dueling can, and does, influence the course of matches, that the map affords pedestrian tacticians several options for safely n' quickly covering otherwise dangerous distances to get to nodes and engage in aforementioned match-influencing fights, or - lastly, but equally importantly - that the specific custom vehicle loadout of this map has managed the rare feat of delivering nuanced combat gameplay on numerous occasions because of the interplay between (kinda) fragile artillery (PPC, ion) versus faster damage blockers (Aegis), a brawl that's scarcely ever left to play out on its own in other maps because of all the other heavy hitters typically roaming around and putting an early, 1-shot end to such match-ups from afar.
Even though this edit's scope was never intended to be some kinda fundamental or revolutionary redesign of TaL's core concept, and it just started by me dwelling long enough on the simple ion/PPC role reversal idea I'd mentioned awhile ago, it's exactly on those promising and preexisting qualities that I was aiming to rely n' improve upon once I was done with that first change, by opening up even more options and giving room to even more indirect/inventive ways to reach nodes, and, hopefully, you'll find most of the other alterations listed here to have contributed to that goal just as much. What I'm driving at with this disclaimer is, even if you primarily favour a duelist/foot soldier playstyle and have always been skeptical of what this map can offer you because of this preference or the general distaste of getting 1-shotted by tanks, I'd still invite you to take a look through V5's changelog and give this edit an (ideally unprejudiced) try before dismissing it as "more of the same", and, if afterwards you still end up with that same conclusion, well, that's fair enough and I'll earnestly accept all criticisms, feedback or expressions of differing tastes to that direction. Essentially, all this is just me working up to a "please try keeping an open mind about this", I guess :).

Okay, with the necessary intro out of the way, let's move on to the main menu itself. Here's the changelog proper:


ONS-Tanks-a-Lot-)o(-V5: edit of ONS-Tanks-A-Lot-)o(-V4 (2010, by Lord Simeon & edited by Danno'68, 30.7MB uncompressed)

File size: 31.2MB uncompressed, 10.1MB as .uz2
File dependencies: BioAegis_Tex.utx, BioAegis_Sound.uax (both from V4)
Release date: January 2016

* swapped core-proximal base tank with Basilisk (thin geometry-covered objectives play to its unique traits), 50secs respawn time
* PPC/ion roles swapped to better balance interplay with Aegis & increase skill check for long shelling, same spawn time
* boosted lockers (no mines), swapped 1 damage amp at service nodes for mine layer (8 ammo)
* integrated CustomWeaponLockers & OnslaughtSpecials2_RNH: node names, beam catching & radar health indicator (embeds OnslaughtSpecials2_RNH.u)
* upgraded to Badgers Mk2 and team-coloured ion tank (embeds Badgers_V2beta3.u, OnslaughtToys1.u and ONSToys1Tex.utx)
* PPC tweaks: disabled bKeyVehicle (won't disappear early), main shell won't explode from skymine contact, different alt-horn (meep meep!) [*Proposed New Standard*]
* replaced all lifts with jump pads, added JPs from below to street level by central gates to checkpoint nodes, added sound to jump pads
* added extra locker near core badgers spawn, replaced far primaries' LG bases with lockers
* completed access to all light fixtures from cores to service nodes to extend defending foot soldiers' reach
* added drop-on girder below proximal primaries-facing shaft openings so players can access that area and vials
* increased base teleporter exits to 3 per side to reduce likelihood of team telefragging
* center ion spawn rotated 90° to facilitate easier exiting, slightly redesigned central roof crates to balance sides
* removed central roof lockers to discourage extended hitscan spam, moved central health packs to middle lift exits
* lower tunnel lights made semi-solid, rotated & receded a bit towards the walls to optimize & help with vec movement
* beams near service nodes' jumppads & central lift exits receded into walls to facilitate dueling, prevent snagging
* service nodes' fence parts both have blocking volumes now, blocking all trace types
* fixed redeemer NewWeaponBase's misaligned tex, adjusted middle node lift shafts' center-proximal textures
* tweaked geometry of chain link fence-side pillars at center-proximal service tunnel entrances to fix previous gap
* central node platform decorative geometry made semi-solid to improve BSP performance & aesthetics
* added node names and more descriptions to distinct locations around the map (bases, tunnels, roofs, shafts, center)
* various tweaks to pathing; bots can now reach most areas, use ion, jump/drop down over sensible distances at center
* centered map graph-wise, made a more helpful radar image & level preview, while honouring previous versions' art
* converted lightmaps to RGB8 format to reduce file size; result smaller by 11.3MB uncompressed, 1.3MB compressed
* added Changelog class & actor for quicker edit changes reference; extract map's class assets to review in plaintext


The download link for the "release WIP" version of this edit is ONS-Tanks-a-Lot-)o(-V5_releaseWIP (8.09MB, .rar archive, BioAegis dependency files NOT included), with the filename intended to be flattened to "ONS-Tanks-a-Lot-)o(-V5" if no major issues (i.e. requiring followup edits) to fix get reported.


As usual, the remainder of the post consists of a breakdown of the more noteworthy changes that players and/or prospective editors of this map might find informative, and which will cover the three general categories the edit focused on, namely vehicles, expanded pedestrian options and other, more technical aspects. For those concerned more about not having missed some crucial info before playtesting than any extended commentary on theoretical design, gameplay balance or practical/technical UEd-related issues, you'll be happy to know there's nothing of that sort to add, so feel free to stop reading here, if so inclined.


The notable changes to the map's vehicle loadout are few (and pretty straightforward too), so let's get those out of the way first. For one thing, exchanging the roles of Tanks-a-Lot's ion-class staple vecs (that is the Ion Plasma tank and the PPC) was itself the core idea that got me started working on this edit. Since this concept of aiming to improve gameplay by way of "increasing tactical skill requirements in artillery vs. shield vec duels around constrictive geometry" is something I believe I've already gone over previously on the msg. board (here), there's little reason to go on restating the same reasoning. Please do note though that, as the changelog states, the ion featured in this edit is the team-coloured OnslaughtToys version, made by the Omnis' Kamek, which has 900hp and an alt-fire blast that's quite deadly for pedestrians, so don't go all flak-happy, rushing it as if it's harmless. While I realize the stock ion was already a tough foe, given this vec now is meant to serve as the map's centerpiece, as well as considering all the other vehicular threats around that can still take it down in 3 hits (or less), I hope most people will still find this acceptable rather than imbalanced. Right, with the ion warning out of the way too, let's move on to the other feature here, namely the addition of Wormbo's Basilisk.
Straight from the top and to be fair here, replacing the TaL bases' core-proximal goliath with the Basilisk is a feat of novelty this edit can't legitimately claim for itself, as it was done elsewhere nearly 2 years ago (although the concept itself may be a different story :p). What's of more importance here, however, is how good a fit online experience revealed the vec to be in terms of general firepower & competence against the rest of the available armoured options. Even more crucial was the way in which its inclusion expanded gameplay in a unique direction, owed to the numerous objective-housing areas within Tanks-a-Lot being comprised of thin and/or non-strictly-concave geometry, which the Basilisk's shockwave could pass through and damage actors across. This opened up different ways of tactical approach, with players coming up with inventive ways to indirectly (safely, even!) undermine enemy objectives, assets or areas, thereby necessitating further evolution to [preemptively] address this threat. To my mind at least, all this serves both as a clear vindication for Wormbo's concept, as well as compelling evidence that the Basilisk naturally deserves its place in this map, since it manages to yield more gameplay value out of it than most (any?) other alternative, and that's why it made sense to include another pally variant at the expense of one tank per side.
To anyone that might be worried though, with 6 goliaths, 4 aegises and 3 other artillery type offerings in total, the map's character n' main attraction aren't likely to change anytime soon, so one will still be able to Tanks-a-Lot spam ...a lot :p. Only thing left to address with regard to this (that kept grinding at my perfectionist streak for not having been able to stick into V5) would be to include a fix for the vec's heatray emitter starting position misalignment issue at its first firing tick during online play, but that's not exactly any kinda tragedy in the face of everything else, if we're being serious here; thankfully, Wormbo's still around so whenever he might decide to take a look at it will be cool with me. Alright, I think that about covers everything there is to talk about regarding vehicular changes for this edit.

Moving on to more... pedestrian matters now (sorry, couldn't resist), I can't rightly claim this edit was informed by some kind of grand vision from the start, similar to how it was with vecs. What kicked things off, instead, were more rote concerns to the tune of, say, addressing the lifts' inherent periodical resource scarcity problem by replacing them with jumppads, do some anti-spam tweaks around the central roofs n' adjacent top shafts areas, and maybe look for a few other interesting ways to utilize existing playable spaces or expand & open up some new ones where it'd make sense to do so. In most cases this was a pretty uncomplicated task, but there were also 2-3 exceptions where things turned into a tangled ball of concerns and constraints, and it's those that'll be getting some focus below.
Previous Tanks-a-Lot versions featured 6 lift movers, and for all the non-central ones the only consideration to offering a jumppad equivalent solution was to not leave "power players" feeling slightly cheated out of the lifts' full tactical potential, typically tapped into with a mid-ascent jump and offering a height/range boost (albeit at a more predictable trajectory for enemy hitscanners). Staying true to this was as simple as giving the primaries' jumppads a slight JumpZModifier tweak (to 1.2; core lifts didn't leave much roof for creative uses), and this achieved a ~60-70% performance parity to the lifts' max jump height, which seems reasonable enough given that most players neither expect nor desire to get a rocket launch kinda boost every time they approach a JP to reach a higher point. When it comes to the central node's shafts, however, it was important to make sure I'd sufficiently accounted for the range of tactical options and scenarios the lifts previously played a role in enabling - both when going upwards to small balconies, top or further, as well as when descending from above while, say, preloading a rocket triplet - before even attempting to change anything.
Just from lengthy observation of these areas during TaL online matches, one could distinguish between several archetypal playstyles, whereupon, for example, some people would opt for falling towards the wall lights alcove behind the lift through the passable grate texture and then do a final, small hop towards the bottom exit that just avoided triggering the lift, while others would prefer to fall straight down, but stay close to a shaft side so they could wall dodge away some 3 quarters of the way down to decrease their speed and move towards the exit. Then, on the way up, there was even more diversity to observe, as some (most?) wanted the transit to be done in a single, quick and no-frills motion without extra jumping (so as to avoid getting sniped from across the area), while others did want the extra air (usually more so when around the enemy's side) when looking to land on the boxes or elevated ledge and gain a quick tactical advantage against sniping opponents. Lastly, you got those who wanted to break the lift's upward path halfway through with a quick dodge forward in order to reach the balcony pickup and/or hop to the vehicle spawn from there. So right off the bat, that's five common use cases pointing to five pretty hard constraints in terms of expectations setting the standard for the substitute solution. Add on top of this that players would be expecting the change to be more an improvement than an impediment, and that this would somehow need to be the case when trying to achieve the same multi-faceted performance through a game element that doesn't have a similar degree of behavioural granularity (you either get kicked up or you don't, no multiple stop points about it), thus requiring finding the ideal placement for 2 jumppads that should still require no greater amount of time to perform in one, fluid motion, and all this through a manner that, despite the cramped space, wouldn't hit a similar degree of usability failure/frustration low point by giving players an undesired push upwards when they were dropping down (as was already the case with lifts from time to time) when the jumppad bases are quite sizable to begin with, and -gasp- ...well, it's easy to see how all this made for a pretty tricky equation system to solve.
Fortunately, design problems such as this are the type of challenge that doesn't tie you down in front of the editor in order to solve, but it's something you can "take with you" and be tormented by for days on end think about elsewhere as you go about the rest your daily life; basically, let's just say you don't wanna know where exactly this final configuration was conceived after several frustrating failures, but results are results, right :p? After running numerous playtests to make sure, this setup seems to have so far held up to all aforementioned requirements, allowing various techniques/styles of transit up n' down the shaft to play out unfettered and in one, easy enough to learn motion from bottom to top (just hold left). For the shaft's bottom JPs, additionally, the same trick that was employed in MasterShower-V3-SP1 to avoid accidental "return to sender" moments when going down the tunnels' entrances was used here to accommodate for the little room around them, namely shrinking the st.mesh, emitter and JP trio down to 50% and putting the whole thing in a small hole that players could deliberately touch (but be far less likely to do unintentionally). All told, hammering on the edit ever since this replacement, it seems the central jumppads have been working elegantly enough to stick with, and bots also appear to've been going through them without problems too (more on them later), so that's what's made it to release; still, knowing my luck, I bet it won't take long before feedback to the opposite starts coming in :/.
Moving on to the adjacent, and related, topic of changes around the central roofs and upper shafts area now, this, too, started harmlessly enough with the intention to try and reduce spam as a general approach to improving gameplay. For one thing, this meant addressing hitscanners occasionally spending much of a typical TaL round taking potshots at each other from across the central divide, which led to the removal of the top lockers, the downranking of the nearby health kegs (which sometimes served to prolong said spam and weren't really justified in any other sense) to health pickups dragged up from next to the central node, as well as to the slight reworking and balancing of the amount of cover that geometry affords players up there. Still, when examining the potential impact of these changes, it quickly became evident that these tweaks would realistically only affect the game's pace slowdown around the immediate area (roofs), but turn a corner into the shafts and the situation would likely still be the same all the way to the distant primaries, with spam and spawnkilling remaining the order of the day. Oh, minor heads-up here, btw: when going around giving different map locales distinct names, I ended up calling those primaries "checkpoint nodes" because of what all the gear facing the nearby blast doors suggests; in a similar vein, I named the stub nodes where the ions/PPCs spawn "service nodes" because of the nearby coolant regulator-looking machine.
Back to the main point though, looking a bit more towards the broader picture, it seemed this distribution of spam flowing outwards from the high central areas was less likely to've been a product of coincidence and far more probable that these different expressions were all the direct result of a single cause, namely that a number of (usually more skilled) players didn't care to get one-shot by enemy vehicles while roaming around the street level or below, so they routinely favoured the only route that would preclude such outcomes, meaning the higher paths, and so they'd regularly engage in ad hoc combat with each other along them time n' time again to the detriment of gameplay quality.
It bears mentioning here that variations to the peds' transit paths around the upper central area were experimented with in recent TaL versions, with most notable approaches being the inclusion a system of jumppad pairs flinging players from the two low lateral midsection points to the roofs at the opposite side of the map, and, additionally, extending the primary-proximal parts of the shafts all the way to punch through n' reach the central roofs. Ironically enough, however, without a complete picture of why pedestrian spam was so pronounced up there in the first place, both those changes ended up further fueling the fire because they kept sending more traffic down those paths, while extending hitscan exposure all the way to the other side of the central area; especially during mid-to-late-game the latter would get pretty bad, with attackers flooding the defenders' shaft with all kinds of hitscan n' projectile spam (mines too), either from being perched at their own roofs, or by flocking to the new enemy territory's shaft entrance point, to the point where defenders would be pretty likely to die mere seconds after exiting from their base teleporters, thus invalidating the design's entire point, and also proving the two-central exits concept moot because the now-longer route was pointless to take.
Instead of dual access from roofs to adjacent vents or highly convenient (and risk-wise imbalanced) propulsion methods, what seemed to be lacking was some kind of true ped path alternative to the checkpoint nodes, as in not sharing the latter half of the approach with the existing option. To that end, but also in order to identify any underused areas within the playable geometry that could be part of the solution, I first ran across those narrow areas above the checkpoint alcoves' top beam and considered the possibility of them being good candidates for teleporter exits that raiders could be sent to. Hypothetically, this would happen after they'd earn such a trip by crossing some perilous/exposed path at the central area to reach a teleporter entrance placed, say, on some small, but visually communicated, platform above the enemy checkpoint blast door or on some newly placed high platform between each lateral midsection pillar pair (maybe another jumppad could send them to the opposite end of such a platform) or something to that effect, all because the defenders failed to intercept the raider in time. In the end, compared to exiting from the current shaft, which defenders have several options to guard against, spawning up there (potentially with a damage amp, mine layer and/or nuke in hand) seemed to offer far more benefits than drawbacks in terms of stealth/undetectability and tactical advantage so as to be considered anything remotely balanced for an attack path. Ditching that concept in favour of the new, blast doors-proximal low jumppads seems a no-brainer in hindsight, as the JPs both make better use of an area that saw very little previously (short of the occasional tank lurking there for repairs), and combine the relative safety of a prospective raid's first leg with the exposure to sudden tank death in the latter half of it in a more equitable way.
As for the mines themselves, they're still on the map and the edit's not taking any otherwise prescriptive measures to prevent their use, so if anyone's playstyle absolutely relies on grabbing those and laying some down near the enemy teleporter exit, well, you can still go right ahead and do that. Between the triple teleporter exits per side and the, hopefully, reduced ped traffic along the upper shafts from the central area to the checkpoint nodes due to new options, however, don't fret if your little spiders end up having a lesser tactical effect now than in previous versions.
To wrap up the pedestrian-related aspect of the edit now, between punching holes to form a path across all light fixtures from/to the cores and service nodes, and adding a girder below the proximal primaries-facing shaft exits so that defenders can grab the health vials there n' get the drop on aspiring core invaders, I'd estimate the overall reach of the stealthy paths network that (should reasonably) shelter foot soldiers from vehicular threats now probably amounts to covering upwards of 40% of the gameplay-significant areas around the map. Here's hoping this helps allay some of the duelist skeptics' concerns mentioned at the top regarding gameplay quality and matches' outcomes in this map being perceived as mostly affected by tanks - Tanks-a-Lot can be Sneak-a-Lot too ;)!
Edit: Shit, forgot to mention one last anti-spam idea I was entertaining for awhile, but ultimately ditched, that future TaL editors might find food for thought or an interesting basis to improve upon. This particular brand of spamming had to do with the frequent practice of vehicles parking at the top of the central ramp overlooking the enemy service node and pelting it with a constant barrage of shells, to which the defenders' only available recourse would be their core Aegis getting there to shield the area, but only if it's alive n' around. Thus, as an additional means of temporarily obstructing incoming shots, but also as a way to give those tunnels' inter-beam trenches some utility, the idea occurred that they could be connected through holes (much like the light fixtures near the same nodes), and local defenders would be incentivized to jump inside the node-proximal one and move along the path towards the central edge by placing there a button. Operating it would trigger a slowly descending blast door coming down and blocking that passageway for some 15-20secs (think 2nd-Raceway's in reverse), giving defenders some time to regroup. Exiting those trenches could be done either via jumppad or teleporter at the opposite/node-proximal end; currently, one can shield-tap-jump their way in, but would have to slope-dodge and half-shield-jump in order to get out, IIRC, and their only, questionable (and pretty damn convoluted) use right now could be considered waiting for an enemy vehicle to pass by before double jumping and managing to squeeze off a single hitscan shot at it (blocking volumes there have always allowed ZETs to pass through for some reason). Eventually, this idea was dropped due to potentially getting abused or being too disruptive to the overall gameflow in a map where access to the enemy's base is only available through 3 narrow passageways; cutting one off completely in the name of anti-spam struck me as pretty heavy-handed.

The remaining bunch of notes below will involve breaking down a few issues that have less to do with gameplay and are more technical/UEd-centric in nature; while they might be of little use to any players still reading this, they could potentially be helpful to other map editors encountering similar problems in the future, so they're presented mostly for the benefit of those few.
Arguably the most time-consuming difficulty this edit posed in terms of technical challenges was improving the bots' behaviour to any significant degree, once I broke from long-established, personal tradition and made the unwise decision to actually bother doing this. Initially, the bots would either get in and immediately exit vehicles spawning at nodes, or they'd rush to grab any of the big 3 comprising the bases' loadouts (rarely, if ever, the badgers though), do a 180 and head straight for the teleporter, blocking everything for everyone and then just sitting there until the idle check/timeout would kick in and they'd all just exit and hoof it by way of jumppads n' shafts. When not reaching the nodes on foot through the few paths indicated to them (upper shafts weren't, for one region, nor were the lower approaches to the central node area), it'd be a rare sight to see the bots actually heading for a node in a vehicle, and an even more rare one to see 'em actually get there instead of bumping into any protrusion and bail shortly after. Overall, the bar was placed pretty low, is the point here.
After a few ped pathing sessions, culminating in placing JumpSpots and their forced path pairs around the map and in the central, more vertical geometries, that went by smoothly enough and started showing promise, it was time to see what was causing all that vehicular mess; after all, teleporters are navigation points whose bVehicleDestination is set to false by design, so why the hell were the damn things car-piling on top of them instead of carpooling across the plenty of existing RoadPathNodes? While no UT[2004] mapping resource I consulted online could offer any helpful explanation regarding bots in vehicles developing a teleporter fetish (oh, and occasionally one for jumppads too... yeah, it was sanatorium-degrees of fun at first), eventually a salient, but more generally mentioned point appeared the most probable: it's not about the presence of a complete RPN mesh linking all the gametype's objectives together, rather this was about the quality of its constituent connections. To wit, any connection quality deemed less than ideal along some intended vehicle path, as indicated by any non-white colour assigned to its arrows, will cause the bots some kind of high anxiety and end in them refusing to ever drive down that way; instead they'll look for any other available path to use to get to an objective, apparently even ones never designed for vehicle use at all :s. As to how to get RPN connections to be white, the answer to that was to afford 'em as much space as possible along the direction of the arrows (guesstimating something like 300-350UUs of clearance on either side). For a map with plenty of narrow twists n' turns as Tanks-a-Lot is, this was a pretty tricky exercise to get right, but, thankfully, it did prove possible to get all corridors' paths white enough in aggregate to convince the bots to try 'em. By this I mean that sometimes the Changed Paths rebuilds' optimal result would only end up coming out unilaterally white, but relying on bidirectional white connections along more distant RPNs at each side meant the network would still be traversable in both ways; curious editors are encouraged to see for themselves just how wonky and counter-intuitive this proved to be at some points, but a working result is a working result no matter how one got to it in such cases, no?
Even with that in place, this only accounted for bots successfully reaching the primaries more or less half the times, whereas for the rest they'd still pile up on the damn teleporters. Next solution attempt for this involved trying to force 'em to move to the RPN directly ahead of the vecs' spawns by feeding the RPNs' names to the vehicle factories' auto-created navigation points; trouble is, those values would get pruned by UEd during each path rebuild for some reason, so after some failed AIScript & trigger combo tests, this necessitated plopping additional RPNs right on top of the vehicle spawns with the necessary forced path and proscribed path directives. Since RPNs are a pathnode subclass themselves, only with longer max connection distances and a few other flags for vecs to read, this ran the risk of telling all pedestrian bots to flock to the same point as well, so to avoid such behaviour, the new bases' RPNs were placed slightly above pawn height (at 60-70UUs or so, IIRC), and were given enough collision width to address more than one spawned vec, but also anyone veering close to the teleporter (nooooo, NO! bad bot! move away from the teleporter!! ugh, I said NO, damnit! grrrr). Put together, these two measures solved most of node transit issues, although there's some car piling that'll still happen on occasion, but around the (non-transverse) nodes where I didn't make use of their VehiclePathName property (to point to the nearest RPN beyond which bots should get out and walk) because they seemed wide enough for a standard approach to work. Ah well, the result is still functional overall, albeit a bit silly at times. Aside from that, after copious amounts of offline observation, it seems safe to state that bots will reliably negotiate the vast majority of the map's vehicle-reachable locales, with the only consistent exception being understeering with the (quite fast) Aegis when trying to take sharp turns to/from the cores to the checkpoint primaries, which regularly ends up with them getting stuck at the nearby wall and bailing out. Attempting to fix that by relocating "cardinal" RPNs was a no-go for general path network fragility reasons described above, and placing more in between, as suggested in some online resources, so as to encourage slowing down didn't help any either, so all I could settle for was doubling those newly placed intermediate RPNs' collision radius values in the hopes that this would get Aegis driving bots to detect 'em a bit earlier and respond in a better way; results there were deemed inconclusive, with the risk of this adversely affecting the behaviour of slower vecs being also another factor to consider, and by that point (pretty recently) I'd begun realizing I was wasting time for marginal improvements and just dropped the matter.
To summarize this note, if I had to describe the bot situation in V5, I'd say it's moved up a few notches from "unreliable" to "almost respectable", but, as this constituted the final stretch of the editing effort, which I kept working on for over two weeks or so (secretly hoping the whole time that someone would find out about it and just take this misery from my hands somehow), it's kinda left me with a sour taste and half-wishing I hadn't bothered, but had gone with my old standby maxim of "don't expect a good match once bots start coming in" instead. So enjoy. Or don't. Hell knows, I didn't. Meh. Grumble, grumble...
The other technical subject that got extensive enough to merit some coverage had to do with putting together a radar image for the map, which would be informative, but in a way that would still honour and preserve the prior art. Even though the fog-less, indoors nature of this map did make things slightly more straightforward than other cases, overall and looking back after going through the whole thing, the process I seem to've formalized, tweaked n' settled with still ended up spanning four general stages (UEd preparation, ingame shooting, post-process & final UEd adjustments - with occasional loop-backs for correcting) and including about a dozen different steps, to the point where I'm wondering whether it might be more useful to not let it be drowned in this word salad by laying it out in full here, but perhaps post it as a separate entry elsewhere, possibly as part of a greater "UEd & mapping General Guides, Advice and Best Practices" thread that could conceivably be made in the Creative Corner forum to serve as a helpful reference & knowledge pool for everyone looking to expand their experience in such matters. Some of the steps did have to do with issues specific to this map though, and that's why I'm still of two minds about it, so if anyone with an interest in the subject would like me to go over this here, plz lemme know below so I can better assess which would be the more beneficial option and timeframe. To wit and for reference purposes though, the workflow goes something like this:
Edit: Ah, screw it, decided to flesh this out a bit more so it can be of some help even on its own right now anyway.

*** WARNING: this process is liable to deface several of your map's textures, so only do the following to a copy of it to get a good pic n' test to ensure it conforms to the node graph properly, THEN apply it back to your WIP ***
- place a [unique-class, easy to find via search] asset in the map, make it bDirectional, rotate it to North, then face straight down and set its X,Y location components to same values as central point (since the map conveniently has a node as that)
- measure map's end-to-end distance in terms of playable space (not just cores!) along its longer dimension (D), set aforementioned asset's Z offset to that of highest solid geometry point plus tan(ingameFOV/2)*D/2 as a tentative first place to iterate upon
- go ingame (via Play Map UEd button), jump to asset via viewclass command (say, if it's a FlyingPathNode, by viewclass FlyingPathNode; you can always switch back to free flycam via viewself), switch to first person view, input togglescreenshotmode and verify that map borders align with the monitor's; iterate by tweaking asset's Z in UEd if not
- if map has an interfering skybox bottom tex, create a distinctly bright ConstantColor (that's not encountered in the map!) and place in myLevel package, apply it to skybox bottom
- if map has interfering ceiling geometry (or multiple levels) that obstruct clear view to playable areas you want to depict, start applying the handy stock invisible texture Texture'ONSstructureTextures.CoreGroup.Invisible' to them; copy/pasting it and mass/per-brush selection options will help here (select one face, right-click n' go to Select Surfaces > Matching Brush)
- for poorly lit areas around the map you want to depict uniformly better, you can always increase their ZoneInfo's AmbientBrightness; for areas where fog obstructs clear view, it can be toggled off/on via the show fog command
- to best approximate an orthographic result with your ingame (perspective) view, opt to shoot from farther away with a low FOV (e.g. set to 40, via FOV 40 command; requires doing a viewself/viewclass afterwards for it to apply; default is 95); before taking the shot, do a killall onsvehicle command to get "clean" geometry around the bases, then a killall ONSFreeRoamingEnergyEffect to get rid of the team primaries' availability emitters
*** post-processing will be more convenient with a (free) program that can open/save in the .dds format, like, say, Paint.NET, but if transparencies aren't an issue, even MS Paint should work ***
- open saved screenshot with a decent image editing program, select area per your constant colour's value and delete it, change canvas size to make smaller pic dimension equal to larger, then resize down to 512x512px (or 256x256, if so inclined); lastly, sharpen the image by 3-4 steps and see if auto-adjusting helps (didn't here) before saving as .dds (DXT1 for 1-bit alpha, DXT5 for gradients)
- since in this map prior art would be preserved behind the map image and the camo theme was visually distracting 'round the edges, overhead radar pic was shrunk a bit to allow short black margins fading to transparent to be added around the pic's borders before saving as .dds in DXT5 format
- since world wasn't centered in this map, left black margin was made a bit thicker; Level's CustomRadarRange was re-evaluated to ensure nothing in the node graph was more than 20-30% under the border tex
- import pic in map as myLevel'd texture, create new TexScaler for it (also myLevel'd), create new Combiner (also myLevel'd) and set camo tex as Material1, TexScaler as Material2, set Level's RadarMapImage to the new combiner; iterate between ingame radar tab checks and adjusting TexScaler's scale & offset values as necessary in UEd; careful not saving the map and closing UEd while some texture remains unused 'cause it won't survive!
- note down final/correct TexScaler values, close/delete tex-mangled WIP and repeat last step for actual edit

Of course, there's still some ways this can be expanded to address problems arising from other kinds of subcases, like, say, just on the issue of procedurally deriving your fixed overhead camera-actor's correct position, what location to choose when there's no central node (average the 2 cores' X/Y components), what to do when the map is axially symmetrical on top of that, i.e. both cores share a map edge (bit more complex there, but averaging the most extreme values across all objectives on each axis could work), or how far to shoot in outdoors maps where terrain flows outwards past blocking volumes on top of previous complications, etc.. Point is, there's plenty of ways this block could still be improved upon, with a mind of posting it elsewhere as a resource, but all that's for later.
Last relevant point here, that might also have helped with Cat's recent MasterBath editing efforts without necessitating an entire rebuild of the whole thing (if it had arrived sooner, anyway) has to do with just that, world moving back to center. If it's not clear why anyone would ever bother with this, well, a centered geometry can allow the node graph to scale to its biggest possible size without spilling past the borders, and there may be some additional conveniences/implications for symmetrical terrain editing in maps featuring the great outdoors (although not 100% sure on that), so after the radar pic was properly applied back to the edit, I figured it might be worth taking a stab at this n' seeing how easy or hard it'd prove to be.
For a map like Tanks-a-Lot, it turns out world moving wasn't much of a challenge. It only took dropping down something to act as a beacon (I chose the trusty health vial), setting its X n' Y location components to 0.0 (not very far from the map's central area, actually), right-click selecting EVERYTHING! (Select > All Actors), manually deselecting the beacon actor, enabling realtime preview for a couple of the more helpful ortho viewports while keeping the 3D view camera fixed to the beacon ...and just dragging the whole kit along until the middle node's center comes as close to it as grid locking will allow - that is sub-1UU. Do NOT turn grid locking off, btw; achieving dead-center alignment won't be much of a victory if it comes at the expense of BSP glitches.
Mercifully, no such horror story happened this time, but there was one confusing complication that arose after rebuilding geometry, lighting and paths in sequence: two geometrically proximal, but non-adjacent zones ended up sharing the same zone colour. To confirm this wasn't just UEd deciding to use different, but very similar colours, an ingame test with wireframe mode verified that only on the east side of the map one could see the proximal primary region's geometry being rendered while moving around in the nearby service node area and the same would hold for the reverse too :s. Clearly some kinda asset leak was the culprit and, fortunately enough, earlier on during the same session I happened to be fooling around with relocating/resetting some central area BSPs' pivot points (which seem to be treated almost independently of the rest of the actor's assets - model included - and can be placed arbitrarily far from the actors themselves), so, after some other, cursory eliminations, my mind went straight for that. True enough, the pivot point of the service node's main subtractive brush proved to be causing this by somehow being placed much closer to the proximal primary's zone than it made any sense for it to be, and a simple reset (select the brush in ortho viewport, right-click anywhere inside it and pick Pivot > Place Pivot Here; verify in different ortho viewport that it was also placed within the brush rather than farther away) was enough to fix things upon the next rebuild, so disaster averted. With that, the world was now centered and made it possible to pick a smaller CustomRadarRange (from 16500 down to 15000 here), thus making the node graph look a bit bigger (and better) without anything spilling over. And that's all there is to tell about world moving, which also concludes the radar image discussion - and, indeed, the technical comments section - too.


With all the points I meant to go over now more or less covered (possibly missed a few, but eh, I'll deal with 'em in another post, if/when I remember them), I think it's about time to finally wrap up this monolith on a couple of trivia notes.
For one thing, as this map's earlier version filenames (OSR-Tanks-a-Lot) might suggest, and its description outright mentions, Tanks-a-Lot was an entry to "King Mango's Old Skool Rules" mapping competition, which, based on this page, seems to've been an open challenge around the UnrealPlayground community to create maps for UT2004 while observing UT99-era restrictions in the type of resources n' assets one could use.
Practically speaking, the most "extreme" consequence of this, that one might quickly pick up on while examining the map in UEd, is that Tanks-a-Lot features no placed static mesh actors beyond those used for the jumppad bases, meaning that every geometry detail down to the smallest decorative bits (bases' pipes, coolant regulator grills, stair rails, fences, central platform vents, roof crates, light fixtures, proximal primaries' vehicle blocking posts, etc.) were all made out of (combinations of) BSP volumes, sheets and/or blocking volumes; for the level of fidelity Lord Simeon managed to achieve that way, I gotta admit that's pretty hardcore work :). Beyond the BSPs, the entirety of other st.mesh assets encountered in TaL only extend to the usual "core game" fare, such as weapon/pickup bases, gametype objective assets, weapon & vehicle projectiles/wrecks n' so on, plus one final, custom-made, BSP-converted parallelogram used for the lift movers ...which finally met its end with this edit.
As far as this particular edit's history goes, meanwhile, I started the project 'round mid-November without a complete changelog in mind and under the impression it'd be done within a month or so, probably ready to be presented as a gift to the CEONSS community for the holiday season. As I kept finding more stuff to tweak, encountered some problematic BSPs that required days to sanitize and untangle (discussion of this could merit its own post in aforementioned hypothetical thread, too), and suffered a setback that forced me to restart n' reapply all changes 'round the 15% completion point near early Dec., however, I kept pushing more n' more (and enjoying the process progressively less n' less because of that) to the point of burning out about a week before Xmas, with probably only half the now fully fleshed-out changelog covered, so I threw my hands up n' decided to not go anywhere near it for the next fortnight. So, yeah, insert platitudinal proverbs here about lofty goals n' all that. Fortunately, I got my mood back picking it up again early on this month, worked through most of the remaining items with little resistance, and, after 40-50 sessions and about 80-ish hours in total put into it (bot shit included) and a battery of playtesting near the end to ensure an acceptable state of affairs for the aforementioned bot shit, V5 was declared to be in releasable WIP/beta state about a week n' change ago. Rest of the time has just been me dragging my feet stitching this damn thing together.
If there's some converging point or idea to be found between these two accounts, it's probably that, even though scope creep caused the edit to easily blow past its tentative, original release "deadline", it tried to stick by the principle of changing Tanks-a-Lot in ways that would still honour the vision, intent and goals of its original author, and bring the map closer to the best gameplay it can theoretically deliver. I dunno if Lord Simeon is still around the UT scene or not anymore, but I'd like to think he'd agree with that.


Anyway, that's the lot of it - all 7,000-plus words of "it" (:p). Give the edit a try and feel free to offer any feedback you might have, if so inclined. Cheers.
Image

Zon3r
Posts: 575
Joined: Thu 7. Apr 2011, 07:46
Description: Don't shoot at me!

Re: ONS-Tanks-a-Lot-)o(-V5

Postby Zon3r » Sun 31. Jan 2016, 19:15

Pegasus wrote:Hold on to that thought for just a short while longer :).

So this is what you meant :)

I need to clarify, i don't dislike the map itself, more like the way certain players are behaving on it. like when a certain player got into the ion tank and just spammed the core area very effectively spawnkilling(the core was locked), then another player joined in from the side with the ppc also bombing the core area, well you can guess what was the outcome. so i have a strong prejudice toward this map. and now you adding all these op vehicles, it will turn into a total mayhem, we just need a mino now :)
Tried it with 25 bots, it was playable, definitely an improvement. meaning if players would avoid spawnkilling, matches would be very enjoyable.
The ppc is more OP than the ion tank, but it's less accurate(can't shoot through small gaps like the ion) AND it's hurting itself unlike the ion, meaning it's slightly easier to take out on foot, still has the skymines, but it's less dangerous

The jumppads in the middle needs to get used to, but i see what was your idea, it's good
removing one DD wasn't needed, tho certain players were taking both of them at the same time, so maybe it wont be missed
The improved both paths are working and not, maybe this was present in previous versions, but the bots at the core are trying to get through the teleporter with vehicles. im playing on godlike so they are not hindered with the difficulty setting

Give it a run on the server, maybe more people will come here to suggest/complain

Bots managed to get stuck there somehow, and were just sitting in the ppc all match
Image

The upper mentioned teleporter thingy
Image
Image

User avatar
Cat1981England
Posts: 2324
Joined: Mon 23. Aug 2010, 15:35

Re: ONS-Tanks-a-Lot-)o(-V5

Postby Cat1981England » Sun 31. Jan 2016, 22:32

First of all, thank you for your work Peg, it's much appreciated. And also for the post which will definitely prove useful :thumbup:

It seems to play much better now even with bots and all the gameplay changes you've made make a lot of sense. I've had a good look over the map and this is all i could find,

- A few textures which you can only see when looking down at the map in the editor could have their lighting set to unlit.
- Jumpads 3 and 1 feel a little to strong. Maybe set to 1.1 or 1.0?
- I know you made changes to the PPC, but could the Iontank and Badger load from packages?
- Would it be possible to move the Aegis or Basilisk away from the tank at cores please or even replace the tank with another Badger. If you try and enter either of them when standing between one of them and the tank, you hop into the tank even if facing away.
- Jumpad0 and its base are floating.
- Underside of brush 584 and 522 seem to have the wrong texture.
- You can spam East and West checkpoints from where the PPC tank spawns. Perhaps the 3 teeth on the nearby door could be made a little larger and moved towards the centre?
- EMPGrenades perhaps to help counter the vehicles?
- The pillar immediately to the right of the PPC spawn could use a blocking volume. From what i've seen the bots seem to drive into it and it (ppctank) swings round into the blocking volume and get's stuck.

Just let us know when you're happy with it, either for beta testing or final edit, and it'll go on :thumbup:
The Universal Declaration of Human Rights, Article 1:

All human beings are born free and equal in dignity and rights. They are endowed with reason and conscience and should act towards one another in a spirit of brotherhood.

User avatar
Miauz55555
Posts: 1164
Joined: Sun 7. Jun 2015, 22:12
Location: Germany

Re: ONS-Tanks-a-Lot-)o(-V5

Postby Miauz55555 » Mon 1. Feb 2016, 20:06

Thank you for the Book Pegasus.
Just now I stoped reading where you write "[...] stop reading here [...]" but I will go on for the technics later. I think I will need a week or two to read it. ;)

Cat1981England wrote:[...]
- EMPGrenades perhaps to help counter the vehicles?
[...]

Or two Battery Launchers?
In the niche in the tunnel where the players are teleported from the core.
Image

joeblow
Posts: 167
Joined: Sun 16. Feb 2014, 20:41
Description: male gamer
Location: tennessee,usa

Re: ONS-Tanks-a-Lot-)o(-V5

Postby joeblow » Tue 2. Feb 2016, 10:07

If a game admin is on I just turn off all bots at the start of the map manually.

There alot of maps the pathing is screwed up and when there are a few players on it ruins the match.

User avatar
Pegasus
Posts: 1022
Joined: Wed 4. Nov 2009, 23:37
Description: ONSWordFactory
Location: Greece

Re: ONS-Tanks-a-Lot-)o(-V5

Postby Pegasus » Fri 5. Feb 2016, 18:33

Apologies for the radio silence, folks, it's been a busy week. While I've only been able to work on the map and research some stuff for 20-30min sessions at a time tops, progress has been made, so an update post laying out all that, as well as addressing other issues and suggestions brought up here, will be following soon - thanks for the feedback, too.
Image

User avatar
Pegasus
Posts: 1022
Joined: Wed 4. Nov 2009, 23:37
Description: ONSWordFactory
Location: Greece

Re: ONS-Tanks-a-Lot-)o(-V5

Postby Pegasus » Mon 8. Feb 2016, 07:42

Okay, so, based on everything brought up above (and a couple o' things that weren't), over the past week I started putting together a "release WIP 2" edit, and it's now done. So, let's first dig into the feedback subject matter, from simplest to more elaborate/time-consuming, and then move on from there to the list of what all made it into rw2 in the end.


Zon3r wrote:[...]I need to clarify, i don't dislike the map itself, more like the way certain players are behaving on it. like when a certain player got into the ion tank and just spammed the core area very effectively spawnkilling(the core was locked), then another player joined in from the side with the ppc also bombing the core area, well you can guess what was the outcome. so i have a strong prejudice toward this map. and now you adding all these op vehicles, it will turn into a total mayhem, we just need a mino now :)[...]
In terms of spam, solitary or even coordinated, yes, this map will inevitably feature some, as that's always been a central part of its concept. That said, this edit focuses on trying to provide numerous, less obvious or exposed, but still skillful enough ways to move between the objectives and fight around them, and thus, hopefully, allow the map to deliver better gameplay quality.
Regarding newly added vecs, now, marginal upgrade differences aside (talking about the Badger and the team-coloured ion here), the only new addition in V5 is the Basilisk. Keeping in mind the whole sum of this pally variant's limitations - in terms of speed, size, rate of chassis/turret turn, absence of splash damage beyond the short-range, respawn rate, etc. - as well as the type of threats the map's geometry will typically throw its way, with the long lines of sight, as well as on account of all the blind corners and poorly lit central areas, overall it's not something I'd personally be inclined to label an "op vehicle" in TaL; even less so, considering the amount of heavy (-ier) hitters the map's loadout remainder features that it'll have to contend with, too. Don't get me wrong, in the hands of capable players it'll certainly get its chance to play a role, as well as its fair share of (freaky) frags, but from my experience playing other Tanks-a-Lot versions that already include it, it's nowhere near the top of enemy threats I'm worried about there.

There's no plans for minos to be added in any future TaL version, you'll be happy to know, btw :p. Still, should that ever come to pass, the new ion version already has a nasty surprise in store for it!

Segueing to the other half of the vehicle balance examination in order to wrap up this section now,
Zon3r wrote:[...]The ppc is more OP than the ion tank, but it's less accurate(can't shoot through small gaps like the ion) AND it's hurting itself unlike the ion, meaning it's slightly easier to take out on foot, still has the skymines, but it's less dangerous[...]
Before deeming the PPC as "more OP than the ion tank", consider the full picture first. The ion fires sooner (1.5sec cooldown + 2.0secs hold time vs 3.8secs intervals), has a bigger splash radius (2000 vs 1870 UUs), deals way more damage (up to 900 dmg vs 550; 1800 against vecs, in fact, because of 2x dmg scaling), has more health (this version, anyway; 900hp vs 800hp), has no spread variance (PPC has a 1.5% random deviation from reticle), is immune to its own primary's damtype and this version can also deal with nearby enemy infantry effortlessly, whereas the PPC user has always had to switch to seat #2 and fire skymines while being blind to the enemy ped dancing around half the time. Pretty much the only thing the PPC has going for it is its less restrictive aiming range & main projectile ballistic trajectory combo, which can allow it to lob shots over obstacles and hit otherwise impossible targets, but that's by no means a free meal and is entirely dependent on its driver's skill. If after all this you still think swapping those 2 vecs' roles around leaves TaL V5 players exposed to a more OP threat total than before, well, I guess we'll just disagree on that.
In my book, this edit stands a chance to deliver a spam downgrade on aggregate, and I already have a certain metric in mind that could be used as an apt measure of this too (although it'd be best if I didn't elaborate on that for now). Hopefully, this main change might even deliver an equal, but inverse, uptick to skillful play, especially against the Aegis, which ions here have previously tended to make minced meat out of in most cases.

Zon3r wrote:[...]removing one DD wasn't needed, tho certain players were taking both of them at the same time, so maybe it wont be missed[...]
From personal observation of online players' behaviour in that area, I'd have to say that what usually happened with the 2 dmg amps would be that either someone would grab both (foolishly thinking this could double the effect's duration? who knows), or you'd have groups of people rushing to get one while still camping the vec spawn point (to little helpful effect towards their team's goals) while just shooting at any visible enemy from the service node platform, and after the resolution of the dramatic "who gets to have the pointless combo of ion + double damage" competition, the other would usually just follow the supervec and link with their own dmg amped gun for awhile - not much of a boost to the team agenda there. Less frequently, but more interestingly, OTOH, you'd have knowledgeable pairs of badger raiders making a quick stop there to stock up on amps, then go ambush hunting towards the central area and beyond for higher value enemy targets; in most cases, though, it'd be hard enough for consistent badger users to even convince a teammate to gun for them, never mind doing the whole routine as properly as that. All told, even if it did feel like I might be shortchanging this last use case by axing one dmg. amp, the rarity of it versus the benefit of placing the mine layer in a pretty distant/isolated place in terms of typical transit routes between objectives (thereby discouraging its systematic abuse to the detriment of gameplay quality), seemed to point to a net positive.

Zon3r wrote:[...]The improved both paths are working and not, maybe this was present in previous versions, but the bots at the core are trying to get through the teleporter with vehicles. im playing on godlike so they are not hindered with the difficulty setting[...]
To briefly sum up the extended overview of tackling this very problem, as presented in my first post, this has been a persistent issue that was approached on a "peeling layers out of" or "chipping chunks off of" manner. Even though incremental improvements were made with each added measure towards discouraging bots from car-piling atop the base teleporters further and further, by no means did that ever reach a 100% success rate, or even 70%, come to think of it. Instead, things got to a "diminishing returns" kinda situation past the third measure or thereabouts, after which I deemed the issue no longer worth iterating on. So, yeah, bots will still exhibit such behaviour on occasion.
If there's a silver lining to the current state of bot pathing around the bases, however, it's that the teleporter jams are partway a self-cleaning mess, as the bots' idle timer will kick in after awhile and they'll decide to head for the next node on foot via jumppad, leaving the vecs behind for humans to tidy up. While it's pretty rare, I have even seen the odd bot grabbing one from that pile afterwards, turning it around and actually driving it off down a proper too, although this is obviously no guaranty for proper base resources usage across the board. Still, the general disclaimer about bots applies in V5 as much as anywhere else, i.e., don't expect too much when they enter the scene, and, of course, anyone else who thinks they might be in a position to further improve things in this regard, is welcome to have a go at it beyond this edit, as far as I'm concerned.

Zon3r wrote:[...]Bots managed to get stuck [inside the service node's fence] somehow, and were just sitting in the ppc all match[...]
Cat1981England wrote:[...]- The pillar immediately to the right of the PPC spawn could use a blocking volume. From what i've seen the bots seem to drive into it and it (ppctank) swings round into the blocking volume and get's stuck.[...]
Hmm, never had that happen in any of my 20-24 inhuman bot test matches, but definitely something that needed straightening out. For the first few attempts this seemed almost too tricky to crack too, but then I remembered that changing a blocking volume's shape meant altering its model just as much as any other BSP's, so after a geometry rebuild, the slight enlargement of the existing volumes in all directions and the additional small extension downward finally took and they both now seem to be properly blocking everything - flycams, pushed vehicles, projectiles, players and so on.

Cat1981England wrote:[...]- A few textures which you can only see when looking down at the map in the editor could have their lighting set to unlit.[...]
There's probably several of those, and with this being a niche I haven't really looked into, tbh, I think I'll defer to whatever changes you might see fit to apply there beyond this edit instead.

Cat1981England wrote:[...]- Jumpads 3 and 1 feel a little to strong. Maybe set to 1.1 or 1.0?[...]
As I talked about in the overview above, the idea here was for the jumppads to offer players something halfway between a standard kick and the half-ascent jump they could get from the lifts in previous versions. For the checkpoint nodes this boiled down to how well they'd be able to get the drop on an occupied enemy turret, where I felt that "close enough, but not over it' was probably the most sensible goal; a JumpZModifier of 1.0 seemed too low and the 1.3 value I remember trying was too much, so I settled for 1.2. If you think it's too much, I'll leave it to you to tweak this further if so inclined, once done with the unlit texture sweep :).

Cat1981England wrote:[...]- I know you made changes to the PPC, but could the Iontank and Badger load from packages?[...]
Yup, absolutely.

Cat1981England wrote:[...]- Jumpad0 and its base are floating.[...]
Well, that's embarrassing. Thanks. And fixed.

Cat1981England wrote:[...]- Underside of brush 584 and 522 seem to have the wrong texture.[...]
Indeed; probably missed it cause I wasn't zipping around under there much. Altered to match the theme around them now.

Cat1981England wrote:[...]- Would it be possible to move the Aegis or Basilisk away from the tank at cores please or even replace the tank with another Badger. If you try and enter either of them when standing between one of them and the tank, you hop into the tank even if facing away.[...]
Indeed, unintentionally entering the wrong vec near the bases' spawn points has always been an eye-popping usability flaw in Tanks-a-Lot that I, too, had noticed and probably even made a mental note years ago to raise or try to tackle at some point in the unknown future, but, for some reason, this completely slipped past me the whole time I was banging on V5, so thanks for reminding me.
To start from the goliath/badger swap proposal before working back to how the main issue was addressed in rw2 though, this doesn't strike me as an equitable suggestion in terms of competent deterrence for any defending team left with no nodes by late-game. I mean, the stock goliath may certainly be larger, and thus more susceptible to splash damage by artillery-type vecs likely laying siege to its base at that point, but its greater health and stopping power compared to a badger is undeniable, and this means it can be used to greater effect to give defenders a better chance at fending off lesser core raiding groups, while other defenders mount a counter-offensive. Besides, with the previous replacement of one goliath from the bases' loadout with a Basilisk already, I think it'd make sense for at least one to remain and act as the team's early workhorse until players manage to unlock more via the primaries. It just doesn't seem like the right math to bust it down to a second badger just for space considerations, which conveniently brings us to the main question of how to solve the limited space problem causing erroneous vec entries.
As a primer for anyone less up-to-date on the subject, while vehicle exits are handled by the game on an individual-entity basis comprising a list of ExitPositions (ranging from 2 to 4 for stock assets), and through specific X/Y/Z offsets from the vehicle's center for each one, when it comes to entering them, vecs use a radius-based mechanic via their sole EntryRadius property, which typically tends to be of proportionally high value to the vec's size - Hammerheads being a classic example of frustrating usability, both when entering as well as exiting, due to breaking from such conventions while still a raptor variant. For paladins and all their variants whose creators don't bother deviating from the norm, this key value is set to 300UUs (Aegis and Basilisk conform to this), but for goliaths it's 375. Considering the goliaths are placed in the middle of the TaL bases' vehicle bay arrangement, and that the 3 vehicles are spaced out a mere 155UUs apart on average, one should easily see how that makes for an impossible situation, if achieving unfettered vec entry is set as a goal, and with all the other surrounding design decisions taken as implicit constraints.
Clearly something's gotta give, and the first compromise I tried was spacing the current arrangement out as much as the adjacent geometry could reasonably afford, but that wasn't enough. Since the fatso in the middle was the main culprit here, the next logical step was deciding it's time to rearrange the trio so that the tank would be on a side, thus halving its interference and freeing up space, so the matter turned to finding the optimal placement for all 3 vecs. Fortunately enough, the arguments I came up with for where each individual vec should best be placed all happened to point in the same direction rather than conflict with each other, so this proved less tangled that earlier expected: it'd be best for the faster Aegis to get central placement so that players could respond to n' shield against incoming threats from other side just as quickly, but also so that bots could handle both turns equally gracefully and without slamming their face against the opposite wall n' turret, like they'd occasionally been doing before, because they're too fokn cool to slow down or something. Beyond this, the vec that made the most sense to be on the core's side should be the one that could actually make some use of that perk, and the Basilisk seemed naturally suited to that, thanks to its wall-passing shockwave that can reach the core if aimed correctly and, by doing so, afford defenders the chance to guard against pedestrian core raiders even a split second after spawning n' getting grabbed. Lastly, the goliath gets to spawn by the left wall and wear the dunce hat this time 'round - spiffy! Well, okay, if anyone's looking for a more compelling argument here, it should have a less obstructed line of sight to the proximal primary approach ramp too, from where most of the threats tend to pour in during late game, or something, so there :p.
After putting this together, some spacing out was still applied, as well as manually placing in UEd a few xPawns (basically team-unaffiliated bots of exact same size as players, i.e. of 25UU collision radius) in key locations near the new vec factory positions for measurement-taking and verification purposes. The resulting configuration looks something like this and seems to have tidied things up enough that all vecs have now ample room near 'em to correctly accommodate a nearby player wanting to use 'em with a healthy ~20UU buffer to spare (for a total of a ~70UU "exclusivity" zone on either side of each vec), so hopefully that's the last we should see of people getting griefed by the map's design there.

Cat1981England wrote:[...]- EMPGrenades perhaps to help counter the vehicles?[...]
Again, to start with the salient difference between these and the stock grenades for anyone not in the know, Wail of Suicide's EONS EMP grenades aren't just a (quite) faster moving, albeit slightly less damaging around a slightly reduced radius, variant of the standard grenades, but also happen to incorporate in their code one additional, key mechanic when used against vehicles: should the explosion damage done to an earthbound vehicle remove more than half of its current health (or more than a third of the current health of any hovering/flying vec they're detonated on), the EMP effect will kick in, ejecting the driver and locking the vehicle for 7 seconds. Since the damage can be compounded by placing up to 8 such grenades before setting 'em all off, even when they do 85hp of damage instead of 100hp, it should seem evident that the tactical advantages able to be gained from having the EMP mechanic force an enemy out of their vehicle, owed to an attack they might not even have perceived or been able to adequately defend against (an even likelier case when EMP grenades get used in conjunction with a dmg amp), can be so beneficial to their users as to warrant further balancing considerations. In practical terms, IMO the impact to skilled & balanced gameplay from offering such a tool as an ubiquitous, locker-available weapon (meaning one that multiple people could potentially decide to focus on any single enemy) is likely to vary widely enough across different map sizes & geometry arrangements that it won't always make sense to include it.
When trying to come up with some kind of rule of thumb able to answer the follow-up question of "well, where does it make sense to use this?" even for the sake of being consistent with my own design principles, no standard was immediately apparent. So the only remaining option is looking for examples where its inclusion assists playstyle balance (for pedestrians, obviously) and trying to identify common traits between those that could point to a more general concept.
The best example I could point to to make a case for using EONS EMP grenades, then, would probably have to be Nightwolf's Minus edit because of the asymmetrical, guerrilla-style warfare it allows (usually solitary) foot soldier players to wage when they're on top of the various buildings and looking to pounce on unsuspecting, but heavily armoured, enemy vehicles below that are otherwise too strong to take on directly. What also seems to help keep things reasonable there is that the frequency of such scenarios is sufficiently limited by the size of the map and the time investment its geometry imposes on players looking to pull this off (grab EMP grens, find available flyer, fly around, get stranded on roof, move into good position, don't draw attention to yourself by using too visible weaponry, wait for a suitable victim to approach, ensure you have enough ammo to trigger the EMP, then ambush), for one thing, but also that their success is nowhere near guaranteed exactly because of how much health and targeting flexibility the strong land vecs there have.
So... how much of that really applies to TaL? Pretty much none of it, was my take. Getting to an elevated area that vehicles have trouble reaching or targeting is very easy to do here, not to mention a lot of players tend to congregate there too, so pelting any hapless foe that might've rolled within range with EMP grenades - whose travel speed, it bears repeating, is quite faster - is liable to happen and plague their drivers a lot more frequently. Contrastingly, in the much more restrictive tunnels, they'd be of very little use and people would stand a better chance of helping their team using harder hitting, standard weapons. Meanwhile, the vehicles themselves here aren't exactly hulking behemoths either, so 5-6 stuck grenades at most would do the trick for any mechanized enemy, when successfully ambushed - halve that for damage amped users. Basically, it all comes down to the presence of that "guerrilla warfare" aspect, and how pedestrian empowerment works more in a direction of sneaky/safe transit rather than an avenue for unexpected and asymmetric attacks against TaL vecs that are otherwise too strong to wrestle. Much like how I also considered whether the EMP deployer might be suitable here - and that's a classified superweapon in its own right, that could seriously screw with a base's vehicular comeback if used craftily, mind - the EMP grenades, similarly, felt like going too far.
Still, perhaps this gameplay contrast between the two cases above could serve as a more general map editing guide by considering them as representing sufficiently "distant" points that define between them some type of spectrum in terms of where EONS EMP grenades would be suitable to include and where not. Assessing this would boil down to how much other maps' gameplay have in common with either of these two archetypes, call 'em "open world guerrilla" vs. "tighter/intersecting separate flows" if you will, so editors could grapple with this question in a much more straightforward manner as it might arise for other maps in the future.
For example, Nevermore seems closer to the Minus model because of its size, strong vehicle loadout and relative infrequency of people finding their way up on the various buildings' ledges or elevated train tracks, so having EMP grenades there could work as a playstyle balance compensator, whereas MasterBath, MasterShower and Tyrant being smaller, sporting more subdued vehicles and having a lot shorter travel distances that afford players many more ways to reach higher positions close to the action without being noticed, might suggest that EMP grenades there would probably be a bad idea that'd pester defensive tank usage beyond a reasonable point. Moving closer to the center of this hypothetical spectrum now, one could consider other candidates like StarReach or GunShop, whose differing ways of empowering peds (through low-g-facilitated movement or increased concealment opportunities due to size, tunnels and various transit conveniences) could make a case for incorporating these mines because vehicles also enjoy their own set of advantages (mostly range-based due to long lines of sight), whether they're stock or custom content. TripleSlap, OTOH, while not offering peds anything too helpful in terms of faster travel, is by no means an "open world" affair and still affords them enough shelter near the center and beyond, once behind enemy lines and safely away from the open lanes, to the point where using tanks could even become the disadvantaged playstyle if EMP grenades were added to lockers there - not a clear call in my book though.
Anyway, getting a bit carried away on a more general, theoretical rant with this again, so best to stop here. I just hope you see where my misgivings on this suggestion are coming from, and that maybe some of this might even serve as food for thought for other maps n' editors down the line so we can see further clever uses of the EMP grenades.

Miauz55555 wrote:[...]Or two Battery Launchers?
In the niche in the tunnel where the players are teleported from the core.
Contrary to the nuances involved in EONS EMP grenades discussion right above, and after seeing this weapon in action across a number of online matches for a couple of months now, I'm afraid I've yet to be convinced of its gameplay value in any setting.
As a general principle, I expect modders to be keenly considerate of gameplay consequences when it comes to the use of auto-aiming/auto-targeting mechanics, and especially so when infantry also get included in the list of candidates that incoming projectiles can lock on to. In the Battery Launcher's case, however, players are no longer dealing with just speeding (and dodgeable) rockets coming their way, but with hitscan zaps procedurally drawn from the approaching missile to them, that hurt them on behalf of enemies conveniently popping back behind cover right after shooting again and again, and this only serves to raise the spectre of the infamous Transdimensional Disturber and draw unbecoming comparisons about the minute differences between the two. There simply is no context in which this doesn't hurt the skillful play component ingrained to this game and expected by players, thereby constituting a gameplay detriment, even if these avrils do otherwise have a slightly harder time hitting their vehicular targets before mid-distance compared to their stock counterparts. Long story short, I'm sorry, man, but in its current state, this is a piece of custom content I cannot advise anyone to add to any map.

Lastly,
Cat1981England wrote:[...]- You can spam East and West checkpoints from where the PPC tank spawns. Perhaps the 3 teeth on the nearby door could be made a little larger and moved towards the centre?[...]
So I left this one for the end because it was the question I arguably spent the most time looking into during the week's edit sessions, and if you think that's the preamble for another wordwall, don't worry 'cause there's a minor twist up ahead :p.
Before that though, lemme just use up a paragraph to say that, while at first I was about as skeptical of this possibility's practical gameplay impact as I was enthusiastic about the inventiveness in discovering n' using it effectively (pretty cool find, btw :thumbup:), I figured this might be a good opportunity to try n' understand a bit better the main PPC projectile's nature in terms of trajectory, size (and associated squeezing through slits), splash radius and damage, and all that led to some shed tinkering. Visualizing the shot's path was what would help the most, so its emitter got swapped for a standard flak trail (speed combo's and translocator disc's emitters were earlier, but more visually noisy choices, that ultimately got dropped for the thinner & much more clear flak's), and then that got retooled to stretch as long as it'd need to and never expire, even upon shell detonation, but instead hide itself afterwards (so that dozens of 'em wouldn't start degrading performance), and wait for a console command to show 'em all again. Additionally, I told the PPC projectile's code to keep track of flight time from birth and to swap the trail's standard yellowish colour for a purple one whenever the shells would go beyond the enemy checkpoint node's latitude (ended up taking some 1.8secs of airtime, which was far longer I originally thought it'd be), so that the relevant shots landing on the platform, turret and nearby walls would be visually more differentiated from those landing at the end of the tunnel. Lastly, the PPC cannon's 0.015 spread and 3.8sec firing intervals got axed and cut down to 0.3 respectively for testing convenience because, seriously, it got annoying pretty soon without that.
So, all told and with a working hypothesis that the PPC would be shelling the enemy checkpoint node for maximum possible damage and disruption without moving, in place of a wordwall I give you the resulting PPC spam study picture wall, which, fair warning, is a 9.5MB, 4000px long beast that I'm not insane enough to embed directly.
To offer a quick acknowledgement before explaining this mess, btw, I'd be remiss if I didn't extend some serious kudos to UltraIMG for being the only account-free pic hosting service among a dozen others I tried before it that seems to take its mission seriously enough to allow uploading and displaying of big images there without first mangling them to all hell in terms of format or visual quality; I meant for this pic to be available as a crisp n' clear 9.5MB png file to preserve thick lines detail and that's exactly what I got. Well done, folks, and highly recommended.
Now then, before anyone points out that this looks like I turned the west checkpoint node into a rave party (loneliest. party. ever.) or the central area into an 80s macross anime recreation (pic 5), what I'd like you to focus on, instead, is just how many shots manage to get through because of the projectile's actual 64UU diameter, which isn't all that big. Especially in the blast door teeth closeup (pic 4), the clustered trajectories suggest there's enough room for this to be possible even with a 1.5% spread. Still, that's about as far as I found facts being able to the carry the case for this being a realistically concerning gameplay flaw, as switching back to pic 1 aptly suggests just how few in a barrage of 40-50 shots actually land in the relevant area versus all those that slip past and hit at the other end of the tunnel (pic 6, aka the "artful one"; thanks wide-lens FOV). Oh, and here's the kicker, too: pic 1 doesn't even accurately represent reality, as I had to manually delete about a dozen purple shots (via the viewclass and killviewedactor commands) so that a closer view would look a bit less like a jumble and start making some kinda sense after two barrages. Bottom line is, the worst case scenario looks like 5-6 good shots for every 60 or so (that's an 8-10% success rate), shot while knowing the right place to aim, without any approaching threat or peer pressure, in rapid sequence and without any spread.
As for quantifying the damage, I kept the enemy node up just in case it happened and, true enough, one shot did manage to hit just right so as to damage it (knocked off 90hp), but the fallout mostly concentrated on the turret and the nearby spawning vecs, as later tests conducted from much closer while shooting at the same spots revealed. While a radius of 1870UU is nothing to sneeze at, it still took 4 shots for the tank to go down (received about 210hp of damage each time), while the Aegis died on the 6th. In any case, beyond the first successful shot at the turret, it's doubtful that enemies spawning on the platform would be harassed at all, even if a skilled PPC user did manage to land a few shots in short succession, spaced out at ~6secs intervals.
Already the above might look like there's plenty of hypotheticals being piled atop one another, and all working towards pretty tepid benefits in this "worst case" scenario. Be that as it may, what would need to be done if one were still concerned about this and meant to try n' adequately prevent it? Well, going by pics 2 and 3, taken at the height of some of the lowest platform-hitting shots, either the blast door's teeth would have to be extended down to at least twice their original length (or beyond), or something similar, but more uniform, should be placed there to obstruct shots passing between them, like, say, a st.mesh fence. Which I did, and immediately there arose a host of problems associated with (much) more typical aiming actions across that area: enter picture wall the second. Turrets losing line of sight to enemy vecs lurking next to service tunnel-adjacent platforms, service node platform snipers getting their aim to said turrets blocked, and artillery-type vecs no longer being able to bounce high, node-damaging shots at the margins of the said nodes' alcoves, thus giving defending Aegises a much easier time, IMO all paint a pretty nasty picture as far as the toll that implementing something like this would impose on the map's gameplay.
Bottom line, I don't think it's worth worrying about this; if someone's skilled (and lucky) enough to've managed to get a successful shot across the middle with their freshly spawned PPC so as to've hit the enemy checkpoint node area (and even gotten a frag out of it), they'd be wiser to thank their lucky star and go back to pursuing their team's agenda than staying there and keep trying their luck on that particular roulette, while a precious team resource goes to waste for no good reason. Hell, even if they didn't, their teammates would soon point that out to them, and likely in less than graceful terms, too. With all that in mind, I'm opting to leave this one alone in V5.


Right. With everything up till now covering all the issues brought up about rw1 and how it all influenced (most of) what went into rw2 as well, think it's about time I finally rolled the damn thing out, no? Well, here goes...


ONS-Tanks-a-Lot-)o(-V5_rw2: a 30.9MB (uncompressed) "release WIP 2" addendum to ONS-Tanks-a-Lot-)o(-V5_releaseWIP, hosted here (8.02MB, .rar archive, BioAegis dependency files once again NOT included), still with the intent for the filename to be flattened to "ONS-Tanks-a-Lot-)o(-V5" if no other issues meriting another pass arise. Short and stout [s]teapot[/s] changelog follows:


* rearranged bases' vehicle spawn locations to eliminate unintentional entry in wrong vehicle
* repositioned service nodes' support beams below their platforms to facilitate pedestrian movement there
* extended service nodes' large blocking volumes downward to prevent spawning PPC getting pushed into them
* slightly lengthened jumppad emitters' spark trails and adjusted them so that component won't crash Particle Editor
- other minor tweaks: gave actual aegis vec factories to primaries,matched all central area ramps' underside textures
- integrated notable rw2 alterations (i.e., everything denoted with an asterisk) to existing changelog
- somehow ended up with a 300KB smaller filesize :s (maybe the central ramps' underside textures were unique?)


Aaaand that's about all there is to say here. Lemme know if anything's still horribly broken and I'll see about giving it another look. Barring any such unfortunate development though, Cat (and anyone else, for that matter) are welcome to modify it and use it however they wish.


PS:
Miauz55555 wrote:Thank you for the Book Pegasus.[...]
Ah, c'mon, at almost 8,000 words, 'tis barely even a novella! But you're welcome :).
Image

User avatar
Miauz55555
Posts: 1164
Joined: Sun 7. Jun 2015, 22:12
Location: Germany

Re: ONS-Tanks-a-Lot-)o(-V5

Postby Miauz55555 » Mon 8. Feb 2016, 19:26

Oh a series. I like good stories. ;)

My intend to the Batterys were more like using it like a superweapon, with a spawn time and just 3 shots. But I can follow your argumentation.

I like the gameplay with the Basilisk, good choice Pegasus and a well made vehicle Wormbo.
Thank you both. :thumbup:
Image

Zon3r
Posts: 575
Joined: Thu 7. Apr 2011, 07:46
Description: Don't shoot at me!

Re: ONS-Tanks-a-Lot-)o(-V5

Postby Zon3r » Wed 10. Feb 2016, 00:07

Couldn't find anything horribly broken, maybe my eyes are not that good anymore





My problem with the battery is that even if you are not in it's direct path, the sparks are still hurting you. at least that's what i have experianced
Image

User avatar
Cat1981England
Posts: 2324
Joined: Mon 23. Aug 2010, 15:35

Re: ONS-Tanks-a-Lot-)o(-V5

Postby Cat1981England » Sat 13. Feb 2016, 22:41

Thank you once again for your work P :clap:

ONS-Tanks-a-Lot-)o(-V5b now on the server.
The Universal Declaration of Human Rights, Article 1:

All human beings are born free and equal in dignity and rights. They are endowed with reason and conscience and should act towards one another in a spirit of brotherhood.


Return to “The Creative Corner”



Who is online

Users browsing this forum: CommonCrawl [Bot] and 1 guest