
...so:
Worm asked for suggestions on what could be improved in ONS, and I thought to just throw here my usual two cents.
I know that you, casual reader and ONS player, know what I'm talking about. Some days ago, for example, I spawned at core in the middle of a Grit fight, just to find that EVERY vehicle was seriously damaged (most of all, obviously, the 1000+ hp Mino).
It's frustrating to spawn at a place just to find out that you have to choose between staying here to heal the vecs (and losing time to have actual fun with them) or going out in a fragile deathtrap.
So I thought: if we all agree that the practice of damaging locked vehicles far from the fight is lame, is there a way to hard-code something to prevent it?
I do realize that shooting down locked vehicles is acceptable when they are resources that the enemy team could deploy to immediatly threaten your team (like: shooting the Goliaths at the center of the map on TripleSlap/BitchSlap/Tyrant), as I previously talked about it somewhere here on the board to Peg, so I'm going to suppose that we, or at least me and the staff, are on the same page about this.
Keeping in count the fact that there are cases when it might be okay to shoot at locked vehicles, I thought of some possible solutions. Some are flawed, but I thought to just post all of them: maybe someone could find a way to perfect them.
1) shielded node, means shielded vehicles. Period. So: the vehicles already locked at a shielded node/core, are immune to damage until someone jumps on them.
That was the first thought that I had, but the problem here is that a shielded node DOESN'T mean that his vehicles are not a direct threat to the enemy team (I'm thinking, for example, of the Goliaths at the center of Tyrant: even if their node is shielded, they are still an immediate threat to any of the three center nodes).
2) shielded node, means that his locked vehicles have a big heal factor. If the regeneration is coded to trigger, let's say, three seconds after the vehicle took any damage, people could still destroy threatening vehicles with no problem, which is okay.
And, of course, people could still lame at core and damage vehicles and so on, but their efforts would be totally wasted after they leave.
Of course, the heal factor would exist ONLY with LOCKED vehicles. As soon as someone jumps on it, the vehicle stops regenerating.
3) shielded node, means that the lamer dies. I'm thinking of something like the damage that you take in SpankJox when you jump high in the sky with the central jump pad: if you stay in the area of a shielded node or core for more than some seconds, you start taking damage until you leave or you die. The damage might be designed to stop if enemy players are present at the node, and so the player won't be too disadvataged if there is an actual fair fight at the node/core (which sometimes might happen when you just escaped with a vehicle or jumped off a flyer, or if the node just got shielded while you were shooting at it. For example it often happens to me on SpankJox or on Nevermore).
Good thing is: with this one, we could also get rid of the core lamers/campers.
Bad thing is: and what about the ones that shoot at locked vehicles from a long distance?
Bigger bad thing is: it would not be easy to implement it, because the "area" of a node depends from map to map (for example, it's very small on Bridge, and it's very big on Grit) and so it could need to be coded and personalized for each map, that is a lot of work.
That's it.
Now: even if I have some experience of tabletop game design and pc coding, I don't know anything about UT coding. Also, I could have missed something in my three possible solution and they might be messed up.
However, I think that the "best possible solution" (in an ideal world) would be to implement both 2) and 3), to get rid of both the vehicle shooters (at close or long range) and the lamers/campers on cores.
But, thinking of what could be easier and faster to code, I think that implement only 2) might be good enough.
What do you think?

I'm looking mainly for the feedbacks from our coder fellas and the staff of the server (because, obviously, they are the ones eventually in charge to implement it and to give it the seal of approval to embed it on our server) but of course any feedback is appreciated

Cya soon!
