Hey everyone, how's it going? Been a bit busy lately, haven't done much gaming or posting; hopefully this will improve by the end of the month. Msg board's been quiet lately too, but I think there's still several important topics we could be talking about here regarding UT, ONS, the server's policies and whatnot besides just the usual maps business. Among the various subjects I've been going over in my head these days, this seems the more practical one to pick for now, so I thought I'd start with it: improving ONSPlus.

As you might know, TechCom and several other popular ONS servers have been using ONSPlus for years because of all its gameplay enhancements; selectable vehicle exits, vec indicators on maps for convenient spawning, extra points for several actions (linking, vec damaging, node isolating, pally shielding) among others, as well as various bug fixes like stuck missile warnings and charging vec's turrets. ONSPlus was first created by Titans' community member Shambler almost 6 years ago, but the mutator stopped being updated/improved upon around mid-07. A few days ago, lilalurl reminded me ingame that Shambler isn't opposed to other ppl working on this code (provided that standard courtesies such as requesting permission are first extended of course), so with that in mind, I thought I'd throw around some ideas I've had for a while on improving certain ONS aspects so others can pick 'em apart or add theirs. Aspiring coders might even decide to work on ONSPlus now to help the remaining UT communities enjoy this gametype even more! Here goes:


- Vehicle class radar dots: most vecs in maps these days aren't stock and only show up as black dots. It might help if the dots' colours were tweaked to represent the main classes instead of their retail instances, for example mark all onsattackcrafts as yellow, ONShovertanks white, ONSPRVs as cyan, etc.

- Vec client/server position unsync @seat switching: UT's netcode tells servers to update vec positions only when they're driven or taking damage and the exact resting place of the vec after handbraking or switching seats while it's still going can differ between client and server. This causes the usual phenomenon of misaligned turret shots for benders and badgers. An easy fix would be to tell the server to inflict 0.5hp of damage to any vec upon a seat switch which would force a position update. To address sliding paladins and such (also caused by position unsync), vecs chould, alternatively, receive 0.5hp damage when players enter/exit 'em. This could cause more BW consumption, however.

- A headshot counter for personal player (F3) stats: self-explanatory I think. At match end we can see how close we got to flak monkey, why not afford the same luxury for our HS count?

- "Switch to Player's Stats" option for Game tab( like "Spectate Player"): ONSPlus lets you jump to any player you wanna observe with the "Spectate Player" right-click menu command, but if you want to check their stats you need to go through 'em all one by one with F8 to get to the right one. Why not automate this?

- More specific missile lock messages ("AVRiL Lock!"): This was already suggested in the latter titans' ONSPlus thread, but I think it bears repeating. Idea behind this is, manta/flyer pilots react one way when they know they're being hunted by raptors and another when peds fire avrils at 'em (practical difference between the two can translate to life or death), both in terms of how they'll dodge as well as where they'll start searching for their attacker. This bit of extra help could go a long way in many cases.

- A kickvote <PlayerID> console command: Kickvoting practically never works cause nobody bothers to vote even if a proven lamer is identified by a reliable source. It can take a while to reach the kickvote window, sort through the long list, kick, then return to action and by that time, you're likely to be dead. Others who care enough to kickvote but are engaged in battle at the time (or driving an important resource) might choose to vote after they're killed, but this delay can be long; if most votes start arriving late, the lamer is likely to go scot free. My proposal here is, when a kv first occurs, a modified server message could appear stating "X voted to kick Y [Y's_PlayerID]". After X informs everyone "Y is doing so and so, plz kv him", players would only need to take 3secs to type "kv [Y's_PlayerID]" and be done with it, if they want to kick Y. There might be other ways to streamline this, but any approach would be better than what we have now. Btw, keep in mind this is a discussion on how to improve kv usage, not how it can be abused.

- Nodes and cores health bars on ingame map (Map tab too): self-explanatory. You saw it on Kamek's TreetopVillage; it looks nice, it's certainly helpful, it's not resource-heavy. Why not make it part of general ONS?

- Vehicle flipping safety: This one's a pain since the game got out. You approach a scorp to flip it, and immediately get crushed upon pressing E. Next time, save your time (and dignity) and just hoof it instead! Other flipping travails include vecs atop narrow ledges where you try to get one upright again, but it only lands on 2 wheels, then strangely starts moving sideways and goes off ...wtf? Let's restore some sanity to this code and perhaps force vecs to levitate a bit before they're flipped upright and touch the ground again so as to avoid this ridiculousness.

- Target Painters don't lock on ground above a certain height: I noticed this at Valarna where you can't seem to get the bomber to strike terrain that's as high as the cores' region; this bug is especially enfuriating in the IceEdit version of Valarna where there's a Nuke Strike Painter and krakens camp close to the bases. A fix for this could be as simple as telling the bomber to fly a bit higher, but then again it could be trickier, so I dunno, haven't checked the weap's code yet.

- Vehicle geometry unstuck code: Last, but certainly not least, this. You've all experienced this. While it can happen offline too, the amount of times it occurs during online play vastly outnumbers those and makes me think it's a glitch caused by lag rather than shoddy mapping skills when it comes to st.mesh collision volume setting. Even though lag's a fact of life for online gaming and we've come to regard ping-compensating aiming as an admirable skill, nobody has ever claimed that trying to get your flyer unstuck from inside a girder has any upshot like making you a better player, so I gotta wonder: how come nobody's ever taken a stab at this :s?
Two basic issues with approaching the problem: 1) how do you diagnose a "stuck" condition in UScript terms? Is it enough to label a vec stuck if, say, it's touching a surface for X secs, the driver's accelerating the whole time and it continues to touch that surface despite it? Then perhaps use Shambler's vehicle exit code to tell the server "move stuck vec 50UUs in the optimal direction"? Would you trust players to report when they're truly stuck (much like when the teams stop being balanceed) and do a "mutate unstuck" to get themselves out instead? 2) How do you code an unsticking method that players won't try to abuse in other situations? I'd really like the chance to pick a few good coders' brains about this one :/.

- Fix for cross-round spec camera bug: Sometimes when a new round begins your camera freezes somewhere in the map and even if you force spec someone you still can do so only in 3rd person (ifyou switch to 1st person the rotation is locked). Only fix is rejoin the server, but you might lose your spot trying. Shambler mentioned this was on his to-do list years ago, repeating it here for emphasis' sake.

- Fix for flyer vecs exit blocking when touching volumes above: Also mentioned at the titans', simple restatement here. Happens a lot at the falcon nodes on MagicIsle, very annoying.


That's all, your turn! Remember to make suggestions for ONS in general, not about map-specific bugs!

If ONSPlus is free to be edited, I wonder why Shambler removed the plain source code from the compiled packages. You can give it a try: use the Edit Script function in UnrealEd on his classes and you will receive nothing but empty code windows. Just by chance I once found a procedure to decompile them, but the formatting got lost during the process and it's horrible to read.


Radar dots: I never really took a look at how he implemented anything in ONSPlus, but I remember to have seen special classes of the individual vehicles, for instance ONSPlusHoverCraftFactory that extends ONSHoverCraftFactory and it might be that those factories are used for the radar dots (as they only need to be found once at map start and can then be written down into a list instead of having to let the server iterate through all dynamic Actors whenever a player opens the radar screen).

Vec updates: as far as I remember, the engine doesn't call an event when the player changes seats and so it's nearly impossible to find a solution for that problem with a reasonable performance.

Headshot and stat shortcut: Probably possible. I have no experience with the UI system (which would need to be altered) so I can't foretell if there would be some problems here.

AVRiL message: Never had any problem with it, the sound and so on is enough for me to know when an AVRiL is incoming.

A kickvote with "press F1 for 'yes' and F2 for 'no'" would be probably good…

I like Wormbo's health bars above the Nodes, but I find it horrible on the radar map. It feels too cramped to me.

Vehicle flipping: Seriously, how often does that happen to you? Once in a month? After playing for such a long time we all know probably that we should take a step backwards after starting to flip a vehicle. Making it hover and so on doesn't seem worth the effort to me, tbh.

Target painter: if the bomber doesn't appear, then only for the reason that it couldn't fly in even higher. It already attempted everything but the next higher position would be outside the subtracted space and thus is not an option. It's not a problem of the weapon, it's a problem of the map's ceiling being too low.



Just my two cents.

crusha_k_rool wrote:
If ONSPlus is free to be edited, I wonder why Shambler removed the plain source code from the compiled packages. You can give it a try: use the Edit Script function in UnrealEd on his classes and you will receive nothing but empty code windows. Just by chance I once found a procedure to decompile them, but the formatting got lost during the process and it's horrible to read.

But you can get the .uc files directly from the downloadable package, can't you?:
[url=http://homepage.eircom.net/%7EJBarrett847/ONSPlus-v1.1beta31.zip]http://homepage.eircom.net/%7EJBarrett847/ONSPlus-v1.1beta31.zip -> can't seem to manage to fix this link to display correctly but it works fine when clicked.


To be precise on the matter IIRC (90% sure) Shambler told me, when I asked for some features via PM:
http://ut2004.titaninternet.co.uk/forums/showthread.php?p=208406#post208406

that he would be opened to some people adding some things to ONSplus, supposing of course he is asked first etc...

crusha_k_rool wrote:
[...]I wonder why Shambler removed the plain source code from the compiled packages.[...]nothing but empty code windows.[...]Yeah, I must admit this did puzzle me too when I tried batchexporteding it with ucc; nothing but defaultvalues in the script files :s. Thankfully, lila's links solve that problem, but it still strikes me as odd that the only way you can examine the code is by getting it from the coder's zip archive. Btw, is there a specific obfuscation switch you can feed to ucc when compiling that will cause the .u file to not be decompileable?

crusha_k_rool wrote:
[...]Just by chance I once found a procedure to decompile them, but the formatting got lost during the process and it's horrible to read.[...]I'm curious, does that involve 3rd party programs?

crusha_k_rool wrote:
[...]AVRiL message: Never had any problem with it, the sound and so on is enough for me to know when an AVRiL is incoming.[...]Actually this lets you know when a missile is incoming, not what kind it is. Makes quite a difference if you're in a cicada passenger seat. Or if you're in a manta attacking an enemy node (an AA missile means, at worst, you can take the damage but still have more time to focus on the node some more; an AVRiL you'll have to take immediate action against). Also, as I already mentioned, a more specific msg could tell you where to start looking for your attacker, ground or air (can help with dogfights-heavy open maps).

crusha_k_rool wrote:
[...]A kickvote with "press F1 for 'yes' and F2 for 'no'" would be probably good[...]That might work too, but since most ppl have their F1,F2 already bound (in fact, you can't really know what keys ppl have or haven't bound at all), is it possible to toggle their function only in such a case, then restore it? This might be a problem, which is why I proposed a different command that ppl could bind on their own, much like how it happens with the various special mutator commands.

crusha_k_rool wrote:
[...]I like Wormbo's health bars above the Nodes, but I find it horrible on the radar map. It feels too cramped to me.[...]Huh? I'm baffled as to how this would "feel" too cluttered for you:

How can you make the case that it's not helpful either?

crusha_k_rool wrote:
[...]Vehicle flipping: Seriously, how often does that happen to you? Once in a month? After playing for such a long time we all know probably that we should take a step backwards after starting to flip a vehicle. Making it hover and so on doesn't seem worth the effort to me, tbh.[...]So your reasoning here is, we've learned to live with this bug for years so there's no point fixing it now, even if we have the ability to do so? As for how often it happens, I can attest to seeing ppl get crushed by flipped scorpions at Techcom even as recently as 4 days ago. Admittedly, it's usually not the most experienced ppl this tends to happen to, but is that even a criterion we should be considering? Bad game experience is bad game experience no matter who's having it; game is worse for it in any case. Also, although not as prominent in ONS, speaking as someone who started dabbling with other gametypes and servers recently (RACE gametype at LDG server, to be exact), you won't believe how frequently this problem occurs and ruins gameplay. Not saying we should start taking up projects to solve other people's problems here, however noble that might be (and even though the scope of ONSPlus does cover other gametypes), just pointing out that this issue is still alive and present as ever; don't kid yourself. Frequency shouldn't be a valid counterargument here.

crusha_k_rool wrote:
Target painter: if the bomber doesn't appear, then only for the reason that it couldn't fly in even higher. It already attempted everything but the next higher position would be outside the subtracted space and thus is not an option. It's not a problem of the weapon, it's a problem of the map's ceiling being too low.[...]Well, what that tells me is, to fix this either all problematic maps (and all their different versions) should be edited to have their ceilings raised or the weap itself could be tweaked to make the bomber's altitude gradations denser. I'm proposing the latter since it could solve such problems, past, present and, possibly, future in one fell swoop.

pegasus_ wrote:
crusha_k_rool wrote:
[...]I wonder why Shambler removed the plain source code from the compiled packages.[...]nothing but empty code windows.[...]Yeah, I must admit this did puzzle me too when I tried batchexporteding it with ucc; nothing but defaultvalues in the script files :s. Thankfully, lila's links solve that problem, but it still strikes me as odd that the only way you can examine the code is by getting it from the coder's zip archive. Btw, is there a specific obfuscation switch you can feed to ucc when compiling that will cause the .u file to not be decompileable?

I don't know of any switch, but you can open the .u file afterwords with a text editor. The top of the file is filled with a lot of cryptic symbols (aka the compiled code) and the bottom is the plain text source code. Deleting the bottom part out keeps the file usable but unreadable.

pegasus_ wrote:
crusha_k_rool wrote:
[...]Just by chance I once found a procedure to decompile them, but the formatting got lost during the process and it's horrible to read.[...]I'm curious, does that involve 3rd party programs?

I found that the above method could still be bypassed by using the Unreal Package Tool, which is supposed to export any kind of resource from any kind of Unreal package. (I found that it fails at many places but surprisingly it could extract the code of these .u files where normal methods fail)

Anyway, even the UPT fails at decompiling the Anti-TCC files (and that's good that way!), probably because Wormbo is a hell of a programmer who can write other programs (maybe he wrote his own compiler) that help in such situations and which can for instance really, really protect stuff from decompilation.
But I don't even want to know how he did it, it's better that way.

The reason Anti TCC can't be decompiled with UTPT isn't the compiler I used (it's the same everyone else uses), but a bug in UTPT I exploited consequently.

Vehicle class radar dots: good
Vec client/server position unsync @seat switching: good
A headshot counter for personal player (F3) stats: why not, can live without it in ONS
Switch to Player's Stats: why not, can live without it
More specific missile lock messages: too artificial?
A kickvote <PlayerID> console command: many, many ppl share the ID, noobs don't know the console
Nodes and cores health bars on ingame map: why not
Vehicle flipping safety: good
Target Painters don't lock on ground: good, the Painter's range is now equal to office laser pointer
Vehicle geometry unstuck code: good
Fix for cross-round spec camera bug: good
Fix for flyer vecs exit blocking: good

Also the disappering tank's turret would be nice to fix. And the no-weapons bug.

Foibo, I believe the missing vehicle turrets (all pawns on them actually, as well as the weapons in peds' hands) during the first few seconds you see them isn't actually a bug, but has to do with the way UT netcode prioritizes the bulk of all info it must transmit to you. When you first "arrive" at a scene, the server has to send a lot of info your way so you can appreciate the situation (in case you've already spawned and need to survive), such as the players around you (position, rotation, velocity, team colour, skin if they're on foot) and all the projectiles that are flying around as well. All that is enough for the first few seconds until the next "wave" of packets comes around and then you get proper node list info (the first few seconds, nodes' colours can be all kinds of messed up), but also vehicle pawns' states (where turrets are aiming, their charging state if an animation/sound has to be applied) and player's guns also start to appear. It makes sense, then, that if a server is crowded making BW needs greater and some net traffic problems happen to occur at the same time that tank turrets might stay invisible for a few more seconds or weapons grabbed from a locker might take a bit longer to be added to a spawned player's inventory. Either way, if you aim right and click, you can be sure your vec projectile will be fired and its effects will be calculated and shown to you next.

No weapon bug, as well as the dead-player-becoming-spectator bug are probably a result of crappy net traffic corrupting a UDP packet somewhere and causing the server to receive and interpret it wrong (you sent a "respawn" packet, server read an incomplete "spectate" packet). That's just my theory on it though, I'd like to hear what more UT knowledgeable ppl have to say on this.

foibos wrote:
[...]A headshot counter for personal player (F3) stats: why not, can live without it in ONS
Switch to Player's Stats: why not, can live without it[...]I'm confused here: are you saying these suggestions are good or that they're unnecessary?


Btw, I forgot to add one more suggestion for a possible ONSPlus improvement:
- Improved weapon locker ammo integration: This has been such an obvious flaw for years that, I believe, ppl have already attempted to fix it in other communities with their own mutators/server actors. Basically, if you already have your link gun with some ammo in it, passing through an active locker will only bring it up to 70 whereas if you simply throw it away and grab a new one, it'll have 220 ammo or whatever the max amount has been set to. Same for other weaps probably, but even if it's just for the link gun, this is pretty annoying for a gametype as heavily relying on this gun as ONS is. Fix should simply be "set specific weapon's ammo to same weap as new ammo."

pegasus_ wrote:

- Improved weapon locker ammo integration:

Wulff has coded some cumulative weapon lockers which do what you want (from what I understand from your post). You can see them in action in Hustle.
It can be re-used in any map of course and if ONSplus actually gets expanded I guess having his code around could save some time.

Addendum post with a few more features and fixes I hope to see in a future ONSPlus version:

- Ion tank variants made non-bKeyVehicle: If you've ever gotten out of an Ion tank, or any other vec that inherits its code like the PPC (the ONSHoverTank_IonPlasma code to be precise; conversely, the Railgun tank only shares the same chassis mesh as the ion and has different code), either to heal it or do some other important task, you might've found your ride self-destructing after going unattended (read, unoccupied) for more than 25secs. This is most annoying and can at times put you in a very shitty position if you're in enemy territory and not around that vec factory's node. The reason this happens is because of a property in the Ion tank's code added for the AS purposes of putting pressure on the attacking team for the specific map where the vec was originally featured, AS-Glacier. Still, the same check is done in ONS and the result is a frustrating and pointless mechanic that everyone is simply expected to put up with. This should be fixed.

- Display all vehicles' health (next to player's health) when speccing them: We're talking fixing Epic's oversights now. For some strange reason, when spectating, the health of the vehicle a player is using will show only if the vehicle is a manta, bender, scorpion, or a levi/beam turret or any variant thereof and in no other case (not the levi itself, bizarrely). I can't think of any reason why this feature would be coded in such a way, but I also can't think of any reason why it shouldn't be fixed, if that's possible of course.

- Fix Cicada rockets' damtype incorrectly reporting frags as bender turret kills: Yet another well known retail UT bug whereby if you check a specific player's stats, you'll find all their cicada rocket kills reported as bender skymine frags. This is because in the cicada rocket class' code the reported Vehicle class property is defined as the bender's sidegun pawn instead of the ONSDualAttackCraft itself.

- Set ingame play time to 00:00 when speccers become players to ensure proper pph calculations: Even more retail UT bug squashing. The way things work right now is, when someone logs on a server as a spectator, the server will mark the game time at which they entered and subsequently use that for any calculation such as that for the pph stat (score/gametime) regardless if the speccer happened to join the battle 10 or 20 minutes in. That will both make their pph dramatically lower than it actually should be and possibly net the newcomer some flak and abuse from ignorant ppl who, if their team happened to be losing and they're looking for someone to blame, they'd quickly glance at that player's stats, see they have 0 points after 20mins of ingame presence and go ballistic on them! The solution here would obviously be to readjust the entry time value of any speccer that becomes a player the moment that happens.

- Adjust Raptor and onshovertank karma primitives for more fair/realistic gameplay: Last retail UT issue I'm gonna bring up, but this one's gonna require some showing aside from just describing (pics included). In a nutshell, when it comes to calculating physics, UT's code is pretty crappy so to simplify vehicle collisions, they assigned each vec a collision "area" that's basically a big box defined by the volume each vec occupied. For most vecs this works as you'd expect because their shapes are similar enough to box shapes to accomodate this (the manta, in fact, uses 2 different collision "boxes" to accurately interact with the rest of the UT "physical" world), but when it comes to the raptor, there's a big part of the collision volume that you can shoot at which isn't really the raptor's mesh, but the shot will still count because it makes contact with this invisible box. Even more strange is that the sticky grenades the gren.launcher fires are the only projectile that goes through that area properly :s. Anyway, allowing clearly missed shots to count as hits is unfair to the pilot, but, conversely, when a sneaky raptor pilot tries to run down a player on foot, this bigger volume will help them get frags they normally shouldn't have gotten, so IMO this is problematic balance achieved by two wrongs of convenience instead of proper care and effort. Fixing this would benefit both sides of the coin since, I'm pretty sure we all agree, UT should be a game that promotes fine precision skill over "good enough" sloppiness.
I'm also mentioning the goliath chassis' volume here because, in its case, landing on the front part of a moving enemy tank (not the turret) while trying to flak it to death will mysteriously get you crushed since you're actually standing in it instead of on it. Considering the myriad types of tanks this happens with and the kind of danger each might pose (hello, mino), IMO, this is disproportionately unfair for peds and should be fixed. Tank whores get way more slack as it is.
I bunched these two issues together because, I think, fixing both requires taking the same steps: create a better collision mesh for each and assign those to a new subclassed version of each vec that will automatically replace the originals at the very beginning of each match. I gotta admit I don't know how hard doing something like this might be (or if the engine will even allow non-BSP-esque volumes for vehicles), as messing with meshes is one of UT's creative disciplines I know I want nothing to do with, so take this with a grain of salt until some experienced modeller comments on this.
Edit: I apologize for the smaller size of the uploaded pics; I forgot to disable imageshack's 800x600 resizer :/.

- Toggleable bots shooting nukes: Self-explanatory, I think. Very annoying having your hard earned nukes shot down midair by wiseass, online bots that are otherwise too dumb to even find a node on a map and just loaf about. With a feature like this, each server/community could decide on their own whether they'd benefit from bot antinuke autodefense or not. The answer is not.

- Toggleable server-side force autotaunting off: Also self-explanatory and, frankly, I'm surprised this hasn't ever been considered when the power to override players' other personal settings such as team preference has been given to admins for years now. Nobody cares to hear your tired, automated, "irreverent" remark after you finally managed to score a frag or you'd be listening to ours practically non-stop; if some ppl can't grasp the concepts of maturity and courtesy, in the end perhaps they'd just as well be imposed on them...

- Toggleable snipeable bender/stationary turret users: I don't believe I need to explain this one either. As the last feature I wanted to propose, this is admittedly a bit more out there, but not so much as you'd think; snipeable rear bender turret users is a reality in UT3 and seeing that 3 years ago got me thinking. At first it seemed kinda unfair and imbalanced towards the camping snipers' side, but realizing lately just how bad bender antiair campers can be themselves (esp. in the more powerful custom variants), perhaps this would be an elegant and practical solution to balancing things out. As things are right now, both stationary turret users and bender turret users can create at will and almost immediately quite big zones of air traffic denial and this can be particularly effective when they know that their typical opposition in a particular map won't be strong enough to retaliate (like on Dria-Gorz, VolcanoHigh, Panalesh, etc.). Since the game already bothers to draw their character's model when they're in one, why not put the fear of a headshot in them too ? Btw, this would apply to the squid lovers' kraken version too where its passenger turrets are of the hellbender variety, not the typical levi turrets (go switch to repeater lasers, kraken driver, if you dare!).