HarvesteR's First Contract Update Update #3

[cpast]

That is a good point. Because the update has come to include the (assumed) extra distance, it might even change the current distance collision meshes are rendered and brought into the game (if they even went out at all). We'll just have to wait and see, but I'm sure the devs have figured something out.

Source on it including extra distance?

[kujuman]

Source on it including extra distance?

I think "Because the update has come to include the (assumed) extra distance" means, "If extra physics distance were to be included at some point in KSP development, this update would be a good choice to do so as it would improve gameplay in a meaningful way" rather than "extra distance confirmed for KSP .24".

[tjsnh]

Depending how bad the diminishing returns are, looks like every rocket stage will now get a probe core and a dozen radial 'chutes ....

[KerbMav]

If the refund system really favors ("distance-dependantly") KSC for recovery, than it feels like it was implemented mainly for space plane users and for the little extra when returning anything to the surface.

[Alshain]

If the refund system really favors ("distance-dependantly") KSC for recovery, than it feels like it was implemented mainly for space plane users and for the little extra when returning anything to the surface.

Rockets can return to KSC just as easy as planes.

[KerbMav]

I was talking about intention in game design.

No one stops players from landing their interplanetary beheamoths with tons of parachutes.

[Bilfr3d]

Source on it including extra distance?

No source. Hence why I said "assumed" in brackets. Because if the distance was still 2.5km, people would run into some troubles recovering the parts. It would seem pretty impossible to do it (without including probe cores) if the distance was still 2.5km. I'm starting to think there might be a slider to choose at what distance the debris automatically gets deleted (up to the point to stop it all together) to help players of different experience. The one thing that I would think would have to happen, is that the collision mesh of kerbin would have to be rendered at the same distance as the selected debris distance, and once the debris hits the ground, it cannot be deleted, or is recovered automatically, so that if you do go past your set distance it doesn't get deleted. As I said, I'm sure the devs have figured something out, and we're just going to have to wait to see what they've done.

[BudgetHedgehog]

<snip>

Sorry to disappoint you, but there's nothing of the sort in 0.24. Things that are at a higher atmo density of 0.01 (roughly 22km on Kerbin) and on-rails will still be deleted, regardless of probe cores or not - just like they are now.

[cpast]

No source. Hence why I said "assumed" in brackets. Because if the distance was still 2.5km, people would run into some troubles recovering the parts. It would seem pretty impossible to do it (without including probe cores) if the distance was still 2.5km.

That's exactly what seems to be the case (and probe cores are irrelevant to that, BTW - all ships on rails are automatically removed when atmospheric pressure goes above 0.01 atm, whether or not they're debris - rails can't simulate drag, and below that point drag is important enough that Squad decided removing the ship is better then having it continue ignoring drag). You likely won't be able to slap parachutes on spent stages to recover them.

[Bilfr3d]

Sorry to disappoint you, but there's nothing of the sort in 0.24. Things that are at a higher atmo density of 0.01 (roughly 22km on Kerbin) and on-rails will still be deleted, regardless of probe cores or not - just like they are now.

I never said that the slider thing I suggested WOULD be included. It was just a thought of how it COULD be done. And I never actually knew about the 0.01 on rails deleting But I have made a probe plane attached to another controlled plane before. I detached the probe, it went flying away, after 2.5km it was still there, flying away. So I don't really know about he probe one.

That's exactly what seems to be the case (and probe cores are irrelevant to that, BTW - all ships on rails are automatically removed when atmospheric pressure goes above 0.01 atm, whether or not they're debris - rails can't simulate drag, and below that point drag is important enough that Squad decided removing the ship is better then having it continue ignoring drag). You likely won't be able to slap parachutes on spent stages to recover them.

Goddamn Squad. They would have to increase the on-rails distance then. As I said, possibly it could be done using a slider for players to choose their distance based on both their computers performance and their own experience in the game. you would also think that increasing the distance of on-rails could possibly slow the game down, as the spent stages would still be rendering on rails, which could slow the game down if you have a massive ship, with equally massive stages. For the third time, I'm sure the devs have figured something out, and we'll just have to wait to see what they've done. Although I would like to see what they've done to make it possible to recover stages. Maybe we're all oversighting this, and they haven't changed anything to the on-rails distances, etc.

[cpast]

Goddamn Squad. They would have to increase the on-rails distance then. ...snip... For the third time, I'm sure the devs have figured something out, and we'll just have to wait to see what they've done. Although I would like to see what they've done to make it possible to recover stages.

The answer would appear to be "absolutely nothing"; why would they have to do anything different? So far, it seems like if you want to recover spent stages without a mod, you have to basically get their periapsis above 22km (which, for on-rails craft, is a stable orbit), take them with you (hence SSTOs having a purpose), or kick your main craft's apoapsis out far enough that you have time to ride a spent stage to the ground before the main craft needs your attention.

Shifting from what they've done to purely my opinion: Recovery *should* be hard; the issue is that stock KSP makes it very, very easy to safely parachute an empty stage to the ground. You can put as many radial parachutes as you want on something, for not much of a mass penalty. If recovery didn't require taking things into orbit, it would be way too easy to make a craft fully recoverable, removing any benefit to careful mission planning minimizing the amount of stuff you lose.

They could have done something to change it, but we haven't heard anything even *suggesting* that recovery of dropped stages would be possible; to the contrary, HarvesteR mentioned (when describing part test contracts) that using experimental SRBs for non-contract missions would require extra planning to make sure they could be recovered; if dropped stages could be recovered, there would be no need for this extra planning.

Edited July 14, 2014 by cpast

[stoani96]

Just a quick note to that "every thing further than 2.5km away from the focused craft and below 20km in atmosphere(at Kerbin)"-thing:

Squad! That would be soooo easy to (quick-)fix!

before this craft is deleted, check if it would have sufficient chutes for a save landing (under 10m/s). that is just math! i dont know the formulars right now, but you guys "invented" them. something with mass times cd instead of area times cd, not?

However, if the chutes would be sufficient the craft is just "beamed" to the surface at its current coordinates. i know that is more than wrong, but a very quick quickfix! And i would be totaly fine with that, because it allows me to throw of boosters or entire stages with chutes and recover them (which will, i think/hope make even more sense with that update!). and further simulation of that craft (e.g. if it is beamed on a steep slope and is about to collapse) can happen (and will heappen i think, because of that 2.5km thing) if it is in "range".

So please, squad, do something for your money and work on this game! KSP is a great game, with a lot of potential, but it is the slowest developing game(or IT project in common?) i have ever seen!

I dont know what is going wrong in your team, but something definitely does go wrong!

A basic contract system is just a matter of hours. you are working with unity, right? So add some scripts that check progress and, well, thats it! okay, procedural contracts is also some work (another few hours), but all in all that is done in less than two days....

And budget was more or less already implemented, wasn't it? every part already has a cost variable. add them and show it at an new gui... wow, great work!

So, recap that: on the first day you implement contracts in general and give some stuff to test it. on the second day you implement procedural contracts and the tester tests the general implementation of contracts. and on the third day you finish work with budget and testing the procedural generation.

And what did you in the, in dont know, last six month?? (oh! i know: pre-preparing for vacation, preparing for vacation, vacation, vacation, coming back from vacation, oh, forgot anohter vacation, finaly got back from vacation, pre-preparing for work, preparing for going back to work, going back to work and finally work)

[BudgetHedgehog]

<snip>

3 things:

1, if it was "sooooo easy to fix", they probably would've tackled it by now. You think they haven't thought of your idea already?

2, KSP is actually progressing at a pretty normal pace. The only reason it appears long is because we're allowed early access to it. This is actually how fast games are usually made, especially ones with a sandbox the size of a solar system

3, you pretty obviously have no idea how programming works.

[cpast]

Just a quick note to that "every thing further than 2.5km away from the focused craft and below 20km in atmosphere(at Kerbin)"-thing:

Squad! That would be soooo easy to (quick-)fix!

-snip about recovery of spent stages-

Again: Why should spent stage recovery be possible? From a game design perspective, it removes much of the point of minimizing staging and dropped parts. From a realism perspective, rocket recovery via parachute is complicated and difficult; the only spent stages ever recovered via parachute were the Shuttle SRB, and it required the largest parachutes ever made up to that time.

So please, squad, do something for your money and work on this game! KSP is a great game, with a lot of potential, but it is the slowest developing game(or IT project in common?) i have ever seen!

I dont know what is going wrong in your team, but something definitely does go wrong!

-snip-

I'm assuming from this comment that you're a professional game developer, well-versed in the details and pitfalls, as well as how design processes work? The alternative is that you're someone who has never even tried to make a serious game, who is convinced that crude half-baked implementations somehow are acceptable in games being sold as commercial products.

[stoani96]

3 things:

1, if it was "sooooo easy to fix", they probably would've tackled it by now. You think they haven't thought of your idea already?

2, KSP is actually progressing at a pretty normal pace. The only reason it appears long is because we're allowed early access to it. This is actually how fast games are usually made, especially ones with a sandbox the size of a solar system

3, you pretty obviously have no idea how programming works.

1.thats the problem with squad in general!

2.define "normal" it is a small game with a small team and the "main part" is already done (more or less): the engine

3. no? NO??!?? im a (hobby) programmer myself and know how its works (at least for me: doing some code, test it right away or doing it in small paces to test these small pieces and fix them right away!)!

What is wrong with my assumptions? tell me, mister iknoweverythingaboutprogramming, im ready learn something new

(note: the last of us, a very big game with a very workintensive genre, took about 4 years.... a large game with a large team. ksp: small game, small team and also about 3 or 4 years, not? (at least 2, im pretty sure!) but they wont be finished after 4 years! im also pretty sure about that (based on current dev speed)

[smart013]

3, you pretty obviously have no idea how programming works.

This. And this arrogant knowitall attitude based on beeing clueless about the job at hand is pretty disgusting i must say.

[cpast]

3. no? NO??!?? im a (hobby) programmer myself and know how its works (at least for me: doing some code, test it right away or doing it in small paces to test these small pieces and fix them right away!)!

What is wrong with my assumptions? tell me, mister iknoweverythingaboutprogramming, im ready learn something new

Right. Sorry. Clearly, hobby programmers such as yourself know how it works to release a product that you expect people to pay you actual money for, which is designed to be fun for a large audience, and is fairly big in scale. Creating things designed for yourself and maybe a few friends is comparable to a game expected to be of sufficient quality that a large number of people will pay you $27 for it.

[stoani96]

Again: Why should spent stage recovery be possible? From a game design perspective, it removes much of the point of minimizing staging and dropped parts. From a realism perspective, rocket recovery via parachute is complicated and difficult; the only spent stages ever recovered via parachute were the Shuttle SRB, and it required the largest parachutes ever made up to that time.

Im pretty sure sooner or later it will be possible in the game, caus it isnt pretty if this parts just disappear. thats my oppinion, i dont like that. and if it can crush into the planet it can also land. and i never said, i want back all the money! if i just get 10% of the eniges cost because im "recyling" it into cans or so, im fine with that. why? cause its "more realistic" and makes the game more DIVERSE

[stoani96]

Right. Sorry. Clearly, hobby programmers such as yourself know how it works to release a product that you expect people to pay you actual money for, which is designed to be fun for a large audience, and is fairly big in scale. Creating things designed for yourself and maybe a few friends is comparable to a game expected to be of sufficient quality that a large number of people will pay you $27 for it.

You, sir, just hit the nail on its head! You say, squad is doing all this, because they want to release a game that is worth its 27 dollars? well they never accomplished that!! Cause if they really wanted, they would either release fast paced and give many bugfixes away, or take time and release it totally bugfree. but they take their time aaand let it out more than buggy. and to be honest, it does not make sense to kill all the bugs, cause the game will have so or so a lot of updates... but okay, if squad wants to do that....

so please do not note squad and sufficient quality that a large number of people will pay for in the same context

EDIT: and please tell me what is sooo diffcult at implementing a basic contract system? you're acting like you know everything! never criticise without arguments

Edited July 14, 2014 by stoani96

[cpast]

Im pretty sure sooner or later it will be possible in the game, caus it isnt pretty if this parts just disappear. thats my oppinion, i dont like that. and if it can crush into the planet it can also land. and i never said, i want back all the money! if i just get 10% of the eniges cost because im "recyling" it into cans or so, im fine with that. why? cause its "more realistic" and makes the game more DIVERSE

KSP recovery is not remotely realistic (because slapping moar parachutes on works), so that isn't a good argument (again - chute-based recovery of spent rocket stages has been done for a total of one design, ever). Now, you can make gameplay arguments (which, IMO, are generally better than realism arguments anyway), at which point it's more of an opinion thing. Personally, I feel that it's good that you have to expend serious effort to recover stages, and you lose them otherwise. Having a 10% recovery percentage for stages which are auto-recovered by a proposed parachute count mechanism would also discourage unnecessary part dropping, but it's much more complicated to do that than to keep the current "anything in >0.01 atm on rails is removed" (which applies to everything in the game). However, again, that's a matter of personal taste.

You, sir, just hit the nail on its head! You say, squad is doing all this, because they want to release a game that is worth its 27 dollars? well they never accomplished that!! -snip-

so please do not note squad and sufficient quality that a large number of people will pay for in the same context

I, and many, many others, disagree. KSP has been a top-selling game on Steam; while Steam sales numbers aren't public, it already has convinced a large number of people to pay for it.

EDIT: and please tell me what is sooo diffcult at implementing a basic contract system? you're acting like you know everything! never criticise without arguments

1) What sorts of contracts do we offer? How should that work in general?

2) What are the kinds of failure conditions on contracts?

3) Well, for successes, how do we measure "success"? On achieving it? On recovery?

4) How should the rest of the game handle this?

5) Are contracts scripted, or procedural? What unlock mechanisms are there?

6) For budget - how does that work with contracts? Advances? Budget per launch? Do launches have to be associated with contracts, then?

7) What happens in the 90 corner cases we discovered while starting to implement things?

8) Do any specific contract types we want to offer require things out of the rest of the game?

9) How do we balance things?

10) Are contracts something that is necessary, or something that is optional?

11-15) *debug*

16-20) *polish*

The better question is, what do you expect out of a "simple" contract system? A proof-of-concept type thing, where you have 1 kind of contract which is SOI change, no intermediate goals, and no integration with everything else?

[The Destroyer]

Lets see...

First of all, you need to get an idea of how it's gonna work, what will fit in with the game, actually give thought of 'how is contracts going to work?" Then, you need to figure out how to code it in, how it will be generated, what types of contracts theres gonna be. Is it gonna be landings and orbiting? Testing? Grand tours? Of course, each contract also has a silly discription too!

And then of course, during coding, you may be able to whip up a simple coding system fast, but what about affecting other parts of the game?

The poster above me completley summed it up beautifully.

[nanowinner]

Obvious troll is obvious....or is he really not so bright?

[stoani96]

KSP recovery is not remotely realistic (because slapping moar parachutes on works), so that isn't a good argument (again - chute-based recovery of spent rocket stages has been done for a total of one design, ever). Now, you can make gameplay arguments (which, IMO, are generally better than realism arguments anyway), at which point it's more of an opinion thing. Personally, I feel that it's good that you have to expend serious effort to recover stages, and you lose them otherwise. Having a 10% recovery percentage for stages which are auto-recovered by a proposed parachute count mechanism would also discourage unnecessary part dropping, but it's much more complicated to do that than to keep the current "anything in >0.01 atm on rails is removed" (which applies to everything in the game). However, again, that's a matter of personal taste.

I, and many, many others, disagree. KSP has been a top-selling game on Steam; while Steam sales numbers aren't public, it already has convinced a large number of people to pay for it.

1) What sorts of contracts do we offer? How should that work in general?

2) What are the kinds of failure conditions on contracts?

3) Well, for successes, how do we measure "success"? On achieving it? On recovery?

4) How should the rest of the game handle this?

5) Are contracts scripted, or procedural? What unlock mechanisms are there?

6) For budget - how does that work with contracts? Advances? Budget per launch? Do launches have to be associated with contracts, then?

7) What happens in the 90 corner cases we discovered while starting to implement things?

8) Do any specific contract types we want to offer require things out of the rest of the game?

9) How do we balance things?

10) Are contracts something that is necessary, or something that is optional?

11-15) *debug*

16-20) *polish*

The better question is, what do you expect out of a "simple" contract system? A proof-of-concept type thing, where you have 1 kind of contract which is SOI change, no intermediate goals, and no integration with everything else?

okay, the recovery thing is a very discussable theme, and i think everyone has another opinion to this. i, personaly, would be better with such a quickfix thing than the current way it is done

ksp itself is not the problem. i myself LOVE it! the problem is squad. i did not know how unable they are!

the game itself, its POTENTIAL is worth a lot

1) brainstorm for an hour, or for all i care one day

2) kidding?? (for all i care one day)

3) again: kidding?

4) wat?

5) procedural, thats clear! and: kidding??

6) an argument! but: if you are thinkin really slow you will have a solution in 3 days ;D

7) beeing a good programmer avoids this. oh sry i mean good planning(!) does this

8) wat?

9) kidding?

10) kidding?!?

a contract system is that what i say: a contract system! and all it requires is thinking about it(planning) (for all i care take 4 weeks for that! ), draw some guis and write the scripts behind all that.

if all that is running really slowy after at lest 6 weeks (8 for all i care) it is totally finished.

i think the workflow is the problem. if i program something i test nearly all critical things on the way and not everything at the end. cause than you get hundreds of versions. and that makes testing even slower.

solution: moar programmarrs! ;D

btw: is only harvester programming?

[stoani96]

Obvious troll is obvious....or is he really not so bright?

please! enlighten me and make me brighter by saying me what exactly is your problem.

mine, btw., is squad

[BudgetHedgehog]

btw: is only harvester programming?

Apparently so. They should hire you because you seem to know a lot more about the game they're developing than they do and with you in charge, it sounds like KSP 1.0 will be ready before the end of the year. I'm completely serious - post on the Development and Suggestions board with all this and then just wait for the job offer. I have no doubt it'd come because you've demonstrated that you're clearly better than the entirety of Squad. I mean, after all, who could provide counterpoints to such persuasive arguments as "kidding?!?", right?