If you had a clue what you were talking about I'd go into more detail, but you don't, so I won't.

Both, for a ship buyout. When you do a buyout, it
limits your opponent's ability to come back into
the game. But if they have ships, and they time it
right, they can sell one and get them back in. That
causes a slow drain of ships on your enemy, forcing
them to be more conservative, locking down their
game.

Eventually, if they aren't careful, they end up not
having enough ships for daily operations. They have
to sell that colt they were using, or that big defender
they were using, etc, etc.

But most people stop before that point. By putting
a limit on their aggressiveness, it makes it easier to
defend stuff and easier to be aggressive. Most corps,
faced with a buyout, just kind of implode and quit.

2000 ships in a turns game is a lot of ships. That
takes a lot of turns, and for that reason they are rare.
Most of the time you go to dock and see a load of ships,
or notice that the ship numbers are suddenly very high,
and that tips you off to check and buy some yourself.
Crank that up to 10,000 ships, add a small rule against
it, and I doubt anyone would bother to try.

But in an unlim... you can do a buyout overnight with
some automation. Thats where the problem is.

In some edits you don't even have to do a buyout to accomplish the same thing because total ships are set low. Alien capping in unlims can allow enough caps to effectively do the same thing w/o hitting the server rule against buyouts. It takes a while since in most alien cap games I see an alien to cap every 2-3 minutes on average. The best way, as Sing pointed out, is to set the number of ships very high.

The downside to the alien capping method is that unless the ships are made personal it will affect the reds cashing in the current TWGS.

               / Promethius / Enigma / Wolfen /

"A man who has no skills can be taught, a man who has no honor has nothing."

10000 ships (or 30k) with a 50 personal ship limit,
and a configurable corp limit, would work fine. In
games like subzero, the corp limit could be raised
to 1k, in games where buyouts are a problem the
limit could be lowered.

This way, bringing in individuals to lock the ships
up would be time consuming. It wouldn't stop the
problem entirely in an unlim, but it would make it
very difficult.

Ok, here are some thoughts based on what's been said.

1) Any lag is caused by inefficient or even buggy could and can almost certainly be fixed. If nothing else, I can shift the slowdown to the one who's buying and shield anyone else from it. I just need to test and optimize the ship buy function for dealing with maxing out the ship count.

2) If there's a major problem with getting back into a ship after being #SD#, why not keep a ship record held over for every dead player? That way you're guaranteed a ship to return to the game. No sense in returning the ship to the unused pool so someone with 500 ships can grab it, leaving you without a ship to fly in. Another option would be to allow you to return to the game into one of your unmanned ships if no other ships are available.

Actually it's not the buydown itself that is the culprit. It's the update when somone uses the xport feature. Ships aren't as bad as planet buyouts on a server when updating, but it still effects the cpu load. The problem with saving records, you'd have to save quite a few to accomadate any new players wanting to enter the game and not just players that are ship destroyed. Out of all the things I said above, the server issue is the only thing I'm concerned with. As I said other, some people feel that this is a viable tactic in the game, but I just don't want somone crashing my server by creating the maximum planets and/or buying the maximum ships.

I'd think that it's less of a concern for new players than existing ones. Keeping a ship record open for a dead player wouldn't take too many ships out of the pool. Max 500 in a game with 500 players, but when's the last time you saw that? In practice, it wouldn't take too many ships for a typical game. If a buyout locks out new players, so what? The game is between the big boys who are in the game at that point, I'd think.

By putting pacing into things like the Transport listing, these server load issues are already being dealt with. If it remains a problem, we can increase the pacing delays so that it takes longer to generate transport lists.

A ship buy delay of 100ms would probably fix the
lag associated with that. I don't know of many
people that need to buy more than 10 ships a second.

Reserving a ship record would help in getting back
in, but that wouldn't eliminate all of a buyout's
power. The unmanned ships option could be hugely
abused.

How about instead of reserving ships just for players,
you keep a reserve for corps too. If players could
only buy a max of...
limit - (player count * 2) - (corp count * 50)

Then games that require larger ship counts (like
subzero) could still function, but ship buyouts would
be almost pointless (would be pointless in a turns
game).

@D:
The xport lag has been worked on. The new xport
delay plus the ability to abort most of the internal
processing of the xport list fixes most of it.

Server stability is not an option. The server must be
stable, even if it means sacrificing a marginal tactic.

So basically, you could reserve a certain number of ships for each player and a certain number for each Corp, and then it's first-come-first-serve among the remaining ships. So for a game with 50 players and 10 corps, with 2000 ships, you'd have 50*2+10*50=600 ships in reserve, only available to the player and Corp that controls them, and 1400 ships in a general pool. Or, to keep the original 2000 ship public pool, we could add an additional pool of reserved ships to the specified ship count, so in the above example, you'd have 2000 ships plus 600 ships, or 2600 total ships in the game. I kind of like this better than hard limits because you still have plenty of room to grab up extra ships if you need them, but there's really no incentive to buying the non-reserved pool out because players and corps will still have plenty to work with in their reserved pool.

Yes that's the line of thought that I was on. As corp numbers increase/decrease and player numbers increase/decreae, some of those figures would be subjected to change however.

BigD, are you saying make the reserves dynamic? Because I was thinking they'd be static. If the game can support 200 players and 200 corps max, then you could have a base of 2000 ships in the shared pool, but the capacity to grow an additional 200*2+200*50=10,400 ships, though in practice you would most likely not have nearly this many ships in use. So the ship file would support a larger amount, but the actual amount in use would depend on the number of players and Corp sizes in the actual game, something that would most likely lead to a much smaller reserved pool in active use. Looking at the maximum possible for a game, that would be 2000 shared pool plus 500*2+500*50=26000 max, which is a maximum supported ship size of 28,000, within range of the 30K limit. We could allow the shared pool to grow to 4000 ships and remain within our 30K maximum.

But let's look at what would actually happen in a maximum capacity game. Just because you allow support for 500 players and 500 corporations doesn't mean you'll have that many. More likely you'll have like 20 players and 5 corporations or something like that. So you end up with 4000 shared pool ships plus 290 reserved pool ships, and that would have very little impact on the performance of the game.

I think this would work fine.

I see what you are saying now. The maximum would never be over the cap of the amount of players allowed into the game.

Cool, I'll take a look at adding this and let's see what it does. Do we even need to make this transparent to players, or just make it an internal maintanence thing? If you've used your max amount and there aren't any more ships in the public pool, you'd just get the "no more ships" message as before. You don't necessarily need to know about your limit of 2 reserved personal and 50 corp ships. So all I really need to do is write some code to manage allocation of ships and that's that.

Just continue to send the same "no ships available" message.

That way it doesn't break existing scripts, but solves the issue.