[Map] Ons-Syrma-

[GLoups!]

I know why, i had a strange problem with the boths EWCB (those with snipers), the snipers don't disappear when they was taken, i fix this by put bDelayedspawn to true > rebuild all, then it was the center EWCB (with the super shock): same problem i just delete the mines on it because they not really needed,put bDelayedspawn to true and just rebuild geometry,bsp and lightning but not the paths.
The other changes are somes deformations in the terrain, add a location volume for the caves, change the lightmap resolution of fews surfaces :distant primarys,and stone house-not on the bases- and put bShadowcast to true in Terraininfo , bActorshadows to true in the lights properties and change the skins of theses misplaced staticmeches, hope it don't make a big deal, so i've just rebuild all and reupload the map.

[Pegasus]

Okay, we may have reached a point where we're taking steps back instead of making the last one forward to lock down a release version, so here's a few clarifications to hopefully help push towards that.

- If you check the code of the EWCB class embedded in your map (easily done by right-clicking on any such placed actor and selecting Edit Script), you'll see at the top, commented out header that you're using v1.2 which already supports noStay for all weapons automatically. None of the other settings you changed around (like enabling bSequential which just turns off the randomness in the pickups' pool and makes the rotation more boring predictable, or disabling and re-enabling bDelayedSpawn, as enabled is that param's default state already) have anything to do with weapon pickups remaining after grabbing 'em, which was an issue with v1.0 (as seen on 2ndRaceway-DW-SP1) and that's one of the reasons the updated version was made. Moreover, rebuilding any of the map's pre-baked aspects (lights, paths, geometry, etc.) has nothing to do with the EWCBs' standard operation. For the record, I tried out the latest version both offline and on my localhost server after setting both aforementioned params to their default values for all bases and everything seemed to work as it should: SSRs and CSRs would properly disappear after getting grabbed, and pickups rotated as expected. I dunno what caused this overreaction since, I believe, your EWCBs were already behaving as they should, but at any rate, trust me, there's noting wrong there.
- The lift-proximal beam st.meshes running parallel to the distant primaries' cicadas, as well as the connecting ones to the vec's base were collisionless to vehicles (again? not sure), and fixing that required finding the 2 resources in the st.mesh browser (myLevel.Base: grate3 and grate5), re-enabling the UseSimpleBoxCollision and UseSimpleLineCollision params for each, as well as giving both a new 6-DOP (box) collision.
- Aforementioned lifts apparently do take out 10hp per encroaching event (say, if you're standing right at the edge of the lift when it goes up and you hit the ceiling) just like you've set them to, but here's the weird part: that only happens in client/server remote play. In standalone mode the lift outright crushes you to death in one hit :s. At any rate, it doesn't affect the online experience at all so no need to worry about it; just thought I'd mention it for the record.
- Ran across a weird visual bug involving Wormbo's new badger headlight projector's angle and range, which seems to produce a light artifact at 90° angles both left and right of the vec's facing direction; becomes quite noticeable inside the bases' coliseums. It's not really relevant to anything here, but if I don't put it down, I'll probably forget it, so there . Edit: now including a picture here!

Anyway, since I had to apply the aforementioned tweaks in order to test 'em out on the localhost server, and it all worked out fine, I figured I might as well do the path rebuilding UEd was whining about, resave the whole thing and upload it here (only the map is included in the archive, none of the file dependencies) in the interest of saving you time later and for your reviewing convenience. Hope this doesn't come across as me overstepping my bounds here and that you're alright with it (if not, don't hesitate to say so though). If this helps, please let us know about whatever other changes, if any, we should be waiting for in order to schedule the roster update - like, say, adding back some extra items to those EWCBs or whatever else. Considering the map's reached a release version point, however, we'd appreciate it if you tried to keep focus on just fixing existing bugs instead of introducing more elements. Oh, and thanks again for the hard work, GLoups!

[Wormbo]

- Ran across a weird visual bug involving Wormbo's new badger headlight projector's angle and range, which seems to produce a light artifact at 90° angles both left and right of the vec's facing direction; becomes quite noticeable inside the bases' coliseums. It's not really relevant to anything here, but if I don't put it down, I'll probably forget it, so there . Edit: now including a picture here!

Hmm, maybe the projector texture doesn't have proper clipping.
/me goes and checks for next release

[edit]
Nope, it's set to clamped and doesn't happen on other maps. Not sure what might be going on there.

[GLoups!]

If the fix version is allright for you then anyway I'm sure to not having to add anything else.

as well as the connecting ones to the vec's base were collisionless to vehicles (again? not sure), and fixing that required finding the 2 resources in the st.mesh browser (myLevel.Base: grate3 and grate5), re-enabling the UseSimpleBoxCollision and UseSimpleLineCollision params for each, as well as giving both a new 6-DOP (box) collision.

You've already told me but by a combination of circumstances that day, I go next door, a parallel emitter precisely at this place that appears mysteriously made me think It was the problem (seems already fix, cause i think that the cicada spawning was interfering with the node just below), so thanks to have fix it.
I could not prevent me to tinker once more (last) time since i'm always considering me in learning mode (but less now thanks to you again!). I won't touch anything, I promise.

[Pegasus]

Hmm, maybe the projector texture doesn't have proper clipping.
/me goes and checks for next release

[edit]
Nope, it's set to clamped and doesn't happen on other maps. Not sure what might be going on there.

Ugh, after doing some more testing earlier today, I'm afraid I'm gonna have to declare my previous bug report a "false alarm", at least insofar as your Badger is specifically involved. It seems that there's an issue with that particular st.mesh and that a similar visual effect manifests whenever any kind of headlights-sporting vehicle is facing it within that projector's distance. Should've done a bit more diligence before drawing a verdict and associating specific custom content's creators to it, and for that I'm sorry, but (in my measly defense) there were only 2 wheeled vehicles available in that area, and the other one both spawns far away as well as is rarely involved in my testing for there to've been any good chance of noticing the common aberration beforehand.
As far as the glitch itself goes, GLoups had also changed a couple of lighting/visual related params from their default states with those st.meshes (bActorShadows and bDynamicLight on one semi-ellipsoid, and bActorShadows n' bLightingVisibility on its complementary), but even when switching 'em all off and rebuilding lights (bLightChanged flag gets raised if the editor so much as sneezes, I fokn swear...), again the glitch persisted. The 3 materials this st.mesh uses are all stock textures, so that leaves the model itself as the only remaining suspect, and that's where this thing crosses into modelling territory and beyond the realm of my knowledge; I've done some very minor model editing once in the past (I believe in zModeler? or zM2 or was it Blender? don't even remember :/), but I know very little about how texture wrapping works and this seems like such an issue (smaller reso specular layer?) so that's as far as I can go investigating this. Hope this helps whomever might care to pursue this further.

If the fix version is allright for you then anyway I'm sure to not having to add anything else.

[...]
I could not prevent me to tinker once more (last) time since i'm always considering me in learning mode (but less now thanks to you again!). I won't touch anything, I promise.

Alright, so just to make sure I'm understanding you correctly here, does that mean you're okay with the version fix I posted yesterday being the one we host on the server? Also, you're quite welcome; helping creative people improve their craft and put out even better work by pointing them to the right tools n' info is all the satisfaction I need to keep doing it .

[Wormbo]

Maybe some nitpicking here:

Node name; distance fog vs. terrain

Shot00052.jpg (446.21 KiB) Viewed 10656 times

There seems to be a typo in the node name. Also to me the node location doesn't seem to be very "west".

The other thing is the interaction between distance fog and terrain. The distance fog color doesn't match the dominant sky zone color, so terrain segments pop in and out when you move around. It may be worth adding a "fog ring" to the sky zone to get a uniformly colored background for where the terrain segments will usually appear.

A third thing that isn't possible to show with screenshots is the ambient audio. I seem to be hearing something that sounds like distant thunder, which seems to contradict the "nice sunny day" weather in the map. (But maybe that's just a perception thing.)

[GLoups!]

The other thing is the interaction between distance fog and terrain. The distance fog color doesn't match the dominant sky zone color, so terrain segments pop in and out when you move around. It may be worth adding a "fog ring" to the sky zone to get a uniformly colored background for where the terrain segments will usually appear.

Product of hazard yet, that is exactly the question I ask myself yesterday while having a look at an another map but in the opposite direction: this map is Ons-Byonix and I thought to seek advice from ceonss community about it in a more or less distant future (and its author) since it's a beautiful map, and need very little editing (may be just weapons and vehicles improvements), but the only visual questioning is this one precisely:

Byonix skyring.jpg (142.88 KiB) Viewed 10640 times

what I understand from this idea is to put a static meshes of the same color as the fog in the skybox just at the height of the mountains with accessorily an alpha channel transparency, but the problem is that as we see on the picture the difference trench between the sky and the fog color/fog color skyring even will be more pronounced on Syrma where the sky is very clear and the fog most darker (i already trying to change color fog and it's crappy), so let it as well even if it isn't perfect imo is the best solution.
The thunder on the map every 240sec : ah well, do not forget that we are on a distant planet and the weather conditions may be different of everything we know here, does it is good excuse ?
Of course i change the two nodes name and volume location names , for those who would asking it's stars names .
I just take the fix version from Peg and change names of the two similary nodes, rebuild all and reupload just the map file- nothing else has been changed.

Download Syrma/map

[Cat1981England]

There's "cloudring01" in the far.usx which may work better gl.

[Wormbo]

what I understand from this idea is to put a static meshes of the same color as the fog in the skybox just at the height of the mountains with accessorily an alpha channel transparency, but the problem is that as we see on the picture the difference trench between the sky and the fog color/fog color skyring even will be more pronounced on Syrma where the sky is very clear and the fog most darker (i already trying to change color fog and it's crappy), so let it as well even if it isn't perfect imo is the best solution.

The idea is not to cover up the fog with a skyring, but to place a skyring (for better transition between sky and fog) and then adapt the fog color to it. If the fog is this high (e.g. due to high surrounding terrain), it may be a good idea to make the transition area between ground/fog and sky larger and to adapt the fog to the sky colors. The fog on that Byonix screenshot clearly is too dark for how the sky looks.

[Pegasus]

With all the resurgent talk about refining visual details, I'm concerned we may be losing perspective here and veering off target. I mean, yeah, obviously getting into the finer nuances of fog n' skybox/skydome fidelity and improving an outdoors map's overall presentation are useful mapping aspects for anyone to gain some hands-on experience with, and, hell knows, I can probably come up with half a dozen additional items of a similar kind that could still be improved on the map too (already thought of 3), but by now, I think we've worked our way down the list of issues meaningful and important enough to address for this phase in the map's development that further delaying a live test, with all the different kind of gameplay-relevant feedback that would start bringing in, just to keep on polishing the silverware no longer seems to be the best course of action. Not to mention authors don't lose the ability to continue working on their maps after a first release version goes live either, but I think it's more important to aim for hitting that milestone first and, once that's done, go back to worrying about making the terrain pop in/out of view in the distance less or the skybox/fog colour gradations look more natural, or anything else of that matter. Gameplay over aesthetics and so on.

As to the Bionyx tangent GLoups brought up, while this is probably the wrong place (and definitely the wrong time) to get into it, I'd say it's a map that's definitely come to our attention (years) before, and I've already given it a decent look myself in the past too. While it wouldn't take much work to address its somewhat deficient resources (vecs, weaps & ammo), to come up with a better, non-chokepointed node link setup, and maybe place its stub primaries in a slightly more covered position (say, behind the convoy vehicle, which could also be rotated around), overall I wouldn't say that Bionyx offers anything unique in terms of gameplay that would make it stand out against its competition - Alien2, Ascendancy, WhiteSands, to name just a few. Also, while it does feature a few quirky, custom scripted elements spread around (some karmathings here, some Nali cows there, all stock vecs needlessly subclassed for no practical reason just so that ONSPlus radar dots can all be black :@), as a whole there's no cohesive plan that ties it all together and contributes to making gameplay more original. Even its low-g central area could've been more interesting, say, if it allowed peds to get on top of some of those rocks slowly floating about and maybe even have something useful there for them (although I realize that would also require movable weaponbases/pickupbases, which is IMO something we've been direly lacking and I've tried to do myself in the past unsuccessfully), but as things stand, applying a fresh coat of paint to it would still leave it a pretty ordinary, middle-of-the-road kind of affair that would still lose in gameplay comparison to maps we already have on the roster. I dunno, it looks nice, but that's really the best I can say about it :/.


Anyway, to get back to our main objective here, GLoups, would you say the version you uploaded today is now good enough to take for a live test? At some point we gotta take that next step, and the map doesn't even have to be perfect for that, simply good enough so the player feedback we get will be more about the important, gameplay aspects of it instead of smaller problems. Let us know if you think it's time.