Jim DiGriz

I'm using build 23 in an RP0/RSS/RO install and finding that I can't unlock already in-process tech research unless I have enough science for it. So I've got 7.8 science and Supersonic flight is in the queue and costs 1 science so I can 'unlock it again' and i get the "it will unlock in infinity days NaN" message and it unlocks (science stays at 7.8), but I also have Early Avionics in the queue which costs 10 science and it just gives me "Not enough science to research this node". That blocks me from being able to access and queue up Basic Avionics which I could get for 5 (and blocks me from getting the upgrade points now as opposed to later). I can give you logs and such, but I don't think there's anything too relevant in there, and this seems fairly straightforwards.

You might want to hook it up to ModuleManager so that folks could feed in arbitrary sized custom arrays to either regular or physics warp via a cfg patch? You'd probably want to disclaim any implied warranties of merchantability or fitness for any particular purpose, but why not sell rope to the people who want it?

heck, yeah.

Fix: https://github.com/MuMech/MechJeb2/pull/823

MechJeb is vastly more difficult than stock once you start noticing things you don't like and start patching the code. Its also educational to try to re-implement the maneuvers in mechjeb in kOS or kRPC.

e-dog did log in a week ago, so its possible he'll be back when real life allows. what might be more useful would be a "proc fairings redux/continued/community/kortexm" ckan config uploaded to ckan in the interim, rather than splitting the forum thread.

FWIW, I wound up doing this: lock launch_heading to heading(launch_dir,launch_pitch). lock steering to R(launch_heading:pitch, launch_heading:yaw, 180). Most of the examples that showed doing a heading() * R() or vice versa never worked for me... i'm not certain any more now why i used heading() and didn't use launch_dir and launch_pitch directly into R, but i haven't looked at this code for a couple of weeks...

That's mostly what I said? I just replaced "free" with only enough costs to offset the launch some to keep on treading water. I've been playing RP0 quite a bit lately and this is the way the "Sounding Rocket Medium/High" contracts typically work. They pay off a few $1000s and that offsets the cost of the $6-10k launch vehicle some and that's about it. They're useless for doing multiple launches and gaining any funds. That's sort of the way I'd see it working with contracts for second bases. The first base contact might give you $100k-$1M of payout since it represents novel progression but anything after that would be $10k kind of range for each base / station.

OMG thank you so much, this is the kind of contract mod that I've been hoping someone would write. As far as randomization goes, I'd really like to see dramatically less randomization. When I'd like to see for bases and stations is that as soon as you unlock the prereqs (achieve orbit/land around the body or whatever) then you get the initial base/station contract. The initial contract should have a high payout. Then you should immediately get a contract to build another base/station but the costs should adjust downwards to only offset the costs of launching a new station. Resupply and crew rotation missions should similarly always be offered but have low payoffs that mostly compensate for mission costs. It should be pretty "grindy" to continually build bases/stations and supply / rotate them in order to try to get ahead in cash -- but if you want to build eight stations around Kerbin for your own reasons, then you should be able to get enough cash to compensate for the launches. Ideally I'd like to turn the randomization in these contract rewards down to zero as well, I really find contract reward randomization pointless and I never pay attention to it and it just annoys me that its there and someone thought it added to gameplay. Where I think there should be randomization is over stuff like the something-broke-on-a-station contracts. Those could be special events, with randomization over the severity and payoff, etc. Its possible that ISRU return contracts and such should also be randomized. Maybe only allow a few ISRU contracts total at a time, randomize the bodies and the payouts. If base-building is kind of nerf'd the way I just described so that once you've built a collection of bases and stations around the bodies, then you still should have a way to get ahead, and it makes sense to structure that around having a space-economy.

Should probably have better integration with RemoteTech. It looks like when the vessel is out of range with RT the science is still automatically scraped, even though normally it wouldn't be possible to do a science experiment when out of contact.

@PART[Biomatic]:Final { %TechRequired = start %cost = 0 %entryCost = 0 } That MM config can be placed into any BiomaticHack.cfg file (or whatever you'd like to call it) in the GameData folder and it'll move the Biomatic part to the start node in the tech tree and make it costless -- once 'purchased' it'll unlock the GUI for all command modules... Seems to be working fine so far...

They provide a service to me as a centralized way to find games, purchase games, manage games, and install games across multiple platforms. They provide a service to "up and coming companies" to be able to advertise on steam, to be able to entirely avoid setting up their own software distribution and downloading service and they avoid the barrier of users having to manage another login on another service just to download bits and run a game. The experience with UBIsoft games purchased from Steam, for example, is annoying because it just installs their own client that you have to run to manage games, which they had to build and is arguably inferior to steam (or at least it gives me two sets of orthogonal things to be aggrivated about instead of me only having to learn about steam's idiosyncrasies). Steam does take a 'cut' but it seems proportional to the service they're operating and so far they don't appear to be abusing their status. As I posted before they also have extremely high bandwidth costs and need to scale out to handle major releases of popular games, which will simply not happen on a not-for-profit basis. So far it really isn't better for us both. If they start abusing their position, then I'd argue for a competitor and I'd expect one to eventually emerge. And really its much better for me, and much better for small game companies -- based on the number of early-access indie titles in my library that I otherwise would never have found (*cough* KSP *cough*) I'd say that its working pretty decent for everyone right now, other than people who get upset about a bit of profit motive.

Also makes it really easy to sync my library of games between my laptop and my triple-boot linux/mac/windows desktop... Of course there's maybe about 5 games that i really play on different platforms, but its still a convenient package manager for games... If someone produced an open source package manager for games and it got traction like Steam has and had the games I want, then I'd use it instead. But the bandwidth of requirements of handling an XCOM or Fallout launch couldn't be handled by a not-for-profit approach (the way that rubygems.org is run by donations would never work).

"properties" => "updates" => "only update the game when i launch it" then don't use steam to launch it. create a shortcut or command alias or whatever you'd have to do anyway if you didn't install it via steam. use steam to update the game, don't use it to launch the game.

Or click the button so that steam does not auto-update it.

Yeah, I just noticed that Earth has become Kerbin, looks like Kopernicus may be very busted...

unfortunately: EDIT: KSP.log: https://gist.githubusercontent.com/anonymous/31dc8c0425c12c6216b3147f1d95e49d/raw/1bf7f82ec70c2cc8894d44016b7cdd6b2a325309/KSP.log Also if it helps, I'm not remotely where I'd be flying by Venus, and I'm doing Moon impactor contracts, so that was definitely not an accepted contract. I think I remember seeing it in my available list though.

Since 1.1.0 it has been proper MOI calc with smeared out MOIs for each part, not just the point-mass approximation. With this fix it should actually be usable (I believe it was off by a 90 degree rotation in 1.1.0 to 1.1.2)

Honestly there's no useful takeaway from your rant. If you want a challenge and want to explore other words, install Realism Overhaul with Kscale64 and Outer Planets Mod to start with. You'll need all the delta-V then. There will be other planets to explore that are way far out. Install TAC LS so that if you don't plan your exceedingly long missions correctly that there are dire consequences. Install the near future mod that nerfs your solar panels to increase the challenge of operating that far out. Install Remote Tech to make probes that far out more challenging. Any number of other ways to come up with a challenge.

I did not. I don't think I've ever actually done one because they seemed overly fussy and I didn't see the point so I turned them off... Lol...

@ferram4 is there any possibility that the busted voxelization from CLS could have been causing the negative torque issues? I picked up the CLS update and now kOS is suddenly remarkably more stable.

If you don't think its a FAR issue, I'll take a stab at the suggested kOS fixes in that reddit thread or whatever suggestions you can throw out once I get some time.

@ferram4 There's a thread on reddit r/kos about an interaction between FAR and kOS producing sharply negative torque amounts from the torque APIs: https://www.reddit.com/r/Kos/comments/4mocue/bad_cooked_steering_with_far/ I've definitely seen this as well (I'm not the OP there) and its pretty easy to reproduce on launches using kOS. Unfortunately, I have to focus on packing for a trip today, so I can't afford to be more helpful right now.

I've seen weird things with variable scoping and 'lock'. If you remove the `lock heading` and just set the heading in the loop does it work? Alternatively, if you declare mysteer as either global or local explicitly does that fix it? EDIT: and yeah, one obvious symptom of this would be that the controls in the bottom right wouldn't be trying to respond at all.

That sounds like you're trying to generate too large of an angle-of-attack and the aerodynamics is not letting you. Once you hit a high enough velocity in thick enough atmosphere, with a properly shaped dart-like rocket you'll wind up getting forced into a roughly zero AoA gravity turn anyway. If you haven't pitched over far enough at that point you'll tend to go straight up, if you've pitched over way too far you can find your rocket turning over and starting to head down with nothing that you can do about it. But then once you clear the think part of the atmosphere you regain control and it pitches over. Generally what works better is to pitch over 10-15 degrees to initiate a turn, then wait for your AoA to get large and then get small again, then lock your steering to your surface velocity vector.