well given the mechanics of long distance travel in VO, a battle fleet could simply warp in right next to a station, having the sectors surrounding it becomes pointless.

Unless the surrounding sectors had some sort of defenses in place which have the same effect as an ion storm, forcing ships out of a jump prematurely.

Now that I like, some kind of ion storm generator, where have I heard of something similar? oh yea, dosent EVE have something like that, and a starwars game, empire at war I think. Not that it's nessecarily bad just because it has been sucessful, quite the opposite, sometimes popular things are popular for a reason. oh yea the independence war series also had something like that.

Now that I like, some kind of ion storm generator, where have I heard of something similar? oh yea, dosent EVE have something like that, and a starwars game, empire at war I think. Not that it's nessecarily bad just because it has been sucessful, quite the opposite, sometimes popular things are popular for a reason. oh yea the independence war series also had something like that.

I don't like the idea of an Ion storm generator (enough of those bloody things around as it is). Something like a sector wide warp-inhibitor field could be nice though.

Are you smoking pot?

Every player has a name, and a creation date. Combined that forms a unique key. You don't even need the date since we have unique names.

You keep thinking in terms of keys. You should be thinking in terms of locks. I take over system x, the lock of system x is then set to my key. I can then look at what my key controls, and change any lock, or group of locks, to give privileges to other keys, or groups of keys, or factions, or whatever. The keys and locks are stored server side, the privilege settings are backed up client side.

When a lock changes hands, all the old privileges are canceled. The new owner's client is checked for a pre-existing backup of privileges for that lock, and/or default privileges for all locks. That way if you recover a lock you haven't lost all your settings.

I haven't bothered to google anything at this point, but I would imagine this entire topic to be a very old topic, on the internet in general.

... and please lay off the pot. it will fry your brain.

Restayvien: pay attention. Depending on how you define 'sector wide warp-inhibitor field' the two things you're talking about are either one and the same, or the latter doesn't address the issue at hand.

Anyway, if you ever unintentionally run into an ion storm you're simply a bad pilot.

If we are to have shared storage for personal,group and guild usage then multiple keys will be needed so there will be a need to generate them. Keys could be randomly generated using playername and date/time.

Please try to stay on topic.......There is a separate thread to discuss the mechanics of conquering stuff.

Roda: I think you're missing a point somewhere. I don't want access-control-lists stored for every instance of a key, compared to all the players for whom they want to define access. I would rather have a trivial data block that has no tie to an actual player, can be moved around completely independently, and only requires an inventory check (something inherently available when a player is in a sector anyway). I definitely don't want to transmit privileges over the network, they could get pretty large and complex, and where is the value? It just adds further Ick to a situation.

I welcome criticism or alternative ideas. Mine is based on a concept of what I think will be flexible enough for us to use over the long term, while also working well enough with our architecture and database mechanics. It's not a sure thing, and we may modify it or implement something different. But there's no reason to imply that my thinking is drug-addled, especially when your own logic is far more fundamentally flawed.

Well to be fair you have created a space game, that usually denotes being high in the first place

But! i like your key system. Get crackin! *whip whip*

/me hands Roda some K-Y

What are you doing in the same room as Roda with a bottle of KY there doc?

Edit: Sorry, I should probably add something to the discussion. Personally I think the concept of keys as cargo is a horrible idea. The fact that you would have to carry around a physical key this day in age seems needlessly archaic, especially given that there is no chance we, as players, can ever lose credits in such a manner (or any manner for that case). And something so large that it takes up cargo space in your ship...?

That said, some sort of spy/sabotage mechanic that existed outside the need to "conquer" an asset would be neat.

It would be useful if a group of people could hold ownership of a key in common in such a way that use and control of this key would require the group to act in concert. It is scary to trust some individual with group property and decisions.

it dosent nessecarily have to take up cargo in the ship, it can be loaded into the ship's computer, or not loaded if you please. wtih the serco around biometrics becomes an unworkable solution, as given enough technology to be thrown at the issue, biometrics can be faked.

and maalik, it's not so scary when you have multiple accounts, I've been one man mining and escort groups before. I've got friends with oodles of time on their hands, I could conceivable have them all with me on accounts I own, helping me accomplish X goal. That being said, you can also just only risk what you're willing to lose, even if your entire invintory were to become vulnreble, thats what alts are for.

incarnate:

Forgive me for attempting to blame drugs for something I see all too often in even well educated professionals. And that is to start from the wrong end of the problem.

I think you are missing the point. The one thing that is inescapable is that every instance of a lockable object will require a "lock", and that should be the center point of the system.

The terminology is important here. You can mean the same thing, but if you say key, you communicate something that can be transfered independent of the object that is lockable. By referring to a "lock", you make it plain that it is something that is part of the object in questions. Keys are just abstractions imposed on a layer above the lock. The lock is the fundamental layer.

Each lock is independent, and is completely unaware of all other locks.

Each lock may have a table of records with each record containing a single player and access level.

A player may have access to many locks, and you may even build an interface that allows a player to set the same settings on many locks at once, but that is done at the interface level. Such relations between locks is arbitrary and optional at the interface, and each lock has no need to know about it or track it.

You can create a key that does all kinds of things, like control many locks, but it is an abstraction that exist on a separate layer from the lock. There are an endless number of things a key can do. Build the lock, include minimalistic functionality, and add advanced key functionality as demand arises.

Heh. Well, that's nice, Roda. You have seemingly missed the fact that I am attempting to avoid tables of users tied to.. anything at all ("locks" or "keys" or whatever you want to call them). The whole idea was not based around "locks" or "keys" or anything of the sort, it was based on our inventory management and the knowledge of what data is available at what time. Any system based on lists could end up containing thousands of entries of individual character IDs and the ACLs permitted. Instead we'll have a handful of keys and the ACLs that are inherent to them (at the currently loaded location), and only the character's key-inventory to contend with, both of which are in memory at any time when a comparison is likely to occur, and do not require database access. All the aggregation stuff you refer to (setting multiple locks) can also be done just as easily with the key-based inventory object; as you say, it's all UI. Plus, having the key be an inventory object allows us to very simply use it as an inventory object, in the manner that people have been discussing on here (dropping keys, stealing keys, losing keys, etc).

The system you propose would also achieve the same ends. It would just suck.

The system you propose would also achieve the same ends. It would just suck.

Even K-Y won't help with a 14" strapon wrapped in rusty barbed wire.

<sigh>. Thanks for that great mental image there, Lecter. So ANYhoo, let's keep further discussion on-target to comments or concerns over the specific system proposed in the first post.

Inc, to clarify my "Temporary Keys" idea - yes, of course pirates could just sell the station back. However, if ownership of a given object would only transfer after an object had been held for at least a certain consecutive amount of time (say 30mins for a station), the original owner would now have two alternatives: pay either an exorbitant ransom, or organize a counter-offensive and have the chance to win the station back at no cost (except for expenses, rewards and such).

If the original owner wins, he/she would no doubt save a ridiculous amount of money. If the original owner loses, he/she could still pay a (obviously now larger) ransom.

Either way, I think this practically guarantees huge furballs, with a player involvement comparable only to NW.

Don't get me wrong - my recently found vocation as a pirate would surely appreciate a massive ransom. I just see it more like killing a Connie - sure, the drops are nice, but the real fun is actually managing to kill the thing.

Addendum: If I ever were to conquer a station, I could guarantee you that I wouldn't sell it back for any amount. Add to that the current economy (with everybody being insanely rich), I believe there's a high probability that I'm not the only one who thinks this way.

If an object as valuable as a station would come with such a high risk of instant permanent loss, that might lower the incentive to other players of building/acquiring such objects in the first place.