[Question] Base and Turret Respawn

[kevATin]

Am I correct assuming that Altitude clients should be able to correctly handle respawning bases and turrets on maps hosted by a custom server? After all there are already 1bd maps, and the client doesn't really care what kind of map it's give, does it? So assuming the server was patched to be able to handle respawning of bases and turrets mid game on any map, (potentially spoofing the map type so the client plays along) the clients wouldn't have a problem with it, right?

[biell]

The base altitude code has two concepts you need to consider:

mapChange : This is the start of a new map, and a new game. Things like bases and powerups reset from here.

roundEnd : This is the end of a round (1 game can have multiple rounds). Things like bases and powerups reset from here.

So, it isn't arbitrary or controllable that these things happen, it is coded based on those events.

It is important to note that the Altitude client and server share the same code base, that is why every client comes with a server. This is actually a bad thing, because the altitude server relies on the altitude client to do a lot of things itself based on very little information. Bandwidth wise, this is great, but it make the game kinda in-secure. A rogue client could really mess things up.

This is also why we don't have the kind of control you are looking for, because the server only tells the client what the round state is, and the client makes it all work for your screen and playing experience.

[kevATin]

Ah I see, yeah I was hoping the server could circumvent this round-cycle that the reset is normally based on and the client would just go along with it. Too bad it's not that easy.

How about a different approach: How do turrets attack players? I presume at least this mechanic is handled by the server, right? Otherwise i could (if I could~) just make a custom client that causes all turrets to ignore me. If I as the server could "disable" turrets that have practically infinite health, then that'd also give us a few more options.

Also how is turret health handled? Quite often when I play I notice turrets getting destroyed and then reappearing with a slight bit of health left, usually after 1 or 2 seconds. I presume that's because of lag, but in any case it shows that the client can be updated on the turret status. Even if that is a bug, it might be exploitable to make it a feature~

[biell]

People keep wanting the authors to open source Altitude, and what you have just said is the reason it can't happen. The code base is way too trusting that the proper client software is running. If you could modify the client code, you could get away with all manner of sins. I believe the server trusts the client that the turrets do their job.

Have you ever killed a turret just to have it re-appear with very little health? The original destruction is your client saying you killed it, and the regeneration is the server denying the clients request to take down the turret because it is dead, saying it still believes there is a little life left.

So, with a server patch, it is "possible" that you could do something, but I don't think it would be easy to do that, and I don't know if it would work consistently across all clients.

[kevATin]

Phew okay then, more disappointment~

So there isn't any "updating" going on, it's just the server denying the clients statement. Does the server have to deny (or confirm) the request immediately or could we delay it by say one minute? What if that were to happen? And depending on the previous answer; could we tell the client we accepted their turret kill, but one minute later have the server send the client a deny to that very same request?

Also this means that we could theoretically accept the turret kill, but not forward the information to other clients, that way each player has to kill their "own" turrets on the map, while other planes are fine. Except of course if my client can decide that your plane is getting shot... that could be a problem if that's the case.

Another thing that came to mind, since the server has to forward to all clients that a turret has been killed, couldn't a turret death be faked/forced that way? This could be useful for coop maps and other stuff, simply have a turret disappear after certain objectives have been met.

[biell]

All of that is in the base Altitude code, and other than Xal's server patches, that can't change. He no longer has time to make updates, and the updates like that are actually very difficult. He decompiled the JAVA code, but that leaves you with variable/function names like aa, ab, ac, ... and he had to figure out what everything did. It was difficult work, to say the least. It was helped out by reading the string constants and comparing to a very old copy of the altitude source which was once publicly available (version 1.0 or something). It also helps that he is a programming wizard.

Altitude is a really interesting game, and the authors did an amazing job at creating an interface for interaction. This is a thing which really doesn't exist in normal games. That being said, this interface was really designed for things like ladder, and not what I did, or what you are looking to do. But, once you open pandora's box, you can't close it. And they added more and more functionality to their interface. After that, Xal came along and added even more.

And, that is where I came in, pretty much stressing the ability to extend Altitude to its breaking point (and sometimes stepping over that line) with my coop additions and new game types like race, tag, ruin, mdg, flag.

To interface with altitude, the only mechanism is to read the log.txt file and write to the command.txt file. It might be worth while to, while people are playing on your server, open two windows and perform a tail -f on both files, to see how the interaction works. It might give you an idea of the flow of information, and how the interaction plays out. It is easy for me to forget how complex it is to understand all this, as I have literally spent hundreds of hours staring at altitude logs while creating and supporting Alti+; but, it really isn't intuitive how it all works. That being said, it is logical, and once you understand it, you can work within the framework.

Another thing to think about for the interface is that it is all about reading from log.txt and writting to command.txt and each operation has lag, so you want to try to keep your interactions to things that can withstand a 250ms lag. Average lag will be less.

[kevATin]

When I wrote that reply I didn't have alti+server in particular in mind. I guess alti+server just being able to read logs and use the command-line is quite limiting, and extending xals patch is complicated. But those aren't the only things that can be done, right?

Couldn't functionality like that be achieved with packet filter firewalls or something similar? I don't have experience with this, but in theory it doesn't seem too complicated. If I remember correctly Altitude just uses UDP, so if some packets are missing it won't freak out and drop the connection, right?

The packet filter runs either network wide or around the altitude server and alti+server instructs the filter periodically on which packets to specifically not forward to the server/client, etc.

I'll have to read more into this~

To interface with altitude, the only mechanism is to read the log.txt file and write to the command.txt file. It might be worth while to, while people are playing on your server, open two windows and perform a tail -f on both files, to see how the interaction works.

Will do.

[biell]

you may be able to generate and/or manipulate packets. But, I would think that to be very difficult. I have not looked at altitude network traffic before to offer advice in that arena.

You might want to check out this repository, there was an attempt to make information available regarding how Altitude works for people to write their own code to talk to the server:

https://gitlab.com/alti2d/vanilla_mod

[kevATin]

Yeah I'll read up on packet filtering when I find the time~ Will keep you updated if I'm successful with experimenting.

Sorry but that git project seems to be private (and since you're member there you can see it). I can only see the 3 public projects in the group https://gitlab.com/alti2d

[biell]

Sorry, I didn't realize that was a private repo. It makes sense, since it could be used to mess with an altitude server and ruin the game for everyone. You could approach Xal and see if he would open it up for you, and if he even thinks it would be helpful.

[kevATin]

I've talked a bit to xal in the past, just haven't had contact in a while, was planning on talking to him anyways, now I've got one more excuse.

Apropos messing with altitude; what "hacks/cheats" have you encountered in Altitude before? I remember seeing people speed hacking (there's a bug that seems to sometimes be caused by bad connection thought I'm not sure, that causes planes to fly faster, either all or just individual ones, but this was clearly speed hacking), I remember seeing that years ago. And a few months ago there was someone who if I remember correctly, insta killed everyone right after they spawned, not even kill aura or something, and right after kicking them everyone was able to spawn (and live) again.

Has there been any attempt at improving Altitude security? The speed stuff was years ago, so the Nimbly guys might've added some basic protections against that, but if not maybe checking if a player's position moves too quickly, then that incident could be sent to admins who can then verify and ban. As for the kill part, we're back at the problem with the client having ultimate control and pushing the server around. But even without packet filtering, the server could see if all players just got randomly killed by player xyz while that one wasn't even close to some other players, then they were probably cheating.

I guess it's hard to implement sensible counter measures against cheating in Alti, because it doesn't happen all that often, and when it does you usually aren't ready to analyze it carefully. If it happens on my server, I'll be sure to check the logs~