Sorry for the delayed response again, vacation keeps getting in the way of following progress here.
So I tried the RC4 in UEd and I'm afraid I'm not having any better luck with it in terms of play previews automatically and consistently making both windows disappear almost as soon as I press the button. It's gotten me curious enough to want to keep one of those RCs around even if this stops happening in subsequent edits on my laptop just to check its behaviour against that on my desktop PC back at home when I return. Seeing as Cat's (and presumably yours too) own experience indicate this likely isn't a global issue, maybe it can be narrowed down to one or a combo of few factors (contiguous RAM is one possible culprit on my mind right now) and that knowledge can be made more public to later help others dealing with the same problem. Still, all that's of a later, more "academic" concern and won't help get this map through its final steps toward a release version, so for the foreseeable future I propose we just sidestep the whole path network-related crashing discussion and focus on ironing out the map's remaining few kinks instead. To get back to that now, here's the few notes I could still put together.
- Think I neglected to mention it in previous posts, but good job on the node link setup you came up with, J-P - better than the one I cooked up too, I might add
. it combines a standard layout (peripheral lines plus midsection) with a couple o' added quadrilateral "subnetworks" (9-3-4-10 and 5-7-8-1 more prominently) that add to the value of non-midsection central nodes (n3 and n7) and thus make it worth for players to include 'em in their strategic planning instead of just caring about the midsection objectives. What also makes this design effective IMO is that no node immediately stands out as the obvious "victory lynchpin" point to focus on grabbing and controlling, but that strategic value is more "decentralized" and distributed instead, all because none of 'em have more than 3 connections. A nice example of a simple design limitation imposed on oneself contributing to better gameplay instead of curbing it (think chiptune music in the 8-bit/16-bit console era). Anyway, 'nuff theoretical waffling 'bout that now, methinks.
- Took me awhile, but a few days ago I finally took the map for an offline spin and had myself a match with 15 bots. After 2 rounds of pretty open play where both cores got exposed and attacked, I gotta say the map can deliver some quite fun gameplay. Other than the issue of bots abandoning vecs - numerous mantas would be piled up there mostly - by the bases' gates, likely because the RPNs on either side of the gates aren't perfectly centered, which you've already identified yourself and can easily be fixed, their overall behaviour seemed reasonable enough and even helpful. Particularly bots in the Perses would become quite a devious and considerable threat around the map's center, which was a surprise for a raptor aficionado such as myself and further bolsters my impression of how well the vec fits in the map. Notwithstanding a minor usability issue I identified regarding how representative the targeting info conveyed to SPMA turret users can sometimes [not] be (something also present in the UT3-style SPMA and probably best discussed in the vec's own thread instead), I gotta give kudos to Wormbo for the bot logic he added to the vec, as well as those damned AA missiles whose business end I gazed up close a few more times than I'd have liked to
.
- Another bug I came across during the aforementioned offline match that you seem to've fixed in RC4 as well had to do with the collision-less beams running parallel to the spawning cicadas at the distant primaries. Speaking of those nodes, and as a more general observation too, it occurred to me that, out of the 12 objective locations on the map, players can find a flyer spawning in 10 of those, for a total of 14 flyers. Considering the many useful land vecs available, as well as the quite thorough jumppad transit system also included, I can't help wonder whether offering flyers to almost half a full playing crowd's amount of people might be a bit too much and work against the design intent behind the addition of the previously mentioned land-based or ped-oriented elements. Offering 2 flyers per core seems reasonable given the number of players concurrently spawning there at the beginning of matches, but IMO the distant primaries could stand to lose their raptors without much impact to the overall gameflow as they're closer to the midsection. Lastly, the choice to have badgers spawning inside the lower level rather than outside could potentially predispose players to camp that interior instead of driving the vec to a location that would better serve their team's defensive needs for the entire area against oncoming threats from the nearby core, so perhaps moving them outside those walls might be an improvement here.
- Lastly, to address a couple of visual/aesthetic issues, some of the rocks near the bunker primaries' pillbox exits could stand to be a bit rotated/moved in order to close gaps between them and the structure visible when standing at those exits. Also, when I mentioned the addition of a vec teleporter exit-time emitter in my last (serious) post, I was more considering the option of adding one in the class's code that would be dynamically created and destroyed during a teleporting event and would then be propagated to subsequent maps, and less thinking about a permanently placed one at the exit location ...but you know what, this solution looks cool too
.
Alright, I think that's everything there was to bring up about the RC3-RC4 transition. In fact, seeing how you're already on top of most of those issues, as well as the BSP/APA/ZP construction work around the tunnels (wear a hard hat!), it's starting to look like the map is now approaching the quality asymptote its overall design and layout can deliver, with a release version not being too far away now. Looking back to when GLoups' original mapping project was first announced on June 19th, and after the dozens of tweaks, improvements and optimizations Syrma has had added to it since, it may just be feasible to see a release version on its 2 month anniversary/milestone in the next few days. And even if that doesn't pan out, I'll certainly be anticipating it whenever it's ready anyway. As for running out of ideas for the release version's name, well, the nomenclature used up till now had more of an internal coordination purpose to it, so to borrow from a typical practice when a dev cycle ends, it could just get collapsed to the project's name sans the suffixes.
ONS-Syrma sounds fine to me, and it always leaves room for subsequent versions and SPs later on too
.
, so i've just optimise pathing, deleting too closes (50) flying path nodes (
), in the meantime i have to fix these bad driver's bots who don't want to get the vehicles out of the bases and elsewhere, i optimize a little by adding two new antiportal well placed and add exits emitters for vehicle teleporter, replace the two ionpainters by portableionpainters - 