[Map] Ons-Syrma-

Anything about UT2004 mapping, Uscripting & more
User avatar
GLoups!
Posts: 371
Joined: Fri 3. Feb 2012, 17:57
Description: Just play for fun.
Location: Fr

Re: [Map] Ons-SyrmaMMXIV-

Postby GLoups! » Fri 4. Jul 2014, 12:51

No it is just the base of an ancient former, it'll respawn nothing here, moreover I wanted give a look to the performances although it they this seems to me already valid I shall take advantage of it to correct certain small details.

gain 10-15 fps by merging all polygons and convert alls to semi-solids.
Last edited by GLoups! on Thu 7. Aug 2014, 11:06, edited 1 time in total.

User avatar
GLoups!
Posts: 371
Joined: Fri 3. Feb 2012, 17:57
Description: Just play for fun.
Location: Fr

Re: [Map] Ons-SyrmaMMXIV-

Postby GLoups! » Sat 5. Jul 2014, 22:42

And I have made a small video of the card(map) for those who do not want to get bored with theses files.

[video]http://www.youtube.com/watch?v=dVemVU_udMc[/video]

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

Re: [Map] Ons-SyrmaMMXIV-

Postby Pegasus » Mon 7. Jul 2014, 01:27

Oh hey, GLoups released a new version on Monday! Oh shit, can't find the time to properly look at it and take down notes 'till late Saturday :/. Sigh. Anywho, first off, props on continuing to work towards improving this, GLoups; shows you really care to deliver something good for ppl to play with instead of firing off a single release, giving up and moving on to something else so big ups there :).

Now then, although no list of all the changes between versions has been supplied here (something to keep in mind for the future perhaps ;)?), I think the ones pertaining to the more fundamental design issues I mentioned in the last post aren't too many to keep track of and quickly go over here. In broad strokes then, simplifying the design of the ruins nodes and spreading some of the non-primary objectives more towards the periphery should both help improve gameflow and movement from one area to the next. The jumppads transit system you added will likely also contribute to pedestrians rejoining the action after losing their vecs (or heading out on foot) much sooner and, therefore, is a pretty good idea. Lastly, there was some improvement in the cores' and proximal primaries' design by removing the surrounding covers in the former's case and shrinking the shield cover in the latter's. OTOH, the degree to which these objectives are covered and amount of maneuvers they necessitate before an attacker can begin damaging them without remaining unreasonably exposed in both instances still has me reserved about how easy it will be for those nodes to change hands, or for matches to manage to end within regulation time, for that matter. To my mind, forgoing the basements and moving the cores topside is probably the most meaningful way you can help matches along, but, in the end, I'm just offering thoughts and feedback here; this is your map, so the final decision is yours to make. Also, talking about the rest of my previous comments on other aspects of the map which didn't see any change (e.g. volumes & BSP's complexity, improving the map's character), I'd say those still apply too.
At any rate, regarding the major stuff, we'll see how things turn out in live play tests sooner or later, I suppose, and we'll be able to discuss 'em further after that, but since I'm getting the impression that the overall design is getting locked into place with each new version, I think it's time to move on and go down the list of various "post-beta" issues I've kept in mind to point out for awhile now, many of which could help improve the map on a smaller scale, but still in useful and practical ways. So, let's get to 'em.

Bases:
- Observing the AA firepower on offer by the map's vehicle loadout (3 HellHoundss plus a KingHH per side for a total of 5 + 2 for the team controlling most of the map), I'm guessing that, just like me, at some point you began thinking that offering Falcons at cores might be a bit too much for a map of this size and lacking in any other of the usual kinds of OP vecs (minos, bios, krakens, etc.), and you tried to compensate for it through those custom benders. Still, this is pretty much a textbook case of the escalating arms race spiral, and, given how the vast majority of the flyers in this map are of the stock variety, I can't help worry that those will be the ones paying the gameplay price of all this by getting 1-shot in their raptors again n' again :/. The alternative I'd recommend here would simply be to remove the Falcon, or if you still want to have a custom flyer in that UltVecFactory's vec pool, to use something less powerful, like a Phoenix that only has 250hp and accelerates similarly to a raptor. Only saying this because, next to OP flyers and tanks, the HHs' beams are one of the most persistent annoyances you can find in maps featuring custom vecs (by far worse than the Railgun tanks too, considering their turrets' lack of upward aiming limits).
- The other custom vec whose use I'd call into question is that EuScorpius thing. This was honestly the first time I've ever run into it after hunting for and checking out a shedload of custom ONS content (vecs, weaps, other scripts and mechanics, etc.) for years, and even after trying it out, I still had to go through its script before I could understand what all about it was different from a stock scorp. In case anyone's wondering, essentially, the only changes made are that it has ~4 times the scorp's ground speed (4000 vs 940) with the accel and gears ratios slightly tweaked to accomodate, and it features built-in air control; that last one's not much of a bonus when maps that include it are hosted on servers like CEONSS that already have the stunt mutator enabled as a standard too, so eh. Oh, I forgot: for some reason, it won't eject drivers when flipped upside-down too, but I'm struggling to call that a plus. So I guess this thing exists, but the main Q here still is, why use it? If it's to get players a bit faster to the nodes, they're not exactly that far away, and the jumppads you added do a lot more to help with that IMO too. Additionally, the map's quite anomalous terrain seems more liable to send that thing flying in all kinds of directions the driver didn't intend for it to go toward instead of being conducive to its use, thereby reducing the impression it'll leave on players even more than the fact that it looks and fights just like a scorpion. Tbh, I don't expect the EuScorpius to get much use in online matches, and instead, I'd propose swapping it with the more trustworthy and distinctly different EONS Scorpion that, I think, already resonates with many folks' tastes regarding its toolset (decent speed, but also has a boost for quick jolts, EM balls seek mantas and are better against peds up to mid-distance, and the kamikazi feature helps against bigger armoured enemies).
- I realize that the antigrav PhysicsVolumes right above the cores were placed to block enemies going straight through, but, contrary to other, more established, ways of achieving that same result (say, a simple st.mesh grate), this method doesn't just offer the chance to have some silly fun with the team's land vecs placed there, but also has the unfortunate side-effect of force-exiting pilots from their flyers when they move in and not allowing 'em to reenter until the vec has been pushed outside the volume with repeated shock core shots or whatever. Moreover, since the volume extends below the ground level too, there's also the possibility for enemies to employ even more bizarre attempts at stealth while attacking, such as getting atop the core and jumping up, which will then bump their heads to the force field's rim above and let them float around while remaining relatively unseen (poor lighting there doesn't help defenders either). At a minimum I'd recommend significantly reducing those PVs' height, if not considering outright replacing 'em with something more typical that gets you the same result.
- There's two visual glitches in the base areas: the frame that the EuScorpius spawns on flickers (easily fixed by deleting the 2 duplicate st.meshes), and there's some flickering also going on with the big grills' st.mesh borders, always at their 2 NW corners (I think that's the myLevel.Base.mur4). Since the problem seems to be built into the asset itself, a simple fix would be to just drop 'em and recreate the geometry with an additive and a subtractive BSP, and applying the same texture.

Distant primaries:
- Relative to the node's disc & shield, it seems like the size of the hole between the 2 floors is holding the design back from delivering the gameplay potential the area has. If you consider, for example, the geometric arrangement of areas like Urban's cores, Icarus' lower central node, TwinFang's proximal primaries or Alien2's central node, IMO the common factor that allows for fun duels to happen around the adjacent objectives is that the vertical lines of sight are quite broad and uninhibited so players can target each other with enough room/variety - hitscans, splash damage attacks or anything else. Here, although the bunker is big enough along the E-W direction, that little hole in the middle is all the room that enemies on different elevations are allowed to use to thread their shots through, and the result may well be that the playstyle around that node often devolves to blind fire (shombos, lobbing flak shards) and waiting for the other person to drop or ride the lift to their level first so they can win through ambush (that's me trying to avoid calling it camping, btw). I feel that a bigger degree of freedom there would help things along, and you could get that not just by altering the BSP (hell, most of the top floor could be comprised of st.mesh catwalks just as easily), but by optimizing the area in other ways too, such as by having a lift (or jumppad) at either side instead of a bigger one near the middle, where players are more liable to step on it and ride it up by accident. I mean, hell, since the invisibility pickups were removed and those boxes don't provide as significant a role as they did before, maybe the rearrangement could see them reduced in numbers and moved more towards the back n' center of the lower level as one way to free up space and put some more distance between the useful mechanics and the people using 'em while fighting.
Additionally, examining camping potential can be viewed through the vecs' perspective too. Since the doors are big enough, I think we can safely assume that ppl will try to drive in and park all kinds of smaller, wheeled rides to help retain control of the area, from scorpions to badgers and beyond (even raptors fit through!). In that sense, perhaps the doors' frames could stand to be shrunk down a bit in order to ensure that fighting taking place in there will be more of the pedestrian variety and not as much a cheapened camping affair. Given the reduced lines of sight across them, btw, I believe the doors themselves could be removed altogether without risking that becoming a disadvantage to the node's defenders (think garage nodes in Battlefront & OmahaBeach that play out well enough without needing doors). Axing the 6 pairs of doors will also save on server resources, as proximity checks for any nearby actors are done per tick.
- The purpose of the big trench area right outside the bunker's lower entrances being enclosed so that wheeled vehicles falling in can't drive out (well, without abusing the stunt mutator, anyway) also eludes me. Wouldn't facilitate the game's pace more if, say, instead of vertical walls, the eastern and western sides of it were inclined terrain that the vecs could drive on (center-facing sides could still remain undriveably steep to retain the original design's intent too). More to the point, instead of having the single, overly complex BSP shape both the bunker and the trench, wouldn't it be simpler to limit it to just the bunker and get the same result outside of it through terrain manipulation? Just a thought there...
- Of the top floor's windows, only the secondary-proximal one provides a long-range line of sight for attackers to "pinch" the node with a hitscan weapon; I retreated as far away as the fog would allow, but the windows closer to the cores still didn't provide a clear shot. Was that intentional? If not, making the windows slightly taller could afford attackers a slightly better chance at putting pressure on the defenders inside.
- On the visual side of things, all sliding doors seem to have some kinda realism issue when sliding open, either by being visible through the walls (top ones) or by partly obstructing the nearby windows (lower ones). Implementing the previous suggestion about narrowing the door frames a bit (and shrinking the movers down in the same axis accordingly) should solve that. Alternatively, you could try just making the top doors a bit thinner and the bottom, node-proximal movers retract a bit less or something.
- Lighting inside the bunker is still poor. While the mural/poster in there doesn't exactly fit the theme (:p), I could barely make it out because of the lack of any light source inside. Admittedly, in the YT vid you posted things seem a bit less dark, but that might have something to do with YT's own code tweaking the image as the raw video was being encoded - wouldn't be the first time we've observed that either.
- Moving the invisibility pickups to more neutral territories was a good idea, but the U.dmg pickups right outside the bunker, I feel, are part of an overall problematic trend that I'll address later on in the list in whole.

Peds' transit system:
- As I alluded to previously, jumppad transit systems are a great method of getting peds back into action in large maps; well, short of expecting them to suicide and respawn somewhere with vecs anyway. Still, when it comes to specific and commonplace features in maps like jumppads, teleporters, pickup bases and other things, it helps when mappers try to maintain some consistency in their visual/design language. Simply put, it's best that all jumppads use the same st.mesh and accompanying visual effect across the map, and the same goes for the other aforementioned objects. In this map's case, both through players' own experience and through your previously established example, ppl knew what to expect the jumppads to look like (there's one right outside the distant primaries), but now you're introducing a visually different base with a translucent puff emanating from its top. I think it'd be best to just pick one st.mesh of the two (sg_Mechammodispenser and AmmoChargerMesh) and apply it across all the map's jumppads for the players' convenience and quicker communicating of their nature. You may also want to consider adding/changing any existing emitters on top of your jumppads to the more informative, directional ones as well, considering there are places where multiple jumppads are nearby and it's not easy to tell which way they'll send you flying. If you do decide to add those, make sure you grab a rather lengthy one that has its bDirectional property enabled (say, from the latest MasterShower version) so you can quickly duplicate and reorient them with the rotation tool as you need instead of having to calibrate the emitters through UEd's wonky Emitter Editor by hand each time ;). Lastly on this topic, those bigger jumppads & relic pickupbase combo platforms come off as particularly confusing from afar too. You can only tell there's jumppads when you get close (the texture pretty much obscures 'em) and it's even harder to tell there's a special pickup in the middle of that whole doodad unless you're right up to it - again a matter of visual design needing some untangling IMO. Why not just split those across their numerous constituent parts and keep things more understandable instead?
- The map attempts to improve pedestrians' movement experience not just through fast vecs and the jumppads system, but also through offering Relics - specifically 3 Relic of Haste pickups. Although after the latest changes it could be argued that there's little need for still having them, I can see the argument for keeping them around - say, their usefulness during fighting or dodging mantas. Still, at around 140 classes, 3 dozen textures and a dozen sound clips in total, the entire XRelics package does come at a cost in terms of extra filesize, so might I suggest using the standalone RoH from BiggerBeerBattle-V2-K instead, since it's far more lightweight, uses the proper texture for its pickup (instead of the '?') and displays the relic's icon in the proper place on the HUD (rather than on top of the clock)? Edit: hmm, I see you've replaced the invisibility pickups with their relic counterparts now too. IMO the standalone invisi pickups are better in that they don't last forever and allow their user to remain cloaked while firing too, so they're much more fun when grabbed, but it's up to you how you choose to handle the map's resources budget.

Misc stuff from all over the map:
- As I said above, good job simplifying the ruins secondaries and spreading the nodes a bit more apart, GLoups; I'm confident the map will play much better because of it. Of the nodes that remain near the center, however, and are the most likely to bring out your map's character, I think the one that can most easily be improved for the most gain is the node inside the dilapidated barn, "old house node" is the name. Basically, I think it's a fine environment to fight in, but it feels too cramped, and for no real reason either since there's not much around it that necessitates it being that way. I was toying with that thought for awhile and then decided to open UEd and try making those st.meshes a bit bigger, see how it'd affect gameplay. After a few tests, I think that enlarging it by a factor of 1.4-1.5 in the X and Y axes would offer players fighting inside there a bit more breathing room without making the whole thing too big and, thus, vehicle dominated (here's a couple o' pics I snapped of it in V2 while the minigun turret was still there).
- Standard weapon lockers force players to throw their weapons when they're almost out of ammo if they want to get the full amount when they replenish, but that problem's been solved with Wulff's CustomWeaponLocker class that's already prevalent among dozens of maps. I'd highly recommend replacing the map's lockers with the CSLs and, to use a previously named map, you can find them in BBB-V2-K. Mass upgrading would be as simple as selecting all WLs in UEd, copying, pasting inside a text editor like Notepad, doing a simple word substitution (all instances of "WeaponLocker" changed to "CustomWeaponLocker"), copying again and pasting back to UEd; you can also cut the original WLs to avoid having to use different groups, but you'd have to do the final positional adjustment by hand unless you used some reference point or actor.
- On top of the previous point, normalizing the lockers' weaps/ammo across the various nodes would also be prudent (a recommendation for the typical loadout that WLs are expected to deliver can be found here, btw). Bio, grenade launcher, rockets, minigun, and some kinda sniper are part of plenty of people's usual arsenal; no point hampering their playstyle without reason. Mines, OTOH, I'd recommend being much more judicious about offering, especially via weapon lockers.
- Some of the superweapons on offer seem like overkill - the Nuke Layer to some extent (spawning so close to a node too!), but certainly the Nuclear Strike Painter would probably be the ultimate trolling device around late-game and in the middle of the defenders' base. Hell, it's not even a guess at this point; someone's already gone and illustrated just that, probably with ample joy. Maybe tone the goodies down a bit by offering something a bit less over the top? Most of the other content in the map, whether stock or custom, seems pretty balanced right now, so these stick out like a sore thumb.
- Parallel to the previous point, and as briefly mentioned before, many of the map's special gifts seem to've been place a bit too close to non-primary nodes, thereby making it a pretty generous gesture towards the team controlling them and disadvantaging the attackers: U.dmgs, Ions right next to primaries, Nuke Layers, Mega Shield Packs, etc. Why not spread more of that stuff in less important locations and encourage exploration through that instead of ample chances for quick and painful node takedowns within a few secs? As an example of what I'm point towards, placing those teleporters at the bottom of the lakes was a pretty nifty idea, gameplay-wise. Perhaps a few of those barren high hills could have a reason making 'em worth visiting.
- Speaking of goodies up on high hills (get your minds off the gutter plz :p), are those two 9sec ioncannonkillvolumes really necessary anymore? I mean, nobody's getting killed by such a timer, so they're just there consuming server resources looking for target pawns per tick in vain. Personally, I'd advise removing 'em.

General aesthetics:
- I'd advise doing another visual pass to look for and fix the numerous instances of jagged terrain around the map, especially around hills; for a little bit of smoothing work, I believe it can go a long way towards improving the impression the map will leave on people.
- While their surroundings conform to a more contemporary theme (concrete, industrial, whatever you wanna call it), the elevators themselves seem to've been lifted straight out of some nightmarish medieval environment, and unavoidably clash with the visuals of everything around 'em. Might I recommend trying out some st.mesh that's bit more fitting?
- Can't rightly put my finger on it, but there seems to be something slightly off about the skybox's emitter: I'm not sure it's completely aligned with the painted sun behind it, and the corona/glow seems a bit too big, while the bright spot in the middle a bit too small. Or maybe it's just me. Anyway, just nitpicking here.
- The skybox's bottom texture is visible from within the playable area. You can easily fix that by creating a new ConstantColor inside any myLevel group and setting its colour to be the same as that of your outdoors zone's fog; that seems to be the way the stock and early/ECE maps I examined are doing it.
- That moon is freaking me out, man! Dunno if it's the colour highlights at its edges or its size, but does it really need to be there :p?
- If I'm interpreting it correctly, it seems you were trying to fix your NewWeaponBases' misaligned textures, and, for what it's worth, your instinct to try changing something about their skins was right too; it's just that the right answer is to delete (or clear) both skins instead of trying to add a second one. You can do that for all 8 in one swoop too: select one > select all > F4 > Display > Skins > clear both.
- Dunno if it's new in the later versions or if I failed to notice it in the original one, but either way, kudos on putting together the material sequence for your level's screenshot too - gotta love the dedication and meticulousness going on here :).
- Put your name in the level's LevelSummary>Author field, man! It's your own original map, you deserve that!
- Syrma is a pretty memorable name for a map as it is, but I think that roman numeral for the year at the end kinda spoils its uniqueness, and it's largely unnecessary too; why not just simplify it to the shorter ONS-Syrma-v* instead?


Phew, think I've finally covered everything. Hope you've found some of that useful for further improving your map, GLoups, and keep up the good work! If I had one parting tip to give, it'd be what I said at the top: keep a .txt changelog and/or TODO list combo so that you can collect your thoughts and don't forget any good ideas whenever one hits you! Oh, and to have fun mapping, of course :thumbup:.
Image

User avatar
GLoups!
Posts: 371
Joined: Fri 3. Feb 2012, 17:57
Description: Just play for fun.
Location: Fr

Re: [Map] Ons-SyrmaMMXIV-

Postby GLoups! » Thu 10. Jul 2014, 22:49

The least that we can say, Peg, you give me food for thought, as I have not assimilate all, I keep the most important for later but at the moment I am little in a dead end, after several trial days and of counter tries(essays), and I think I need help.
At the crossing, I take this opportunity to mention this, as i'm not been able (I do not know why) to make a dedicated server to look for errors in the map, i find this and that's the log :

Code: Select all

Dedicated Server Log:

[code]Error: ONSPowerNodeSpecial ONS-SyrmaMMXIV-v7.ONSPowerNodeSpecial0 (Function Onslaught.ONSPowerCore.RateCore:004E) Accessed null class context 'VehicleClass'
Error: ONSPowerNodeSpecial ONS-SyrmaMMXIV-v7.ONSPowerNodeSpecial0 (Function Onslaught.ONSPowerCore.RateCore:0070) Accessed null class context 'VehicleClass'
Error: ONSPowerNodeSpecial ONS-SyrmaMMXIV-v7.ONSPowerNodeSpecial0 (Function Onslaught.ONSPowerCore.RateCore:0098) Accessed null class context 'VehicleClass'
Error: ONSPowerNodeSpecial ONS-SyrmaMMXIV-v7.ONSPowerNodeSpecial5 (Function Onslaught.ONSPowerCore.RateCore:004E) Accessed null class context 'VehicleClass'
Error: ONSPowerNodeSpecial ONS-SyrmaMMXIV-v7.ONSPowerNodeSpecial5 (Function Onslaught.ONSPowerCore.RateCore:0070) Accessed null class context 'VehicleClass'
Error: ONSPowerNodeSpecial ONS-SyrmaMMXIV-v7.ONSPowerNodeSpecial5 (Function Onslaught.ONSPowerCore.RateCore:0098) Accessed null class context 'VehicleClass'
Error: ONSPowerNodeSpecial ONS-SyrmaMMXIV-v7.ONSPowerNodeSpecial4 (Function Onslaught.ONSPowerCore.RateCore:004E) Accessed null class context 'VehicleClass'
Error: ONSPowerNodeSpecial ONS-SyrmaMMXIV-v7.ONSPowerNodeSpecial4 (Function Onslaught.ONSPowerCore.RateCore:0070) Accessed null class context 'VehicleClass'
Error: ONSPowerNodeSpecial ONS-SyrmaMMXIV-v7.ONSPowerNodeSpecial4 (Function Onslaught.ONSPowerCore.RateCore:0098) Accessed null class context 'VehicleClass'
Error: ONSPowerNodeSpecial ONS-SyrmaMMXIV-v7.ONSPowerNodeSpecial6 (Function Onslaught.ONSPowerCore.RateCore:004E) Accessed null class context 'VehicleClass'
Error: ONSPowerNodeSpecial ONS-SyrmaMMXIV-v7.ONSPowerNodeSpecial6 (Function Onslaught.ONSPowerCore.RateCore:0070) Accessed null class context 'VehicleClass'
Error: ONSPowerNodeSpecial ONS-SyrmaMMXIV-v7.ONSPowerNodeSpecial6 (Function Onslaught.ONSPowerCore.RateCore:0098) Accessed null class context 'VehicleClass'
Error: ONSPowerNodeSpecial ONS-SyrmaMMXIV-v7.ONSPowerNodeSpecial6 (Function Onslaught.ONSPowerCore.RateCore:004E) Accessed null class context 'VehicleClass'
Error: ONSPowerNodeSpecial ONS-SyrmaMMXIV-v7.ONSPowerNodeSpecial6 (Function Onslaught.ONSPowerCore.RateCore:0070) Accessed null class context 'VehicleClass'
Error: ONSPowerNodeSpecial ONS-SyrmaMMXIV-v7.ONSPowerNodeSpecial6 (Function Onslaught.ONSPowerCore.RateCore:0098) Accessed null class context 'VehicleClass'
Error: ONSPowerNodeSpecial ONS-SyrmaMMXIV-v7.ONSPowerNodeSpecial3 (Function Onslaught.ONSPowerCore.RateCore:004E) Accessed null class context 'VehicleClass'
Error: ONSPowerNodeSpecial ONS-SyrmaMMXIV-v7.ONSPowerNodeSpecial3 (Function Onslaught.ONSPowerCore.RateCore:0070) Accessed null class context 'VehicleClass'
Error: ONSPowerNodeSpecial ONS-SyrmaMMXIV-v7.ONSPowerNodeSpecial3 (Function Onslaught.ONSPowerCore.RateCore:0098) Accessed null class context 'VehicleClass'
Error: ONSPowerNodeSpecial ONS-SyrmaMMXIV-v7.ONSPowerNodeSpecial2 (Function Onslaught.ONSPowerCore.RateCore:004E) Accessed null class context 'VehicleClass'
Error: ONSPowerNodeSpecial ONS-SyrmaMMXIV-v7.ONSPowerNodeSpecial2 (Function Onslaught.ONSPowerCore.RateCore:0070) Accessed null class context 'VehicleClass'
Error: ONSPowerNodeSpecial ONS-SyrmaMMXIV-v7.ONSPowerNodeSpecial2 (Function Onslaught.ONSPowerCore.RateCore:0098) Accessed null class context 'VehicleClass'

Error: ONSOnslaughtGame ONS-SyrmaMMXIV-v7.ONSOnslaughtGame (Function UnrealGame.TeamGame.ReduceDamage:0033) Accessed null class context 'DamageType'[/code]


I have therefore been able to solve the problem of ReduceDamage:0033
For info, it happened when a vehicle fell in the water(Physics Volume) when It's specified a bPainCausing=True while DamageType=None

But now, It would seem that there is an incompatibility between the UltimateOnsFactory and the ONSPowerNodeSpecial : I explain, when the Factory is in direct contact, is quite close to the node: there's no errors, now move it behind a wall (it's what i do) : errors appears.
I control all the array, I even erase everything and replace nodes and factorys, always the same problem, may be someone can tell me if i'm wrong or may be theses errors are not consequential ?.

Other point:Peg, if I find your first post a little subjective for me, the second, more at my fingertips, give me a desire to remodel the map , with the exception of one thing that my mind does not fit :
Moving the core on the ground floor, I cannot visualize what it will give, I mean even visually, I am well aware of the fact that the place could be conducive to camping (example the tank on the underground?:i'll remove it)
But there are four entrance most two grids,plus the possibility of skipping steps to hide behind the walls, not to mention the ability to attack with mantas,even Badgers and finaly we consider The air attack if the core had been elevated.

Second point of view: Strike Painter - In the light of greater of the fact that the tool itself seems to give the fun to the players as well as most of the nodes should have the sufficient protection against itself.
It is a little bit in this spirit that I had designed Syrma in my head which will give it a different soul (I hope) of the other cards, I mean if you consider the cheesy fun to throw it in the base, you may consider that the base-laming is forbidden BTW. In what other cases could-it be use in this manner : by the winning team ( ONS-Kingdom-BadWolf) on this point at least the heart will be protect .
We can make now the link between the first and the second point.
What I mean is that even if I went a bit randomly without knowing where I would(will) go, the elements ot the a map interlocks themselves to build a whole.
This said, I will take into consideration virtually any other points you mention.

User avatar
GLoups!
Posts: 371
Joined: Fri 3. Feb 2012, 17:57
Description: Just play for fun.
Location: Fr

Re: [Map] Ons-SyrmaMMXIV-

Postby GLoups! » Fri 11. Jul 2014, 19:23

After testing, the problem concerns only the nodes, not the cores.

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

Re: [Map] Ons-SyrmaMMXIV-

Postby Pegasus » Mon 14. Jul 2014, 00:21

Hey GLoups, how's it going? Started writing a response last night to your last post, but then, halfway in I had to look into the map's custom classes to answer the first part, so I DLed the standalone newer version of the map, forgot I needed the rest of the required files, went back to get 'em one after another, then got distracted by a phone call and some other stuff and, well, here we are :p... Anyway, I'm happy to hear the previous batch of suggestions helped inspire you to keep working on the map and, hopefully, the remodeling you mentioned won't be so radical as to invalidate most of the work you did before. However it goes down, I'll certainly be curious to see what you cook up.

Now then, regarding the first of the specific issues you raised, the null class error that keeps filling the logs seems to be the product of incompatibility between the UltimateOnsFactory and ONSPowerNodeSpecial classes indeed. While the latter is part of the OnslaughtSpecials package and has been used in multiple online hosted maps so far, I believe the case with Crusha's UltimateMappingTools is pretty much the opposite, which makes encounters where maps have tried to incorporate content from both at the same time a rarity.
Looking at the code of those two custom classes, as well as the typical behaviour of the standard classes they extend, it seems that normal powernodes/cores (as in, from the ONSPowerCore class) iterate across all the ONSVehicleFactory closest actors (definition of "closest" derived through a quick distance comparison between all nodes/cores) when trying to assess those objectives' value for bots through the RateCore function, but the combo of ONSPowerNodeSpecial class not expanding that functionality at all (say, by telling that part of the code to also look for child classes of ONSVehicleFactory) and UltimateONSFactory simply not being ONSVehicleFactory just throws the whole thing off. While the map does seem to play as expected, no quick patches that I attempted managed to alleviate the error spam (say, by forcing a VehicleClass value to each of those Ultimate vec factories or to their entire classes), so the remaining options would be to either alter the relevant part of ONSPowerNodeSpecial's code, with all the hassles involved with that (UEd can be pretty uncooperative with such actions, typically deciding to blank out all of the class's defprops, thereby forcing you to have to feed 'em back in manually :/), drop the UltimateVehicleFactories altogether ...or just decide to consciously ignore the issue, along with all the frustration it will likely cause to the serveradmin looking through those logs daily for any signs for serious problems. That last alternative isn't exactly the most considerate one either ;).
Lastly on this matter, you don't need to set up a localhost server in order to see what kinda output to the runtime log your edits produce; just click the "Play Map!" button in UEd, helpfully symbolized by a joystick icon, and while the launched game session is active, you'll be able to tab out and check the live log it produces in the other UT2004 window the playtest produced. Admittedly, its size can be somewhat restrictive, but you can still copy all the text from inside it to any text editing program, so it's still a helpful tool for that purpose. Just something to keep in mind.

Turning to the cores' placement now, while I do appreciate the fact that there are 5 different ways one can position themself to attack 'em (near the 4 sets of stairs, plus from directly above), what concerns me is the narrowness of those openings and the specific placement of the attacker those dictate, which makes the defenders' work much easier in covering 'em (say, just park a tank or bender nearby). Additionally, I strongly believe there's a correlation - if not an outright causal link - between maps where cores are considerably covered (through st.meshes or BSP) or tucked away behind numerous, sequential corridors and tight turns, and the likelihood that matches in those maps will end in overtime. You can see this bottleneck effect prolonging matches beyond regulation time most pronounced in maps like Surripere-ECE, VK'S-PLAYGROUND!-V3, even more in ONS-}TCP{WinterStorm-SE-Beta1, and, most popularly, with Panalesh where managing to come even within sight of the core becomes a marathon unto its own. A meandering design like that will inevitably favour the core's defenders, but since this only matters at that point in the game where they've been overpowered in every other location in the game, the result of the match is pretty much guaranteed, so all it manages to do is diminish the experience for players before moving on to the next map - and last impressions tend to count for quite a bit when we're talking about map popularity too.
Just like I said last time, my input here is only of an advisory nature; all I can do is offer some recommendations and the arguments that support 'em based on previous experience I've had with hundreds of other maps and what I've learned from that. In the end, though, this is your creation and you're the sole judge of what makes it in, what doesn't and how the post-beta/final version of Syrma will look. For my part, I believe I've covered the cores' placement issue extensively enough by now, so I think it's time I joined everyone else in waiting to find out what the bases' design will be in later versions.

Lastly, as far as the inclusion of more heavy-handed superweapons in maps is concerned, items such as the WGS Redeemer, the Enhanced Redeemer, the nuke Strike Painter, the Gravity Vortex gun, the EONS Nuke Mine Layer, the Transdimensional Disturber (don't ask...) and some other choice gems, I gotta confess that I never exactly harboured much appreciation for any of 'em. The common quality among them seems to be that - whether through extended duration, range or damage - they were built for their users' questionable entertainment at the imbalanced and inordinate expense of their victims. Most pronounced in the Strike Painter's case, recreating that same feat demonstrated in the YT video I linked to during late-game in an online match would undoubtedly not damage the core, but only serve to send the enemy players into a repeated cycle of dieing, respawning and dieing again in pretty sadistic fashion while the rest of their vehicles melt away. To me at least that seems beyond any scope of reason, so I can't help wonder what the point of including the strike painter in the map, instead of, say, a simple nuke, is. You're right that it's become a staple in (RTS)-Kingdom_SE-BadWolf-V1a too (I think it was in some version of Panalesh, along with the WGS Nuke, as well), but IMO that reality should only help emphasize the disproportional misery that weap tends to bring about when [ab]used instead of being an argument in favour of spreading the problem around some more :/.
All in all, the needless hyperbole that characterizes all those uberweapons is the exact attribute that, I think, should render their use prohibitive to the mind of any mapper seeking to create a well-balanced, interesting and innovative ONS experience. I seriously doubt that those guns have ever helped improve any of those qualities in maps. After all, the same line of thinking "earned" Michael Bay the reputation he has, and it's not exactly a very flattering one ;).

Okay, that's all I got for now, hope some of it was helpful to ya. As ever, enjoy yourself mapping, GLoups, don't hesitate to ask for any help you might need, and I'll be looking forward to your next Syrma edit, whenever it comes out.
Image

User avatar
GLoups!
Posts: 371
Joined: Fri 3. Feb 2012, 17:57
Description: Just play for fun.
Location: Fr

Re: [Map] Ons-SyrmaMMXIV-

Postby GLoups! » Mon 28. Jul 2014, 19:52

Then the syrma project matures, I think that the biggest foundations have been laid, finally I realize that peg (once again :) ) was right on almost all points (at least for really on the Eons-scorpion that I dislike a bit), so i make a list of changes dones on the map it will be more meaningful.

Arrangements of Bases :

- As I have not resign myself to mount the core on the ground floor or leave it in the basement, I finaly find the nuanced following solution to put it in the middle of the two floors, In addition the idea of opening a third door has appeared itself a good thing.The physic volume is delete.
- Arrangements of Nodes : New primary nodes (5 and 9) Draw inspiration from the old, but with news solutions from Pegasus, others primary (1 and 10) no changes apart the adjustment of force fields to the minimum, the manta can easily exit through the cone with a jump and it's much easier to go from the top.
- New nodes (3 and 7) replacing small ruins and were slightly move up near the water, these nodes seem to bring them a part of the action that was so far focus on the old house and stone house nodes
-Old house node scaling 1.5* axes x-y, stone house no changes.

Super weapons:

- Deleting Strike-painters and Nuke-layers, add 2 Ons-painter and invisibility pickup via ExtWildCardBase (sill 2 painters and 1 redeemer), replace Relics of speed with the autonomous one, and add two ZoomSuperschockRiffle (I don't know..).

Vehicles:

- Deleting KingHellHound and the Falcon is replace with a Phoenix, at this level i keep all HellHounds but i replace alt-fire beems (RearGunPawn) by the HellBender one which is less powerfull and the Driver weapon by the KingHellHound side gun(Shocks).
- I keep the Euscorpius because this is what I wanted: A faster and handy scorpion with scorpion's weapons before I realized that it's already exist (scorpius) the name is a coincidence :shock: but this one is in fact a tarentula disguised (what a noob! :p ), so i keep two willing at the heart of the action, where they might be useful .
- The perses (new version) is spawning at the bases outside of the walls via UltimateOnsFactory (work without errors at the cores), which allows to spawn it 4 minutes after the beginning of the match ( with the possibility to produce only one).

Aesthetic Aspect :

- New sun .
- Fix SkyBox which allow to not see the underside of the map .
-No crap planet :smartass:
- Smoothing terrain

There's certainly few other things I've forgotten but the main one is here.

Edit: Oh i remember now :nuts: : new networks of Jumppads!

User avatar
GLoups!
Posts: 371
Joined: Fri 3. Feb 2012, 17:57
Description: Just play for fun.
Location: Fr

Re: [Map] Ons-SyrmaMMXIV-

Postby GLoups! » Sat 2. Aug 2014, 13:15

Finally after a few time of tests, it is apparent that the gameplay in the central area of the map lacks a bit of fluidity, so I change the link setup a little and add a decade of jumppads to make the loops between the nodes of this part ,think it's play better now.
I also add a Eons-scorpion for seeing how it play.
Last edited by GLoups! on Thu 7. Aug 2014, 11:07, edited 1 time in total.

Ten
Posts: 70
Joined: Mon 16. Jan 2012, 17:47
Description: I love VW mk1 golfs

Re: [Map] Ons-SyrmaMMXIV-

Postby Ten » Sun 3. Aug 2014, 09:18

Omg! some serious comments going on here!
Nice map mate! Congratz I've yet to download and try the later versions although what I did play seemed clean smooth going. Loved those lasers at one of the nodes, however seemed a little bare at certain places, I guess the updates versions have improved. I'll get back at ya.. Big up yourself! & Keep up the good work Gloups. :)

Btw, don't spend to much time creating, seeing more of u in-game is better ; - D

User avatar
GLoups!
Posts: 371
Joined: Fri 3. Feb 2012, 17:57
Description: Just play for fun.
Location: Fr

Re: [Map] Ons-SyrmaMMXIV-

Postby GLoups! » Thu 7. Aug 2014, 11:04

Thanks ten !
Well this one fix the second round bug of crashing server (i replace all the emitters).
Last edited by GLoups! on Tue 12. Aug 2014, 10:12, edited 1 time in total.


Return to “The Creative Corner”



Who is online

Users browsing this forum: No registered users and 3 guests