Coop+ request: doors that only let you through if you're carrying a ball

[19 cm]

Biell, would it be possible?

Rationale: there are fun aspects to the idea of carrying a charge across the map (e.g. passing), but unfortunately the charge cannot be used in TBD. Using the ball kinda works, but the ball game type has the nasty side effect of respawning everyone if ball is lost.

So the idea is to stick with TBD game type but only let ball carriers into the base area (where presumably there are unlimited bombs waiting to be dropped onto the base, or just a nuke that kills the base when you approach).

[biell]

Originally Posted by 19 cm

Biell, would it be possible?

Rationale: there are fun aspects to the idea of carrying a charge across the map (e.g. passing), but unfortunately the charge cannot be used in TBD. Using the ball kinda works, but the ball game type has the nasty side effect of respawning everyone if ball is lost.

So the idea is to stick with TBD game type but only let ball carriers into the base area (where presumably there are unlimited bombs waiting to be dropped onto the base, or just a nuke that kills the base when you approach).

I agree, I wanted to make use of charge passing, but could never figure out how to make it work. The idea of a door where you have to possess a specific powerup to pass through is intriguing, and not hard to implement. But, I would want to make sure it is what you really want, as it would require going through a lot of code to ensure it is fully supported without breaking anything and would require an addition to the door data structure.

Like the charge in 1de_coop, you want to make sure the players have two different places to go, correct? One way to do this in an existing Alti+ server is to change the "keys" mode from "team" to "personal". The defaul is "team". In "team" mode, anyone on a team can find a key, and everyone on that team gets credit (ala jack and ace). In "personal" mode, only the player who finds the key gets credit for it. So, if I skip the key, I can still help you advance across the map, but I can never actually cross the door threshold. So, my ability to help stops there. This exists now, and you could create a map to use this feature.

Additionally, you could make the key the only health powerup on the map, and set "spawnMode" to "health" to ensure that is the player's new starting position if they die. Instead, you could use any powerup you want, and make it a spawn zone. But, just be aware for both of those that players can use "/sz" to change their spawn zone back to the start. I use a spawn zone as a checkpoint on coop_undersea_adventure.

A third way to do this which keeps people from benefiting from running "/sz start" would be to
use portals. Have the first leg (to what would be the charge) get you to a portal which teleports you to an otherwise unconnected part of the map. Then, allow players to progress from there. players loose bars, powerups, etc. when they teleport, but people don't seem to mind that too much on jack and ace. Oyster even used a portal on the race_rainbowroad, and that is loads of fun.

You should look into installing the windows version of Altitude under wine. I use wine on Arch Linux to make maps. While there are a few quirks, the map editor is quirky in general; so what are a couple more? Then, you could play around with some of these features a little more.

[19 cm]

It doesn't matter a whole lot how exactly the ball will be used as long as there is *some* way to use it.

If xal could find a way to disable the "ball lost" forced respawn in ball games, that would be perfect I think.


The whole point of having a charge on the map and not merely a DESTROY button on the base is to give players another dimension where to build and excercise skill, in addition to the basic ones like moving around with confidence, staying alive, killing turrets and using powerups.

The charge carrier takes onto themselves extra responsibilty and extra difficulty. You can no longer (easily) use powerups, and you're very vulnerable when planting the charge, so you need to cooperate with other players so as to achive the common goal of finishing the map.

The same ideas apply to the ball and the bomb. They are three different kinds of handicaps with somewhat different properties.

[19 cm]

I have tried Wine, I have tried the Linux version, and I have tried all kinds of virtual machines, with the same basic result: the editor crashes or freezes when you start working with the map. The only configuration that ever worked for me is plain Windows on real hardware.

Thanks for the encouragement though, I'll try to play with it some more. Maybe upgrading the distro (LinuxMint 17.1 Rebecca) will help.

[biell]

OK, that makes sense. I should be able to update "/add key" such that if a powerup name is specified (like "/add key [name] [door] [team] [Bomb|Ball|Demolition Charge|Health|Shield|...]"), then you must posess that specific powerup to pass through the door. You could call it multiple times if you want more than one powerup to be acceptible. I will probably also add a short cut named "Charge" for "Demolition Charge".

Be aware that I can't keep a troll from throwing the demo charge through the door and killing the game. At least a ball would get lost and you could start again.


I also could not get the editor to work in wine for the longest time. After I finally moved my .wine directory out of the way and allowed it to create a brand new one from scratch, that is when I finally got the editor working.

[LewisH]

> If xal could find a way to disable the "ball lost" forced respawn in ball games, that would be perfect I think.

I've been working on a re-implementation of the altitude server for about a year now, you can watch my progress on gitlab (https://gitlab.com/xalri/libalt/tree/message, will be merging to master in the next few weeks), though the user-facing documentation is rather sparse (perhaps the code docs would be interesting to someone: https://xa1.uk/libalt/libalt/index.html)... I expect to have the basis working early next year (maybe febuary), though my initial estimate was for the past summer, so yeah, estimates are difficult.

It's open source, and architected in a way which is very flexible about what a game can be and what different clients see -- the only limitations should be limitations of the client, and what we can express through altitude's packet format.

wrt how it will interface with external mods: The first option is to not do so -- the core of the server is a library, written in rust, so a specialised server would simply be a rust program which extends the functionality provided by the library. This gives the most flexibility of all options, but restricts the language to rust. Another option is something similar to the vanilla server -- communicating through text files. I don't like this option, but I may eventually go for partial compatibility with the vanilla server, which would of course have this interface. A third is for the server to expose a socket for control messages, over TCP or a unix socket, probably using a format like JSON for maxium compatibility. I don't know if I'll implement this, but it's something which doesn't require any considerations in the core library, so it's not of great concern yet...

Anyway, I doubt I'll work on my vanilla server patches any more, they weren't more than an experiment to begin with, and I don't enjoy working in java. I think coop would be a good target for my server software, so any suggestions on that front would be good -- what can I do to make this project useful to people when it's eventually in a usable state? ^^

[estguy]

no worries lewish :P we'll get enough ideas to keep you working trhough out the time.
also wew, you seem to work on quite alot