Before proceeding with the unveiling itself, I should note that the goal of this project wasn't to radically overhaul the initial design concept, say, by adding new geometry or considerably altering the extant arrangement, but by exploring what further gameplay quality and thematic improvements could be made atop what's already there through the inclusion of specific pieces of custom content and tweaking some other gameplay aspects that would make a difference on both of those fronts. Likewise, the bar for success in my book is twofold here: first, that the general conclusion be that this version indeed manages to deliver more interesting (tactically and strategically), diverse, yet still balanced gameplay compared to its predecessor; and, second, that the edit manages to also make a convincing case for why the map is good enough to deserve a permanent place on the CEONSS roster instead of being regarded as seasonal fodder to only be rolled out for a couple o' weeks in later October or early November and then be put back in its box 'till next year. "Seasons don't affect map quality, so if it's good enough to host during one of 'em, it should be good enough for the rest" goes the reasoning here. So, is it good enough? Well, the verdict's still out on that, but the CEONSS team's giving everyone a chance to find out, so here's a thread where the community can offer their thoughts n' input on the matter.
Okay, that's enough preliminary yapping. On with the edit's changelog, followed by a breakdown of key changes and a bunch of ideas for further improvement.
ONS-Halloween-V4: edit of ONS-Halloween-C-beta2 (2004 original map by el chico, 2015 edit by Cat1981England)
File size: 17.6MB uncompressed, 7.1MB as .uz2
File dependencies: BioAegis_Tex.utx, BioAegis_Sound.uax, Badgers_V2beta3.u (still, for some reason), Dragon_V3b.u
Release date: November 2020
Editing time: ~30hrs
* Bases: removed an armour pickup, moved the other to windmills' top floor, added top floor jumppads to base turrets.
* Bases: turned windmills' vanes into st.meshes to aid attic defenders (vecs could pass through mover, but infantry and shots couldn't).
* Bases: fixed ground level top step (via wedge-shaped BlockingVolumes) so pedestrians don't get stuck when walking into the windmills.
* Bases: added thin BV wedges at windmills' balconies to minimize jumppad use issues from windmills' sticky outer walls.
* Bases: duplicated windmills' inner lamppost outside to better light some base vecs.
* Bases: highlighted some turrets' presence by adding lanterns on their platforms (from Dinora), fixed planks' walkability.
* Midsection woods: swapped EONS scorp for Stealth Badger Mk.II (from NMP2-PanaleshSE-C) to enable some sneaky gameplay.
* Village: replaced pally with Aegis, on a 40sec respawn timer.
* Village: reworked inn teleporters to one-way system: ground floor to upstairs to roof; improved bot pathing around roof area.
* Village: replaced inn's stock minelayer pickup with -noStay16Ammo variant, 60sec respawn time.
* Village: slightly lowered inn's 3 ground floor windows and removed their glass to facilitate shootouts.
* River: WaterVolumes trimmed & adjusted to span all submerged area, minor current added.
* River: needless opacity material removed (drops Bastien_02.utx dependency), surface made semi-transparent.
* Fort: raptor removed (too many midsection flyers), dragon moved to its spawn point, base expanded to accommodate it.
* Fort: restored top spire, added 5+5 vials at top rim & an ExtWildCardBase (invisibility, UT3 jumpboots with enough charge for 5 jumps).
* Fort: added gameplay/aesthetic incentives to explore northern rock bridge & nearby area.
* Fort: added teleporter system that links to tower top and north end of rock bridge.
* Fort: gates' st.meshes properly mirrored and aligned, front terrain raised & flattened to same level with entrance.
* Fort: fixed tower st.meshes' flicker due to the 2 ramparts' overlap.
* Fort: made spires' xTeamBanners immovable.
* Distant primaries: swapped tank for Badger Mk.II (from NMP2-PanaleshSE-C) to help comebacks against 3vs1 tank situations.
* Distant primaries: slight rendering performance boost by making the 2 non-gate interior textures antiportals.
* Minor node link setup tweak to address quick strategic gain transfers along nearest-neighbour paths by stronger team.
* Removed all ForcedDirVolumes to restore predictable flyer behaviour at borders when dogfighting, upped BVs' height.
* Added better custom collision for StaticMesh'NaThAncientPack.Pillars.PilUp' (thanks GLoups, drops NaThAncientPack.usx dependency).
* Changed all tree trunks to branch-less st.mesh (myLevel.StaticMesh13) to stop vec snagging, kept one SM12 asset to preserve prior art (behind village inn).
* Fixed a number of terrain holes, slightly smoothed river banks' terrain in 3-4 places.
* Raised KillZ by 2000UU so players falling through terrain can't end up alive at bottom of the map and disrupt play from there.
* Added nodes' and locations' names.
* Added some emitters: fireflies around lamps, embers from wall-mounted torches, water spray, plus something extra.
* Reduced green sunlight actor's LightBrightness to 100.0 from 150.0.
* Removed clashing cubemap reflections and/or needless material skins from houses' windows around the map.
* Added grass terrain decoration around some places.
* Minor terrain textures' stretching adjustments to reduce tiresome tiling effect in some areas.
* Fixed all floating wooden boxes around map.
* Changed map's track to the more fitting KR-Atlantis.
* EAX sound support added to fort hall.
* Added changelog.
Acknowledgements, attributions, credits and usage notes:
- CustomWeaponLocker by Wulff.
- YawTeleporter by Wormbo.
- OnslaughtSpecials2 by Wormbo, OS2_RNH fork by me, based on code by _N_.
- ExtWildcardBase by me.
- UT3 Jump Boots by Wormbo (based on JumpBoots by MrEvil?).
- Invisibility pickup by unknown author.
- Dragon originally by Solace, Dragon V2 and V3(b) improvements by Wormbo.
- EONS Scorpion by Wail of Suicide, based on UT3 Scorpion.
- Aegis code by Gorzakk, skin by Big_Al_B.
- Badger by Lord_Don (ONSMinitank model, based on Metal Slug), V1 redesign model & skin by Big_Al_B, some V1 tweaked code by Gorzakk.
- Badger Mk.II code, skin, emitter and sound enhancements (Badgers_V2beta3) by Wormbo. Additional tweaks by GLoups (minigun) and me (exit Z offset when moving).
- Stealth Badger code & skin by Kamek. Stealth Badger Mk.II based on Wormbo's Badgers_V2beta3 code, with further stealth code improvements by GLoups.
- Tavern sign and wooden texture borrowed from Chris 'Oxygene' Urban's ONS-AlenjaForest-SE-ECE map.
* Thanks to the CEONSS staff for the support and subsequent server hosting approval, and specifically to GLoups for helping identify various terrain holes, leftover visual glitches, and for providing a better custom collision model for StaticMesh'NaThAncientPack.Pillars.PilUp'.
* As a standard practice of mine, none of the aforementioned authors - or, indeed, the map's creator or previous editor - were asked for permission for their work to be used in this edit. Also as a standard practice of mine, this project was non-profit work, properly preserved all attribution-related properties & fields, and, likewise, left intact or complemented with further notes where further adjustments were done any and all custom code commentary; further, the project was not used as part of any political message and, similarly, did not attempt to misrepresent previous author's or editor's views as part of such hypothetical speech. On condition of adherence to the same 3 principles - honour previous attributions, non-profit goal, no political messaging/misrepresentation of previous contributors' views - this work may also be further used, hosted and/or remixed by anyone else without asking for permission. Yes, the political angle is extremely far-fetched and only there for completeness' sake.
(Man, wrangling every last bit of that attribution info was exhausting, even for someone who'd been around while most of that stuff was made or got popularized enough to be passed around, and the usage contingencies' wording stuff wasn't exactly fun either. No wonder I never bothered to do any of that before...)
Notable changes:
- To start with what's probably the most consequential change to gameplay, the node link setup (NLS) and vehicle loadout were adjusted based on what better outcomes the map's size and spooky/stealthy theme could reasonably accommodate, and away from known, potential pitfalls. Since Halloween is a medium-sized map, and the dominant team is likely to be in control of the fort node - it's a one-hall structure, so I'm struggling to call it a castle - it was a reasonable concern that the previous NLS would point to the optimal strategy being to fly the dragon over relatively uncontested terrain along the border and toward the distant enemy primary that's directly linked to the fort, bomb it, flip it, and so expose the enemy core with minimal risk. More generally, the dominant team being able to make quick n' easy successive strategic gains along a line of nearest-neighbour connected nodes due to their proximal location, and/or insufficient cover or resources to fight back properly is the kind of scenario typically referred to as "steamrolling the opposition", and if a specific map design allows for such a thing to happen to the defending team's primaries frequently, that's bad news in terms of comebacks, too.
The obvious first step to thwart that was to disconnect the graveyard nodes from the fort. Since the proximal primary enjoys the benefit of being easier to defend or retake, the strategic counterbalance should be that the harder primary to hold, i.e. the distant one, should have the advantage of one extra node connection, thus to the woods and village. By shifting the fort's connection to the core-proximal primaries, this also forces the dragon to either take a riskier path over unfriendly terrain or take longer to reach the next node while hugging the border, and I'm fine with either alternative in terms of balancing. The other comebacks-facilitating step was to eliminate the 3 vs. 1 goliaths problem from the dominant team controlling both graveyard nodes; that's a situation the weaker team can hardly come back from, especially since the primary node's area also affords no higher ground advantage against forces pouring in from the midsection or having come in sight from the nearby graveyard. Replacing those graveyard tanks with Mk.II badgers seemed like the best option because their anti-air role can complement the firepower of the less durable EONS scorpions spawning there, both giving defenders a fighting chance if the enemy dragon does decide to pay a visit; losing your graveyard node and having to fight an oncoming badger that must sacrifice mobility to fire a shell near the settlement primary should be more manageable. Long story short, I'm hoping these changes deliver better chances for the defending team to mount a successful comeback and, as an expression of this effect, that this edit will produce fewer "team stomp" quick rounds n' EvenMatch restarts.
To squeeze in a few more quick notes on the vecs and NLS front, since the map's theme pretty much invites stealthy trickster play, it felt natural to also throw in a Stealth Badger Mk.II at the center node for more sneaky incursions or hill camping. The village paladin also seemed like the near-constant loser when pitted against the dragon: one direct bomb hit and the shield's effectively gone. Since the pally's slow to fire and re-raise its shield between bombs, the only move its driver is really left with is to just take the next 2 hits (shield lost, then death), hoping it buys their team some extra time to respond. Upgrading to the more nimble and sturdy Aegis should afford village defenders a few more meaningful tactical options now (stay and guard the village as a respectable deterrent, or abandon the post and move towards the enemy base-facing hill-line to spam people there?), but that itself needed to be balanced, so a fort-to-village connection, tempting the dragon to go n' do a quick bombing run there, seemed apropos. Likewise, a pesky Aegis spamming your core from the village hills can be pretty annoying, so design tweaks were made all around the bases to help give defenders a better vantage point and chances to fire back, to make remote base resources (turrets) more readable n' more quickly accessible from the windmill balconies/windows, and to somewhat better cover the more valuable vehicles from oncoming shockball spam. Of course, if all else fails, a few base defenders focusing their linkgun fire on the hilltop camping Aegis should be enough to compel its driver to back off a bit, and the fact that the attacker is so far from reinforcements (and extra link ammo) only adds to this not being a smart tactic in the long-term. We'll see about that, I suppose. Btw, it's already been pointed out to me, but in case anyone feels compelled to ask whether the new NLS's design resembling some kind of occult rune was deliberate, let it be known that was purely accidental. A happy, spooky little accident
.- Regarding new custom pickups now, similar considerations about the kind of gameplay the map's theme accommodates apply here, too, in terms of what pickups made more sense to add. At the top of the fort now you'll be able to find n' grab either the standalone invisibility pickup (better than the equivalent relic, IMO, both in terms of gameplay as well as excess code/asset baggage) or the UT3 jump boots. Both options allow for stealthy assaults on the fort, either by dropping straight down and taking minimal damage thanks to the jumpboots, or just sneaking in after taking the long way 'round via the teleporter. Crucially, both empower pedestrian (ninja) tactics and offer no benefit to someone arriving there in a flyer, so it makes sense to be considerate to your infantry teammates and not needlessly pick those up if you're just gonna fly off and attack the fort node through the upside-down ramparts anyway - the pickups for you are closer to the river, on either side of the midsection (dmg.amp on one side and s.shield on the other)
.- Moving on to improvements around the bases, the goal here was to expand and facilitate defensive options, while also providing a first pass at a workable fix to longstanding usability problems. An armour pickup was moved to the windmills' top level to entice and reward visitors there, but once players take the time to look around and outside the openings, they should hopefully discover that the area now provides more mobility options and thus higher tactical value: the windmill is no longer turning, so shooting at enemies' fast incoming vehicles should now be a reliable defensive measure because the vanes won't be getting in the way; what's more, depending on how the enemy dodges and tries to take cover, there's now also two lateral jumppads (with visually pronounced emitters!) that can quickly take a defender to the turret closer to where the enemy may reappear from so they can respond accordingly. Just in case the destination of said jumppads wasn't evident, but also to point out those resources to ground troops, there's a shining lantern near each stationary turret to draw your gaze in.
The bigger issue with the windmills has always been that their outside walls form such a ...weird n' oblique angle with the ground that it confuses the game's engine when pedestrians touch or collide with 'em, usually resulting in players having their momentum instantly canceled and effectively getting stuck on the damn wall when moving or dodging toward it, sometimes even just by touching the surface. At that point, you'll either start to fall very slowly, just stay stuck there until you wall-dodge (or shieldgun push yourself) away, or the engine will decide to let you slide a bit more and then repeat this weird process. The practical consequences of this are numerous: dueling around the outside of the windmills can produce all kinds of annoying results, like not being able to move away from oncoming fire as fast enough as you expected, like trying to shimmy/crouch around the top or bottom wooden rings that surround the structure (there's some tactical value there) and getting stuck, like not being able to walk into the building when standing on said wooden rings because once you touch the brush your momentum gets canceled, and, as of this edit, the windmill was messing with the predictable operation of my jumppads. With limited time in my hands, I had to cut my efforts at a comprehensive solution short, so I just ended up placing some very thin BlockingVolumes to ensure players would not be touching the walls when moving around the mills' entrance/exit areas. It's not the thorough fix I wanted, but after a decent amount of playtesting, it seems to work as intended most of the time (IIRC, one of the western jumppads was sometimes still iffy by the end), so that's the best I could do for now.
Lastly about the bases, the wooden planks leading up to the turrets' platforms got shortened a bit in the hopes they'll be more friendly to bots moving smoothly around there, although improvements to bot behaviour around bases were not part of this edit's goals. Oh, and the outside lamp was mostly added to emphasize that the available scorpion spawning nearby isn't of the stock variety so that players know it's worth the effort to use it
.- One problem that became immediately noticeable during playtesting after the previously mentioned wheeled vehicles were added to the loadout was that those vehicles would often get stuck near the trees around the map's center. The reason for this was that, although all those trees appear identical, about half of them use a collision model that's just a vertical pole, while the other half also feature a horizontal bar positioned pretty close to the tree mesh's roots - to act as a branch one can step on, presumably. With what looks like a random distribution of both models used across the map, the result was enough to strip those smaller vehicles (i.e. badgers, scorpions, and mantas) of their main fighting advantage, namely their mobility, when moving and fighting around the central area. Replacing all the complex collision model trees with their simpler equivalents was a pretty straightforward fix, but for the sake of preserving the map's prior art, and just in case it came in handy later on for some reason (spoiler: it might), I kept one instance of the colliding branch tree, placed behind the village inn, where it shouldn't get in anyone's way.
- Likely one of the most underused areas of this map were the village alleys and roofs, even though both the placement of pickup bases and wooden planks leading to some roofs tried to induce that kind of stealthy gameplay. A likely culprit here is that there's no natural starting point for a pedestrian to just happen outside the village entrance and thereupon start sneaking toward the nearby enemy-owned node. Likewise on the defensive side, most threats players would be looking out for would be flying in from above, taking position along the hills around the locale, or just driving at 'em along the cobbled roads; none of those really necessitates getting on a roof as a matter of attaining some advantage through better positioning. Trying to goose such gameplay along from the defenders' side is what prompted reworking the village inn teleporters to offer access to its roof and those nearby it. The 16 ammo minelayer spawning in the first floor room should hopefully also be an incentive to more tactical players towards more preemptive defense measures, by which of course I mean getting atop the inn's roof, or jumping on a nearby one, and wantonly sprinkling mines all over the place
. Between that change and the placement of a number of JumpSpots & JumpDests so bots can also achieve some basic navigation around the inn, on top of it, and then down from it, I hope this can be a compelling first step toward players taking the time to discover more tactics around the area. Obviously, more is needed, particularly on the village invaders' side, to elevate the area's gameplay value as a whole, but that's for another section of this post to briefly get into, and for another edit to actually attempt.Pending issues and potential ideas for future edits:
- Regarding pickups for pedestrians, and specifically in terms of sufficiency and balance, IMO the map is still a bit lacking. For one thing, there's an obvious disparity in the utility offered by the river-proximal pickup closer to each side of the map: while one team gets a damage amp, the other has to be content with a super shield. Either unifying those two into a single, midsection-bound base or adjusting both extant ones to include both kinds of goodies as potential offerings should be adequate solutions. The other issue here is that, as far as superweapons go, the edit only offers a target painter close to the exit from each base's teleporter. Although global illumination via the SunLight actor has been partially reduced now, that still doesn't mean the bomber's strafing run is suddenly going to be become a substantially more useful tool, tactics-wise, able to dominate the contested proximal primary. What's more, the previously available redeemer left to be discovered along the midsection has now been replaced with a different arrangement, too. Given that there's plenty of places to explore close to the borders that can't outright be considered as part of the distant primaries' locales, I think it'd be worth considering finding a few more places to stash more goodies around the map, including a few superweapons suited to this map's gameplay (e.g. a nuke and/or a portable ion painter) to reward players' exploration efforts. As a last note here, while I know it's very tempting to place something on the roof of the distant primaries' structures, I'd advise caution there, because it could give attackers (or the owners of just of a few vehicles, if no other way were added to get up there) an additional, overpowering boost while raiding the weaker team's primary; not to mention, there's the visual obstruction aspect to consider, since the node's skybeam emitter when it's vulnerable could easily obscure such a pickup's existence, too.
Still, that doesn't mean those areas are impervious to further gameplay-refining tweaks, like, for example, a possible third way for pedestrians to sneak down from some hole on the roof, akin to TitanNecropolis' right flank primaries, or from some crack/opening high up on the north wall that protruding stones allow climbing up to, and then via some kinda short n' narrow shaft (which would exclude direct fire from flyers outside) to approach the node from above once inside and be able to hit it. I'm still not sure this last idea is necessarily well balanced, but just putting it out there, see what others might think of it because, overall, the distant primaries' exposed lines of sight still seem to advantage the locally spawning defenders by a good bit.
- Jumppads were newly added in this edit to enable quicker access to defensive resources, the bases' vehicles number seems adequate to accommodate a full-server team, and there's also a teleporter to take players closer to the proximal primary. Despite all that, given the distances at play, there will likely still be occasions where infantry will be at a disadvantage to meaningfully assist in a comeback attempt. All of this is another way of saying that there's probably still room to throw in a (carefully considered) few more jumppads from the bases' areas toward different sides of the nearby proximal primary (say, toward the top of some of those big rocks) or perhaps others that would subsequently move 'em a bit further afield towards the graveyards even (again, these are primarily matters of balancing, so they should be examined sufficiently), or even one additional JP could push pedestrians almost halfway to the hilltop between their base and the village (that one's a more far-fetched idea). There's more room to experiment in this regard is where I'm going with this.
- Speaking of the village and its new protagonist, the Aegis, as I alluded to earlier, I'm pretty keen to find out just how advantageous its use could prove during late-game, especially around the aforementioned hills overlooking the enemy base. Although I'm convinced that adding the pally variant was a good choice given the Dragon threat, I'm not as sure this late-game siege aspect is equally as calibrated, mostly because the Aegis has a pretty short n' straight way from its spawn point, past the gap between the two houses on the village's outskirts and straight up to those hills. Should that concern prove to be well-founded, one simple solution I can see for wasting more of the Aegis driver's time before they can get into position to cause ongoing problems for the defending team could involve that annoying old friend of ours, the tree variant with the horizontal branch, placed in such a way that it would allow the shorter wheeled vecs to go under it and quickly up the hill (e.g. badgers and scorpions), but which would force the Aegis to drive all the way out to the village's entrance before starting its hill hike. If there's two viable short routes toward the hills from the Aegis' spawn point per side, well, double that solution to match, I guess
.- The other village-related topic here has to do with its sneaky alley & roof play potential, especially in light of the invisibility and jumpboots pickups this edit throws in. A likely reason why not much of that starts in the northern part of the village, in my view, has to do with the fact that whatever tactical advantages it may have to offer end where the cobbled streets begin; this "stealth discontinuity" from one part of the area to the other is what IMO kills any interest in taking the time to move laterally to get the locally offered pickups and improve one's chances against the nearby enemy defenders, and, instead, sees attackers at most just take a generic peripheral-to-backside route to the node. Fixing the discontinuity - in other words, bridging the areas where it makes tactical sense to use stealth - could be as simple as, say, placing some wooden poles on either side of the street at crucial points and connecting them with some thematically appropriate st.mesh, like a rope with dangling lights or something to that effect. Hell, if said lights had even the tiniest annoying corona effect added to 'em, it'd create just the right kind of visual hassle for defenders to not bother looking at too often for (invisible) enemies to hop onto and slip across. Also, a review of the two Wildcard/charger bases' pickups might also be in order here, just in case something more fitting n' enticing could help things along (replace 'em with the same kinda goodies the fort top offers?). Lastly, bot support across a wider area of village rooftops (and elevated cross-street geometry) could round out a potential improvement of the area in this regard.
- I'm starting to consider the names "West/East Settlement" as sounding a bit too much like some kind of old-timey armistice accord rather than a node description suited for use during the general ONS mayhem :/. Assuming more people feel that way, one shorter alternative I'm already thinking of, borne out of their surroundings, could simply be "West/East Logger Camp".
- Okay, time to talk about remaining bugs. While there's no red-hot, game-breaking issue to worry about, there's still a gameplay-affecting one - which would deserve an orange colour code, I suppose - and a couple of lesser, yellow-tier ones regarding aesthetics and filesize/dependency optimization to get into.
* Bug: As already mentioned, the windmills' slanted outer walls can get players stuck and cancel their velocity when touching them, creating all kinds of usability issues. Since this weird angle seems to be confusing the engine's collision calculations for xPawns (that's the player pawn class's internal name) touching the additive CSG, my brief attempts at a fix involved trying to change the angle a bit at a time and hoping that this would stop the issue. Basically, the windmill is an approximation of a conic section, with a bigger octagon as its base and a smaller one at the top, both centered on the same vertical axis; changing the outer walls' angle while not messing up the other properties would therefore require moving one octagon away or towards the other. So as to not mess up anything to do with the top floor, I began progressively lowering the bottom octagon's vertices, but even after 10 tries or so and a total 70UU height reduction, after rebuilding geometry each time the problem still persisted. Pushing even further down with one more iteration, I noticed the terrain had now suddenly disappeared after a rebuild, at which point I decided the hour I'd dedicated to fixing this with no result was a waste of time and no more should be spent there. All told, anyone seeking to fix this should be prepared either for some other kind of vertex editing (i.e. inward/outward relative to center), or, as a more radical but surefire way to "refactor" the building and eliminate the problem, to outright change it into its cylindrical equivalent. After all, even by a realistic standard, there's plenty of cylindrical windmills around the world, and they seem to've performed their function just fine in times past.
* Bug: The Mk.II Badgers of this edit have been myLevel'd, but the Badgers_V2beta3.u requirement still persists for some reason, needlessly inflating the map's memory footprint and extending its dependency tail. To offer a bit more background here, addressing the problem of players falling through terrain was a pivotal concern for a number of decisions during this edit's development. For one thing, that's the main reason why Halloween-C-beta2 by Cat1981England was chosen as this edit's basis, since Cat specifically mentioned in each successive beta version of his presentation thread that he had "fixed all the holes [he] could find" plus "a few more" later on. Sadly, in hindsight, that didn't turn out to be much of a guarantee, as about a dozen more holes kept cropping up, but thanks to the internal review process they got caught n' patched, too, and the player experience on that front should be more or less reliable.
That "more or less" part does have another insidious caveat though: steep angles in conjunction with the terrain's big tile size. The existence of plenty of steep angles around the border was itself part of the reason why the slightly customized, and thus myLevel'd, Mk.II Badgers had to be introduced, since the "stock" Badgers_V2beta3.u vehicles are still liable to have a player exiting halfway through terrain while driving along such a steep angle and thus falling through the ground, whereas as of 2016 or so (in some Grit edit, IIRC) this adjustment has been applying an extra Z offset increase to exiting positions to prevent such mishaps. The other part has to do with tweaks GLoups did to the Stealth Badger Mk.II's presentation and to both variants' minigun damage output last year; as a package deal, those Badgers can be seen working well in his NMP2-PanaleshSE-C edit, and that's where this edit gets them from. Problem here is they were only half-myLevel'd in that edit (yes, that's possible, even with a single .u package dependency), and so that arrangement carried over to Halloween-V4, where, after some effort, I thought I'd successfully managed to myLevel all additional texture, sound, st.mesh and sk.mesh assets, and properly connected all references to everything so that Badgers_V2beta3.u would no longer be needed. No such luck yet, for some reason, so the map still keeps asking for the .u package :/.
Edit: oh, I almost forgot the salient part about why the terrain's big tile size matters here. See, if instead of small n' more tiles, a mapper tries to cover the same area with fewer n' bigger tiles, that's generally a workable, and perhaps quicker, way to deal with the geometry aspect of terrain creation. In the exceptional cases where those spaced-out terrain vertices form steep angles on the ground , however, the collision physics can sometimes allow players dodging toward the middle of such edges/faces, or even falling on to them from above, to just clip right through those triangles/tiles as if terrain wasn't even there and fall under it. I've had that happen a few times during playtesting this edit and did a few adjustments to, hopefully, ameliorate it as much as time permitted, but this is yet another mini-bug to watch out for. Sadly, no easy way (or tool) to "refactor" this exists, AFAIK, meaning one can't quickly or procedurally generate a vertex-richer equivalent terrain from a vertex-sparser source with different tile sizes while preserving the geometric arrangement. An unfortunate side-effect of going with 16-bit grayscale as the terrain's vertex storing format, I suppose since it's so foreign to most picture editing software to be handled properly.
* Bug: this final bug is easy enough to describe quickly, and isn't yet certain it even manifests in a client-server context either, but I'm listing it here for completeness' sake because it's just weird! For some reason, the fort hall floor or its outer walls' top texture might flicker black when shot with projectiles that leave behind a scorch mark projector, and then go back to normal a second later. There also seem to be certain conditions required to cause it (don't fire onto other surfaces elsewhere in the map beforehand), and some other behaviours can stop it from repeating afterwards (move further away a bit, fire one of said weapons, and it stops even when returning). To illustrate how it looks, here's a pair of visual aids created while discussing this internally. If anyone's actually managed to have this happen to them while playing online, please tell us about it so we'll know it's worth spending time to try n' solve it. Cheers.
- Turning attention, finally, to fleshing out the map's thematic execution, the general idea is that there's plenty of room for improvement here. To deal with the less complex parts of the environment in this item, there is, for example, a skybox emitter that spawns four swarms of bats and flies 'em along the backdrop's length. Not only is it pretty inconsiderate in terms of resources consumption (I think it has a MaxParticles value of 1000!), but the 2 bat textures themselves look pretty silly to be considered a serious, never mind spooky, addition to the theme. Something better - and more memory frugal, too? - could/should take its place. Also, for as gloomy and ghoulish an occasion as Halloween is supposed to be, it's a pretty clear n' calm night all around the map, so perhaps a cloud sheet and/or an equivalent ground-facing projector as seen in other maps could be experimented with here to see if it enhances the theme. But even smaller n' everyday items around the map could perhaps be punched up in a similar manner, say, by having the special pickup bases or the lockers be pumpkin shaped or something else to that effect. As another thought, TitanNecropolis might also be able to contribute some appropriate ambient sounds to touch up the atmosphere 'round some places here (e.g. crow calls, chains rattling, etc.).
- A pettier aesthetic niggle I guess I might as well confess to has to do with my standard practice of challenging myself to try my hand at a new UEd aspect or discipline, big or small, with each project I take on. This being a smaller-scale project, I figured I'd just try to create a terrain decoration layer out of scratch so as to liven up the map with patches of grass where it made sense to. After a couple of UEd-crashing false starts, the easiest way I could figure out to bootstrap the process was to just clone one of the extant layers' myLevel'd textures, give it a grass-related name, point the terrain actor to it, and just go grass "painting" from there. The most sensible choice was the terrain texture layer with the smallest use, so I copied the village's cobblestone tex. Everything went fine, and for about an hour or so afterwards I proceeded to happily sprinkle grass around the map like some kind of inebriated, ancient Greek deity of fertility
. Trouble is, after I was done and pleased with my results, I completely forgot to swing by the village and delete most of the grass that would logically still be there, so now that part of the map delivers a slightly schizophrenic kind of visual storytelling, with the village looking otherwise pristine and lived-in, while the cobblestones appear in such a state of abandonment that weeds have completely taken over in some places! Oh well, something to remember to cull for next time, I suppose.- As far as upgrades requiring trickier execution go, these dopey, Pacman-esque ghosts could perhaps be retooled into something that, on occasion, could even affect gameplay. Of course, that would require moving away from their current, collective, emitter-based implementation and, instead, manifesting/spawning them as independent, customized roaming actors, similar to the flying monsters of the RPG gamemode. (I think so, anyway, since I've never actually played the damn thing.) Alternatively, I could reference some odd ONS maps where editors did briefly include earthbound monsters, like an older version of VK's-Playground that few might remember, or an even older version of All-Fall-Down (and I think CEONSS has also briefly hosted another, small-sized ONS map that featured forcefield cells holding monsters in 'em that could be unleashed, too? Edit: it's ONS-MiniCubeAlien). Anyway, you get the idea.
Theoretically, one of the flying types could be subclassed, given this Pacman-derived appearance, get stripped of all its targeting & attacking functions so it'll just roam around (based on what though? pathnodes?), making the occasional sound or changing direction, and one could also make it agnostic to typical TakeDamage, Touch or EncroachedBy/EncroachingOn calls for non-bWorldGeometry actors - except, optionally, for rare situations. Perhaps there'd be something like a 1% chance that if a player or vehicle passed through it, the player would be hurt a bit or have their current weapon stolen, Mario Kart-style, or all passengers would get instantly ejected from their ride for their insolence - you treat the ghost disrespectfully, it tricks you back
. For a reason to touch 'em at all, there could also be, say, a 3% chance that something good might happen. Anyway, there's plenty of other ways one could go about this, but I hope you see where I'm driving at with this (straight onto a ghost!). Anyone with some UEd/UScripting experience, and the time n' inclination to try could come up with something interesting here to excite players, so don't be afraid to roll up your sleeves and let your imagination roam like a retro arcade apparition on Halloween night.- Lastly, and tying into my aforementioned view that there's a lack of sufficient superweapons around the map, a ScriptedTrigger/UnrealScriptedSequence-based Trick or Treat system could be attempted to address such gameplay and thematic deficits in one, well-executed package. Again, there's obviously a multitude of ways one could go about creating such a thing, but since the map has already introduced two thematic "characters" to players, I've slowly begun gravitating towards a specific concept involving them. Since I've no idea if or when I might again try my hand at any of that, however, I think it's best I refrain from going into specifics so as to not bias anybody else's attempts.
Instead of implementation guidance, perhaps it'd be more meaningful to offer a different kind of suggestion here: early on in the Dinora improvement project thread about two years ago, in this post, I recommended that people interested in getting a firmer grasp of ScriptedTrigger usage could examine a specific pair of maps whose arrangements could help showcase how a more aesthetics-oriented, environmental/thematic sequence, in Dinora's case, or how an interactive one, in Foundry's, can be constructed from its constituent parts (i.e. triggers, use triggers, emitters, movers, etc.). Acquiring familiarity with each of the two legs of ScriptedTrigger crafting could then inspire experienced mappers/editors to try more advanced projects, which is where the third, then-unnamed map could serve as an additional source for information and guidance.
Perhaps I wasn't so sure about mentioning it back then, but by this point, I'm convinced of this little known map's great educational value in this regard, so I might as well just go ahead and tell anyone interested enough in this geeky kind of endeavour to've read this far to give ONS-MudSling][ a download and examine all the interactive little touches its creator, Glenn 'SuperApe' Storm, has baked into it - and, conveniently, even dedicated an entire site section to present for curious enthusiasts - some as highbrow parts of the map's gameplay (the bunkers) and others as just little experimental touches in environmental immersion (burning trees). In case anyone's wondering why they may've never come across MudSling][ before in an online setting, btw, that's because, sadly, the map is otherwise not very notable, so the gameplay quality it would reasonably deliver could be considered basic at best, thus not making it worth a roster slot for any ONS server to care to host. I guess one could think of it as a slightly bigger variant of ONS-Halo-Bloodgulch (but with an extra middle node) or an UP-SandCrack-resembling node layout, but with a less distinct theme and far less developed objective areas - basically, a "terrain map". You're mostly downloading it to get a copious amount of pointers on complex ScriptedTrigger work is my point here, but I guarantee it'll be well worth your time if you do decide to look into it and don't get intimidated by, say, almost-40-items-long sequences or more than a dozen actors associated with such a chain. Even if some of that might sound daunting to you at first though, trust me, it's a specimen that's worth grabbing and keeping in your UT research folder for future study n' reference
.Alright, I think I finally managed to squeeze everything I intended to talk about into yet another humble (7K) wordwall
. While this project was fun to tackle, and, just as crucially, helped a bit to keep me sane during those heady, early-November days, I'm happy to've now put it behind me. By this I mean that, barring any disastrous game-breaking bug that slipped by and might need urgent patching, I'm not really planning any further work on this map anytime soon. That said, please don't let that dissuade you from offering any feedback or suggestions you might have, as that could still be helpful in the short-term with assessing this edit's gameplay value, balancing, and, most importantly, its spookiness factor! Whether it proves to be all that Halloween enthusiasts might've hoped for or more of the same, I hope everyone gets to have some fun with it.