shadow_slicer wrote:Could you elaborate in more detail what you see as the difference between "owning" a ship and merely controlling a ship? I'm not sure I understand the distinction, especially if we also consider temporary ownership.
The difference is semantic, but semantics are critical in programming. Using an incorrect term tends to needlessly complicate thinking about how to model a problem. I would turn the tables and ask you "could you elaborate in more detail what you mean by 'temporary ownership'?"
I'll spare you the trouble: You meant "control".
Ownership means that you have permanent control, until you voluntarily relinquish it; so the term "temporary ownership" is an oxymoron.
What I mean by temporary ownership is this: the player has full control over the ship as if they owned it, but cannot sell it at the ship dealer. If you wanted to restrict upgrades, you could use the normal methods in units.csv to limit additional upgrades, and build in all features so they can't be sold. This would also allow the player to make repairs and restock ammo.
That's all fine; but why call it "temporary
ownership", then?
In order to do that, we would need to do a few things:
1) Figure out a way to discriminate between owned ships and temporarily owned ships in the save file.
2) Modify ship dealer interface to make temporarily owned ships incapable of being sold (this would be trivial if we have 1)
3) Separate the sellShip, buyShip and switchShip portions of the base interface into more generic functions and make them callable from python (to allow missions to give you ships [you buy at cost=0], and take away ships) -- actually PU already allows you to buy/sell ships from python...how do they do that?
4) Figure out what to do if the player is forced to return a ship, and they have no other ships currently at that base...
5) Find a way to remove the ship if the player cancels the mission. This is a big problem since the player will likely be trying everything to find a loophole so they can keep the Ubership after the mission.
Well, let me show you the benefit of semantics, now:
By calling this "temporary ownership", you made this, in your mind, a "special case" of ownership, and proceeded to think about how to tweak the code to make it work for this special case. This is the kind of thinking process that leads to code forever getting more complex and intractable.
If, instead, we think about "control", and then "ownership" as being a special case of "control", everything becomes simpler and clearer:
We begin by coding the methods and conditions by which control of a ship is given, acquired, relinquished. This enables us to have party A transferring control of a ship to party B. Aboard a carrier, as a pilot you are given control to a ship to fly a mission, for example. We can code this simply by getting rid of the implied money transactions and thus
simplifying the code!
Additionally, we gain some clarity even at the interface: Note that, currently, the My Fleet interface is confusing, because to switch ships you have to click on the Buy button, even though you've already paid for it.
So, now, that button would change to [Take] or [Pick].
And why should "control" come before "ownership"? Because it's the natural order of things: Economics, commerce, legal concepts... These are late inventions layered on top of "the law of the jungle"; but the law of the jungle is the only real law; and these layers subsume, rather than replace the law of the jungle. The law of the jungle is present at every moment: If we don't obey the laws, policemen use
force on us, NOT laws. Everything boils down to force, in the end; we just don't like to see it that way, but it's how it is.
The most basic fact software needs to model is who is controlling a ship, never mind who legally owns it. Just two command functions: "void give_ctrl()" and "void take_ctrl()", and a query, "bool has_ctrl()"; the rest is coding conditions under which those two functions are called. Control is the low-level interface. Ownership is a high level interface, built on top of control.
So, once we've simplified the code to deal with nothing more and nothing less than who has control over a ship, then we can add a layer of code regarding "ownership", which will have
some bearing on how control over a ship changes hands. Then we will be able to have functions such as "buy()", "sell()", "borrow()", "lend()", "rent()", "lease()" or even "steal()". (Yes, the term "stealing" recognizes ownership; otherwise it would simply be "taking".)
I say "some bearing" because pirates, for example, would be blind to issues of "ownership". They'd laugh at a piece of paper. To them all you've got is
control of your ship and its cargo, and the only question is about your ability to defend this control. But if the software assumes that "ownership" is some kind of objective reality, it can only model piracy by hacking it
around ownership.
And what IS "ownership", anyways? Ownership is a state of mind. The worst mistake we could make, software-wise, is to put an attribute in "ship" referring to an "owner". Being a state of mind, ownership is an attribute of owners, rather than attribute of the objects they own. Dumb programmers would charge like bulls, head-first, into hard-coding a reference to an owner in class ship; 99.9% probability they'd ironically invoke "simplicity" as an argument for doing so, and would paint themselves into a corner, as later on they'd be unable, without major refactoring, to represent the fact that ownership over something could be disputed between two or more parties; or the fact that an object could be owned "in paper" by some guy, but in reality 90% owned by the bank who loaned him the money; and ships without owners would segfault half the time.
Ownership is a state of mind, a concept, and therefore there are gray areas, exceptions and confusion. You could have different "kinds of ownership", like if you're leasing a ship with a 10 year contract, it's "almost" like owning the ship, and you'd probably be allowed, in the contract, to make hull modifications, such as adding pylons or mounts; but if you are only leasing for 1 year, you might not have such liberties.
Armed with the understanding that ownership is a vague human concept, rather than an 'objective' reality, and with the understanding that control comes first, these subtleties would be fairly easy to overlay on top of a solid software package modelling control; but it would be absolute Hell to try to implement them as a modification of the existing "ownership-based" code.
Correct semantics are essential to clear thinking, which in turn is essential to clear coding.