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
). 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
. 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
? 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 larger pic dimension equal to smaller, 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.
