Mine X Units of Ore on Ike an Beam It to Duna

[something]

You know these contracts. They require you to mine a lot of ore somewhere you don't need any ore and lift it to orbit of another celestial body  (or even land it there).

While I always wondered, why I should ship ore from Ike to the Orbit of Duna, given the fact that I had a complete ISRU station on the surface of Duna, I accepted the contract anyways as I had mining equipment on Ike as well. And 400k for flying from Ike to Duna is a pretty good payment.

Now once I reached the required amount of ore on Ike, I realised I had too little fuel to get to Duna. No problem. In that case I simply transferred the interplanetary transfer vehicle from Duna orbit to Ike orbit...

 

But upon switching to the vessel in Duna orbit the contract was paid out as it was completed. Turned out the vessel I switched to had ore onboard which exceeded the requirements of the contract.

 

To make a long story short - these kind of contracts are miswritten. They only require "mine x units of ore here" and "have x units of ore in orbit there". Knowing that,  I exploited the bug more often. I don't know. But at least three times I got paid for mining on Ike and having totally unrelated ore in orbit of Duna.

[Snark]

1 hour ago, something said:

To make a long story short - these kind of contracts are miswritten. They only require "mine x units of ore here" and "have x units of ore in orbit there". Knowing that,  I exploited the bug more often. I don't know. But at least three times I got paid for mining on Ike and having totally unrelated ore in orbit of Duna.

I wouldn't say that they're miswritten.  You're right, they only require "mine X units of ore here" and "have X units of ore there".  But that is also exactly what the contract says.  It's the actual, literal text of the success criteria stated in the contract.  I'd only call it "miswritten" if the success criterion didn't match the actual, literal text of the contract.  Moral of the story:  read the fine print. 

It gets even better (or worse, depending on your viewpoint).  Suppose you have a contract that wants you to mine ore on Mun or Minmus, and have landed ore at Kerbin.  So... just go mine the ore on Mun or Minmus.  Then switch back to KSC, and launch a new ship that has ore already in the tanks, and presto!  Your contract completes as soon as the new ship hits the launchpad, which of course you can then immediately recover for 100% funds.

Agreed that it's a bit silly, and is violating the spirit of the contract, though not the letter.  I believe it's basically a technical limitation:  resources aren't physical objects that are tracked, it's just a number.  A vessel that has X units of resources aboard doesn't have any record of where that resource came from, or when it was produced, and trying to make it do so would be a big technical hurdle and a lot of coding.  So it's not all that surprising to me that it works this way, and I wouldn't hold my breath expecting to see the behavior change any time soon-- it has a very poor bang for the buck, in terms of "gameplay benefit" versus "development effort needed to implement".

It's just one of those things.

[Kerbart]

KSP not only teaches Obrital Mechanics, but Contract Law as well.

[KerikBalm]

I posted about this a long time ago (May 2015):

 

 

 

[Bomaye]

18 minutes ago, Kerbart said:

KSP not only teaches Obrital Mechanics, but Contract Law as well.

This is so much win :-D 

[theend3r]

19 hours ago, Snark said:

I believe it's basically a technical limitation:  resources aren't physical objects that are tracked, it's just a number.  A vessel that has X units of resources aboard doesn't have any record of where that resource came from, or when it was produced, and trying to make it do so would be a big technical hurdle and a lot of coding.

No, it wouldn't. Saving where and how much was mined in the craft section of your save should be quite simple. Or an even easier solution: just check if the vessel has landed on the mining body - Final Frontier can already do that.

Edited October 4, 2016 by theend3r

[StarStryder]

3 minutes ago, theend3r said:

No, it wouldn't. Saving where and how much was mined in the craft section of your save should be quite simple. Or an even easier solution: have the contract blacklist any vessel that has ore on board at the time it is accepted.

So your ore carrier is full at the time of contract acceptance.  You empty the tanks, head to the contracted ore source, fill up from the miner and head to the contract destination.  Does the contract complete?  

It's not as simple as you're making out.

[theend3r]

Just now, StarStryder said:

So your ore carrier is full at the time of contract acceptance.  You empty the tanks, head to the contracted ore source, fill up from the miner and head to the contract destination.  Does the contract complete?  

It's not as simple as you're making out.

Yes, I edited the post. Still not perfect, but better.

[magnemoe]

26 minutes ago, theend3r said:

No, it wouldn't. Saving where and how much was mined in the craft section of your save should be quite simple. Or an even easier solution: just check if the vessel has landed on the mining body - Final Frontier can already do that.

So docking with an probe tanker in Mun orbit transfer ore and fuel before returning it to Kerbin would fail the contract:
This is how I have done it on Mun, on minmus its just as well to land next to miner however that require KAS to be practical. 
 

[katateochi]

1 hour ago, theend3r said:

Or an even easier solution: just check if the vessel has landed on the mining body

What if you mine the ore in one craft and shuttle it to orbit, transfer it to an orbital tanker which then goes to orbit the destination planet and there transfers it into another craft which carries it down. The vessel which completes the contract won't even have been near the SOI of the mining body.

You either have to track individual units of resource.
Or you need some kind of shipping manifest document which has to originate at the mining site (from the mining craft) and be transferred along with the ore as you move it between craft.  So the "manifest document" would be like a resource and can be transferred between command pods on docked craft and would become invalidated if the total ore on the ship with the document drops below what's set on it.  Contract completion them becomes more about getting the document from the mining site to the contract destination rather than the actual ore, but the document becomes invalid if at any point the ore on the craft it's on drops below the amount set on the manifest document. 
That could also work with multiple shipping manifests for smaller amounts than the contract needs; contract completion just requires that enough shipping manifests arrive at the destination (stamped as being from the right source). If you had a tanker which collected up ore from the surface then it would also collect a set of shipping documents and in that case if the total ore on the tanker drops below the total for all the documents you'd invalidate the smallest manifest first and if the total ore on board is still lower than the remaining manifests state, then invalidate the next smallest and so on.
I think that wouldn't be as hard to implement as tracking individual units of ore and where they came from. Essentially all the system has to care about is that if a ship carrying a shipping manifest for X resource drops below the level for that resource which the manifest is set to, then invalidate the manifest.  Contract completion just requires that it gets enough manifests to meet the total required and that each manifest is dated after the contract start date and originates from the right place.
 

[Val]

5 minutes ago, katateochi said:

the document becomes invalid if at any point the ore on the craft it's on drops below the amount set on the manifest document

Harsh. What if I accidentally undock before transfering either ore or manifest. Shouldn't I be able to EVA a Kerbal over with the manifest. (Like you can with science)

Which brings another question. What kind of storeage would you need for manifests?

[Blaarkies]

53 minutes ago, theend3r said:

No, it wouldn't. Saving where and how much was mined in the craft section of your save should be quite simple. Or an even easier solution: just check if the vessel has landed on the mining body - Final Frontier can already do that.

Thats close but the physical ore needs to be tracked(I would never take my Minmus miner back to Kerbin just for a contract). They could label a craft based on ore obtained:
- Miner gets new ore from drills on Minmus...Miner is now marked as having Minmus ore
- A lander that came from Mun(that is marked as having Mun ore) comes in and fills up on Minmus ore...Now the Mun lander is "infected" with both Minmus/Mun ore type labels.
- These labels are applied on any ships that the ore is transferred to(docking), and only removed when all ore tanks from a craft are empty
- Now to complete the contract, the Kerbin vehicle needs to dock with something that came from Minmus(something that attained the Minmus ore label at least). Just leave that Minmus type craft at KSC to redock each time now...

This system can still be cheated, just more effort. Now, add numerical amounts to these labels and we see that the bigger problem is need a GUI with which we can transfer "Mun ore" instead of "Minmus ore"...that becomes silly

[tater]

Like most KSP contracts, they're really dumb and make no sense at all.

[katateochi]

7 minutes ago, Val said:

Harsh. What if I accidentally undock before transfering either ore or manifest

I think the game should provide a prompt. if you start to undock and if by doing so you'd separate the document from the resources it should warn you.  Or preferably the game would transfer the documents automatically for you.  

10 minutes ago, Val said:

Shouldn't I be able to EVA a Kerbal over with the manifest

No, document has to remain with the cargo at all times. If you could EVA it then that would open up the possibility of you just sending the document somewhere without the cargo. 

[Snark]

4 hours ago, theend3r said:

No, it wouldn't. Saving where and how much was mined in the craft section of your save should be quite simple.

I really don't think so.

I've got 50 ore in my tank.  I mined some of it on Minmus and some of it on the Mun.  How do I keep track of that?  Especially when you consider that ore can be transferred from one ship to another, and stuff all mixes together?  I mine 100 units of ore on Minmus, then 100 units of ore on the Mun, then I want to transfer that Mun ore to a reentry vehicle that can take it back to Kerbin.  Which ore have I just transferred?  Do I get to choose?  If so, how?  If not, why not?

Note that it also matters when the ore was mined.  Stuff mined before the contract was accepted shouldn't count, right?  Okay, how do you track that?  Even in the absolute simplest case of one craft with one ore tank that doesn't transfer anything to any other ships... ore is mined continuously over a time period, which means every ore molecule in my tank has a different timestamp on it.  How do I keep track of that?  Now take the cross-product of the time complexity of when-was-stuff-mined (when it can be mixed together), with where-was-stuff-mined (when it can be mixed together), and add the ability to transfer stuff around.

That's a serious can of worms. It's one of those things that sound simple on the surface but are actually pretty darn complicated when you dive into the details.

4 hours ago, StarStryder said:

It's not as simple as you're making out.

^ This.

2 hours ago, katateochi said:

You either have to track individual units of resource.

^ This.  And actually, it's even harder than kateteochi so rightly points out, because there aren't any "units" of ore.  It's a floating-point number, not an integer.  Ore doesn't come in whole units.

2 hours ago, katateochi said:

Or you need some kind of shipping manifest document

^ Or this.  And now you need a whole complex system of code to track these manifests and handle all the cases of transferring stuff around.

 

None of this is undoable.  Lots of good suggestions in this thread.  Lots of things that are possible.  But none of these are simple to implement; if the goal is to avoid behavior that seems odd or arbitrary from the player's perspective, then whatever you do, it's going to be really complicated to code because of all the complex edge cases.

"Really complicated" = "a whole bunch of work to code."  Then consider just what benefit you'd get for all that work.  It would be confined to only people who play career, and who happen take ore contracts, and who care a lot (or, indeed, even notice) about the wonky nature of the contracts.  I suspect that's a pretty small target audience.

So I think there's really just not enough bang for the buck, there, from a development perspective.  Or, at least, it's a low enough bang for the buck that there are other, more pressing features that would be a better use of the dev team's (very limited) time.

[Francois424]

Actually missions like this teaches people about Thrust-to-weight, ore conversion to refuel on the fly, heat/electricity management and that Ore is heavy... right @5thHorseman ? 

It's just a challenge mission in my book, it does not have to make sense...  Much like bringing tourists on the surface of Eve and bring them back safely to Kerbin. 
There's no real sense to it (any tourist would know by that time in the Space program that this is not often successful...  then again we have ppl signing-on for a one-way trip to Mars right now so who am I to argue).

It doesn't have to have all kinds of sides to it.  It's just a quick way to make money and maybe learn something if you haven't been playing KSP for 3 years.  
Quill18 told on a recent stream he had never played with ore before.  Now he tried it at least !

I just enjoy the Wonkiness of the contract system I guess.

Edited October 4, 2016 by Francois424

[Snark]

Hmm.

I've been trying to think of a way to accomplish the same gameplay effect (because I do like the idea of this kind of contract) without all the cans-of-worms that the ore-transfer thing implies.  Here's an idea:

Don't mine ore.  Mine "experimental elements".

It would work like this:

• The contract randomly generates a new resource type, tied uniquely and specifically to that contract.  Same as how waypoint names are randomly generated.  The name could just be alphanumeric gibberish (e.g. "Element XQ-73"), which is easy to code.  If you wanted to spend more time on it, you could get clever with the name generation (a la kerbal names) so that things like "Hyperflarpium" could happen.  But that's just eye candy, it doesn't really matter what the stuff is called, as long as it's unique to the particular contract).
• The newly-discovered element is only available on one particular celestial body.  The contract would say where.  e.g. "We need N units of wubblogen, which is available only on Minmus".
• Standard drills would be able to mine the element.  For the duration of the contract, the drills would get an extra button on their menu, "Harvest Foobarine"-- same deal as how testable parts temporarily get a "Run Test" button.
• You'd have to do some tinkering with the ore containers to make them able to store the resource (including "what happens if you've already got a load of exquibium and you then cancel the contract"), but that shouldn't be too hard to work out.  If necessary, make a special-purpose "experimental element" container that can hold any mixture of elements, so it just stores a list of "here are the element types I contain, and how much of each."

I think this gets around a lot of the problems with using ore.  You don't have to worry about when was it mined, because it's only mineable during the duration of the contract.  You don't have to worry about where was it mined (or the whole "mixing" thing), because it's only mineable on the specific body specified by the contract.  You don't have to worry about transferring between ships, because "get any of this resource" is all that matters, so players can use whatever ingenuity they like in terms of "how to get the stuff from A to B".  If they wanna transfer stuff around, more power to 'em.

It also makes for some handy gameplay elements.  Resource scanning, for example.  Make it so that not only does superhorkium exist only on Dres (which the contract tells you), but actually it's only in one particular biome on Dres (which the contract doesn't tell you-- you know it's on Dres, but you don't know where it might be or how widely it might be distributed).  So you either need to land a bunch of probes and hope you get lucky, or do resource scanning for it (same as with ore)-- again, more player choices.  And of course you can't scan for it until you accept the contract, because it doesn't exist until you accept the contract.

This feels workable to me from a development perspective, and also potentially a lot of fun from the player's.  Also, I think it's safe from exploiting-- not by trying to address a zillion edge cases, but because it's inherently built into the (simple) design.

Thoughts?

[Kerbart]

1 hour ago, Snark said:

I really don't think so.

many scenarios outlining complexities

Excellent analysis. It's indeed not an easy problem to solve right now, and the problem is indeed the contract, or rather, the subject of the contract.

Ore is, what we call in commerce, a commodity. Just like gasoline of brand x isn’t substantial different from brand y (it usually comes from the same refinery in the first place), ore mined at the Mun is not different from ore mined at Duna. Think of it; no one will ask for gasoline from Alaska or gasoline from Indonesia at the pump. It’s gasoline, after all.*

And that’s the issue with the contract; it requests for a commodity from a specific location to be delivered somewhere. That’s not how most commodity markets work. When I’m stockpiling gasoline or diesel I am not going to ask for a specific origin (if it can be traced, in the first place; it might even be a blend). I’m not telling my bank when requesting a mortgage that is has to be money earned in Alabama. 

Here's a wild-eyed solution that requires new parts (yay! new parts!) and new “resources”. Before rolling your eyes, bear with me:

• Core Samples: geological (kerbological? whatevs) samples drilled down from below the surface. Hence, not surface samples
• They require a drill, just like ore. But it's a core sample drill. Efficiency increases depending having engineer and scientist on site
• Core sample containers are just like ore containers but cannot be “contaminated;” you cannot add Minmus core samples to a container filled with Mun samples. You can transfer samples from one container to another; and an emptied container (which has become a Mun Sample Container after putting Mun samples in it) can be reset (cleaned) by a scientist. If you want to go hardcore the samples could be distinguished by biome, even.
• Returning core samples yield science (perhaps based on mass with a max-out value)
• A contract can ask for bring x kilograms of sample material y either to the KSC or to a station with an MPL for instance.

Obviously not easy to implement but it result in similar style contracts and introduce an exciting game mechanic with a believable story and all kinds of fun challenges.

Edit: seems like @Snark and I are thinking along the same lines...

 

* I’m sure car fanatics and carbohydrate aficionados will point out how wrong, wrong, wrong I am about this. But about 95% of the people really, really don’t care and cannot tell the difference.

Edited October 4, 2016 by Kerbart

[FleshJeb]

On 10/3/2016 at 8:45 AM, Kerbart said:

KSP not only teaches Obrital Mechanics, but Contract Law as well.

Finished with all the subclauses was I

But all I ever wanted to do was fly.

Drew up a new contract, and when I was done

All the lawyers were in orbit around the sun.

[Superfluous J]

5 hours ago, Francois424 said:

Actually missions like this teaches people about Thrust-to-weight, ore conversion to refuel on the fly, heat/electricity management and that Ore is heavy... right @5thHorseman ?

I don't know what you're talking about.

Because I've already blocked that memory.

[Archgeek]

I think there's an EasyMode solution for this involving contracts keeping a list of candidate fulfillers -- contract says get 17 tonnes of ore from Gilly to Duna => once contract's active, check each ship to recieve focus for being on Gilly and having 17+ tonnes of on-board ore => add the ship's craft ID to a datastructure belonging to the contract, and keep a tally of every mining craft on Gilly that does this, as we don't know which one the player will use.  => If a mining craft docks with something, those two crafts become one, with a new ID.  Update the contract list accordingly.  => when a craft on the contract undocks something, that makes a new craft.  Check if it has 17+ tonnes of ore and add it to the contract's list.  Remove the parent craft from the list if it no longer has enough ore, otherwise, the player could use either one. => As soon as something on the contract's craft list makes Duna orbit, make sure it still has 17+ tonnes of ore on board (no fair converting the supply to get there) and remove the craft from the list or award payout and deactivate the contract as appropriate.

[Trann]

23 hours ago, Francois424 said:

Actually missions like this teaches people about Thrust-to-weight, ore conversion to refuel on the fly, heat/electricity management and that Ore is heavy... right @5thHorseman ? 

Citation needed for, uh, science.

[Francois424]

20 minutes ago, Trann said:

Citation needed for, uh, science.

Check out 5th horseman (HMV)'s youtube series and tune to one of the latest episode about Ike/Duna.

His series are pretty good tho, so knock yourself out