Devnote Thursday: Tweaking and Turning Gears

[passinglurker]

5 minutes ago, Andem said:

Yeah, about USILS. Configurability. 'Nuff said. I can make it do whatever the hell I want!

That's all well and good for a mod but without a default experience that is considered fun by most of the community the feature would have to ship disabled by default, and that point why bother adding such a complex system to stock in the first place? No without a consensus on what strikes the balance between "doesn't dominate" and "can't be ignored" this shouldn't be added to stock there are enough rushed half baked features in this boat already.

[Andem]

6 minutes ago, passinglurker said:

That's all well and good for a mod but without a default experience that is considered fun by most of the community the feature would have to ship disabled by default, and that point why bother adding such a complex system to stock in the first place? No without a consensus on what strikes the balance between "doesn't dominate" and "can't be ignored" this shouldn't be added to stock there are enough rushed half baked features in this boat already.

You can't please everyone. That isn't the point, the point is making a system that fits well with stock mechanics. USILS does that quite well.

[passinglurker]

2 minutes ago, Andem said:

You can't please everyone. That isn't the point, the point is making a system that fits well with stock mechanics. USILS does that quite well.

Of course you can't please everyone but you need to please enough of them, and I don't think vanilla usils enjoys that sort of prevalence yet

[juanml82]

23 minutes ago, passinglurker said:

@Andem life support isn't so simple modders have yet to find a clear answer on how to implement it yet.

Classic ironman TAC style lethal life support is definitely not any more than niche minority of players cup of tea. like other hardcore "never gonna happen in stock" realism mods it consumes and dominates the game play so that designing around and micro managing it  all is an almost full time gig(this is kerbal space program not kerbal meal manager). so serious life support is flat out never going to happen (or riot)

Mean while there is more casual and forgiving nonlethal life support like usi and snacks they showed promise in theory but in practice they proved easy to game and ignore defeating the purpose of having life support(just lock the cabinet and open it at the destination and you have almost unlimited range). In other words they were too far in the other direction.

Any life support that revolves around the constant tick down of a resource like some sort of solar panel proof batteries simply doesn't seem like it will work any better than as a passing novelty because it's either to hard core for most or laughably ignorable.

For stock they'd have to think outside the box. Like having certain kerbal actions take a set amount of snacks ("want to fix a wheel? Ok that'll cost you 10 snacks" sort of deal), or forgetting actual life support entirely and just have the contract system push for mock "resupply" missions to create the illusion of playing with life support. And I doubt they'd want to commit to a plan like that without seeing some play testing first.

I think, if life support were introduced, it would need a far larger mechanic than adding a resource that gets depleted in time:

It should add the ability to order automated resupply missions that aren't run by the player, to reduce micromanagment, at least within Kerbin and its moons.

The VAB/SPH should also include some sort of standard travel time calculator. So if you want a round trip to Dres, there is a note, somewhere, that tells you that a typical round trip lasts x years, so you know how much you need to take, at least as a minimum. Of course, those calculations can end up rather wrong, depending on transfer windows and the actual ejection burn, but you should at least get a ball park figure.

I also feel it could be simplified to one or two resources. We can assume the kerbals have a 100% efficient air recycling system, so "life support" in only food. And maybe water if water ends up as a resource for other uses as well (say, cryogenic fuels)

But I also think that life support is more than consumables. Long term exposure to microgravity and radiation are also major life support issues, as well as, maybe, long periods of time in solitary.

18 minutes ago, Andem said:

Yeah, about USILS. Configurability. 'Nuff said. I can make it do whatever the hell I want!

My point was, cut the dead weight. In this discussion, the dead weight you pointed out was the 32bit version. If having a 32bit version i going to make further development impossible, GET RID OF IT! As of now, there isn't any reason too, there's still enough wiggle room for development. But at some point, the 32bit version will have to go. No reason to handicap yourself.

And what happens to customers with 32bit operating systems?

[NoMrBond]

Currently KSP is uses multiple individual textures per part

Part textures could be shared from global texture atlases.  The B9 pack does this for example, where textures serve for multiple models, especially applicable for closely related ones (i.e the FLT tanks) with layout controlled by UV mapping.

RAM load could be reduced while increasing fidelity by going from X models + 2X textures (the current), to X models + 2 textures, well not perfectly but the texture clutter could be significantly reduced.

Edited August 26, 2016 by NoMrBond

[Andem]

7 minutes ago, juanml82 said:

And what happens to customers with 32bit operating systems?

Well, let's see, they get shafted. They can't update to the latest version until they get a more up-to-date OS. It'll get to a point soon where the 32bit version is just a hinderance.

[legoclone09]

I think Snacks! is the best solution for LS. It adds ONE thing, and a travel time estimator could easily be thrown in. Something simple and relates to the Snack obsession with Kerbals.

 

EDIT: This makes it fit stock better as well! (courtesy of @-ctn-)

 

Edited August 26, 2016 by legoclone09

[passinglurker]

9 minutes ago, Andem said:

Well, let's see, they get shafted. They can't update to the latest version until they get a more up-to-date OS. It'll get to a point soon where the 32bit version is just a hinderance.

By the time it's a hindrance I'd think ksp would have reached its revenue generating conclusion and they'd have to move on to some sort of sequel to continue development any way. And even if you cut the ram hindrance of 32 bit you'd never be able to cut the ram hindrance of the current gen of consoles. 64bit != unlimited

Edited August 26, 2016 by passinglurker

[Andem]

2 minutes ago, passinglurker said:

By the time it's a hindrance I'd think ksp would have reached its revenue generating conclusion and they'd have to move on to some sort of sequel to continue development any way. And even if you cut the ram hindrance of 32 bit you'd never be able to cut the ram hindrance of the current gen of consoles. 64bit != unlimited

I know that 64bit isn't unlimited. I'm not a complete idiot ().  And yes, physical machines are a limit. But they are nowhere as limited as only 4gigs of RAM. My point still stands. Why handicap yourself? 

[passinglurker]

6 minutes ago, Andem said:

I know that 64bit isn't unlimited. I'm not a complete idiot ().  And yes, physical machines are a limit. But they are nowhere as limited as only 4gigs of RAM. My point still stands. Why handicap yourself? 

Other people who have asked that have produced unoptimized disappointments like battleborn and no man's sky

Edited August 26, 2016 by passinglurker
Edited for tact

[NoMrBond]

Imposing a 64-bit limitation would likely affect less than 2% of the playerbase (The biggest population of 32-bit OS installs is.... WindowsXP-32bit which is around 1.7%)

However if KSP used more than 4GB of RAM (by default) this would likely exclude about ~40% of the playerbase

Neither of those concerns are likely to amount to anything unless there are major changes (considering stock KSP currently uses ~2GB depending on renderer)

[Andem]

7 minutes ago, passinglurker said:

Other people who have asked that have produced unoptimized disappointments like battleborn and no man's sky

Well, I'm convinced that it's completely impossible. Looks like we're done here! Whoopdeedoo!

[Jarin]

6 hours ago, Alshain said:

I hope not.  Life support and KSP do not fit together, it adds tedium and no gameplay.

Were you against communication being added to stock as well? 

[richfiles]

9 hours ago, RoverDude said:

If your probe has control, you're fine.  The control locks only kick into play when you lose your connection (via occlusion or lack of signal strength).  By the way, I was able with the auto pilot to very creatively align to a node, even when occluded - was just a bit tricky   of course your best bet is to make sure you have signal and pre-align.

Nope, these are control locks, so your mods should be fine

Correct - if you have a good signal, your probes operate just like they do today.

Mods will be fine, I expect @NathanKell can provide more detail as he was the coding wizard that updated the control locks

It's a toggle in your game settings.  You can even change it in-game if you so desire   Tho you really are not going to need a large relay network other than to avoid occlusion issues, given Kerbin has a pretty nice built in DSN.

This is correct

Your mods will be fine, we are only locking the input controls.

This is SO awesome! I've been hoping for at least a limited control system like this! I'd have still loved a difficulty option that would have permitted full control lockout, but also the auto execution of pre-set maneuver nodes, made while still in signal range.

One question though... How feasible would it be to get a setting that allows Kerbin to toggle KSC as the only antenna link, vs the whole planet? I actually think it would be a fun incentive to set up a local coms network, not just fling a few coms satellites around far away bodies. I'd also be curious if the system could ever support ground based deployable antennas. Basically, KSC can be occluded, but if your vessel is both landed on Kerbin, and has an appropriate antenna... then it could expand your ground network coverage? Is the system flexible enough that such a thing could be modded? It'd give incentive to explore Kerbin as well! 

[0111narwhalz]

16 minutes ago, richfiles said:

One question though... How feasible would it be to get a setting that allows Kerbin to toggle KSC as the only antenna link, vs the whole planet? I actually think it would be a fun incentive to set up a local coms network, not just fling a few coms satellites around far away bodies. I'd also be curious if the system could ever support ground based deployable antennas. Basically, KSC can be occluded, but if your vessel is both landed on Kerbin, and has an appropriate antenna... then it could expand your ground network coverage? Is the system flexible enough that such a thing could be modded? It'd give incentive to explore Kerbin as well! 

I think this was asked a couple weeks ago, but we got a bit of a politician answer. The gist of it seemed affirmative, though.

[richfiles]

3 hours ago, Alshain said:

It's not the time, it's the RAM usage, and that isn't the only reason.

You do realize all the parts are located in the Gamedata/Squad/Parts, and that you technically CAN remove things you don't want to load. People have done it forever to make room for moar mods. With 64 bit KSP, memory isn't even a huge issue anymore, unless your computer just plain don't have the RAM. Me... I have 32 GB of RAM. I understand there are still some poor souls stuck with a measly 4. I don't know how they do it.

Seriously though, if your complaint is "I don't wanna consume precious RAM, even if I can turn it off"... Then turn it off AND don't waste RAM... remove any specific stock part files.

I can't believe you're making such a pointless deal over something that doesn't even exist yet. Your opinion is just that... an opinion, with no relevant basis in reality. You would not be affected by a stock LS system.

14 minutes ago, 0111narwhalz said:

I think this was asked a couple weeks ago, but we got a bit of a politician answer. The gist of it seemed affirmative, though.

I hope so. How awesome would the circumnavigation challenge be if you had to carry deployable antennas with you on the trip! 

Edited August 26, 2016 by richfiles

[Superfluous J]

15 minutes ago, 0111narwhalz said:

I think this was asked a couple weeks ago, but we got a bit of a politician answer. The gist of it seemed affirmative, though.

I remember the answer being "Yes, and here's how you do it." The "here's how you do it" was a bit technical and I for one didn't quite understand all of it, but just because I don't understand it doesn't mean it's a politician answer.

The idea was, IIRC, to set the "Kerbin" distance sphere to just more than the radius of Kerbin. Say, 601km. Then only things less than 1km off of sea level could talk dirctly to Kerbin. The rest would need a relay, which you as you RPer person could plop out next to the runway or wherever. Or, you could set it to be say 610km and then you could plop relay stations all over Kerbin to make your own global network like you'd have to do now in RemoteTech if you didn't do satellites.

[richfiles]

3 hours ago, lrd.Helmet said:

regarding life support, 
Honestly it would make me quit the game and probably ask for a refund. KSP is about orbital mechanics and getting somewhere (and engineering challenges), it ain't about managing the kerbals on board. 

You'd quit the game, before going into your settings and turning it off, which would fully disable it, as if it didn't exist... 
...
BWAHAHAHAHAHA!!! 

Edited August 26, 2016 by richfiles

[0111narwhalz]

1 minute ago, 5thHorseman said:

I remember the answer being "Yes, and here's how you do it." The "here's how you do it" was a bit technical and I for one didn't quite understand all of it, but just because I don't understand it doesn't mean it's a politician answer.

Perhaps "politician answer" is an icorrect choice of words. The reason I referred to it as such, however, is because the question asked those weeks ago was "will it be possible in stock." The answer did not address stock, nor did it specifically exclude the possiblity in stock, thus it did not answer the question.

[richfiles]

3 hours ago, Alshain said:

So you are saying they should drop 32-bit support?  That isn't happening.

It'll happen when stock grows to big to fit within the 4 GB limit... It will happen, someday.

3 hours ago, Alshain said:

That may be, but people have bought the game under the impression it will work for them on 32-bit systems and it's a bit late for the line to be drawn now.  Maybe KSP2 can be restricted to 64-bit and have all the parts they want, but the systems specs are set and you can't rip the carpet out from underneath people who have paid for the game.

...

I've already covered the issue with 32-bit, it's not going anywhere because Squad has already made a promise to people who have bought it.  There isn't enough wiggle room in 32-bit.  They have to pick and choose which parts to add, there is indeed more room right now, but I would like to see a whole host of other stuff before pointless life support modules.  So adding it would indeed take up space that shouldn't be wasted in the stock game.

Your game won't stop working on 32 bit... The new releases will just move on without you... and you'll be feature locked, with no new tedious and unnecessary stock add ons, just like you seem to like.

NO company can promise updates to infinity for old hardware and software. The minimum requirements gradually moves upward, and besides, you DO have v1.x in 32 bit... Squad has already delivered to you what they promised. Everything v1.+x is new development, and yes, it will someday require dropping 32 bit support.

The fact that Squad has always allowed you to copy the KSP app folder and launch it independently, means you will always have a working copy. When the day comes that 64 bit moves on, and 32 bit freezes, it's most likely that Steam or the store will offer both the locked 32 bit version and the continuing 64 bit developed version for download. In theory. There is honestly no obligation to continue supporting 32 bit! None! They provided a game that met the scope of their intended development goals with 1.x. They gave you what you bought!

Edited August 26, 2016 by richfiles

[Superfluous J]

12 minutes ago, 0111narwhalz said:

Perhaps "politician answer" is an icorrect choice of words. The reason I referred to it as such, however, is because the question asked those weeks ago was "will it be possible in stock." The answer did not address stock, nor did it specifically exclude the possiblity in stock, thus it did not answer the question.

Not to sound like a politician, but I suppose it depends on how you define "stock." Editing a config may be necessary, I suppose. It may even be likely. But you won't need to download a mod off of Curse or anything from what I can tell.

Though I bet modulemanager would make it easier, as it does all things. And I suppose none of these options would be available on consoles but that's just one more reason I'd never get this game on a console.

[NoMrBond]

Wasn't the answer basically 'Turn off the DSN and put an antenna at KSC'?

[Capt Snuggler]

Any chance we could get a peek at what @Porkjet is up to with the part revamp?

Edited August 26, 2016 by Capt Snuggler

[Wallygator]

12 hours ago, SQUAD said:

 

Probes will be limited to no throttle or full throttle, actions and events, SAS/RCS toggles, and the  autopilot settings that are allowed by their SAS level.  This means that maneuvering is still possible, but somewhat limited. Both probe cores and non-pilot crews without a connection to a control point will also lose the ability to add/edit/delete maneuver nodes.  The pre-plotted will remain, but without connectivity to a control point (or a pilot on board), it will not be possible to place new ones on the fly. We expect this provides appropriate incentives to maintain control without ‘bricking’ your existing probes, and also provides an incentive to use your pilots, even after probe cores are unlocked.  Bob was kind enough to share a shot of the updated user interface! http://i.imgur.com/l7sEIP3.png

I do not like this. Unless you add automatic maneuver and thrust execution by node as a thing.

Also, The continuance of the existing kerbal experience and role paradigm continues to thwart positive progress toward mimicking core elements of actual space exploration. 

However, thanks for working on everything else. Nice notes regardless. 

[richfiles]

52 minutes ago, Wallygator said:

I do not like this. Unless you add automatic maneuver and thrust execution by node as a thing.

It occurs to me... That it ought to be very possible for some modder to make exactly that. Just a simple Kerbnet integrated flight computer. Not anything as complex as MechJeb. Just an auto executor of maneuver nodes. You could have it start the burn at the node, or have it split the burn across the node, if it knows the burn time in advance. You could also have the option to burn xx seconds before the node. Finally, there would be an option to set the node accuracy. Does the node execute to within .2 m/S, or do we stop at only 2.5 m/s? Do you kill the burn if m/S remaining begins to rise passed 5 m/S error? All interesting options.

As an extension of that concept, you could also probably call for such a mod to allow the scheduling of action groups, either based on time or on an event or condition (set a specific time from now to trigger a group, trigger at periapsis, trigger if atmospheric pressure reaches a certain level, etc). That second bit would be a bit more complex, but possible as well. The main thing though, would be a mod that auto executes maneuver nodes.


On an unrelated note... Can KSP not simulate a frame or a few... whatever it takes to actually calculate maneuver node burn times (off a freshly staged engine, that is), and then discard the "simulated" frame of a simulation? We can revert a flight, so why can't we have the game freeze the simulation state on staging, run forward a frame or two... or whatever it actually does take, figure out the necessary thrust values to calculate burn times in maneuver nodes... And thus always have burn time there?