NathanKell

Never assume that you have the latest build. That's how people got in trouble in 1.0.5 despite a forum post telling them to update.

Modified the IPartSizeModifier again based on those points. New behavior: During ship bounds calculation it will be called once per renderer bounds now, passed the bounds size. You should report the delta from those bounds (if they are incorrect). In addition, when a ship is saved, it will be called once again, with the last stored base bounds where you should again report offset from those bounds. What remains is that unlike the other modifiers, it is passed data regarding the part's current state, and should report a delta from that state, rather than from prefab.

Currently nothing in our code will check size except for the engineer report or for determining launch constraints (same call). That call will pass 0 as the size input. That call will pass CURRENT as the regime. Oh, crap, also, when saving a Ship Construct we call it to record it in the protopartsnapshot. There, CURRENT is used but the ship size is passed as the size. The bounds reported by the bounding method, prior to PartSizeModifier, are based on the renderer bounds of the given renderer. There used to be multiple calls because there are multiple renderers for some parts. I'd like to say the renderer bounds are correct, but the inflatable heat shield has proved that that is not always the case with skinned meshrenderers. For this reason we support the new field Part.boundsMultiplier to correct for such problems.

Known issue. Waiting on someone fixing the collider.

Turns out the way IPartSizeModifier was used was...nuts. I have now fixed it for the next build. However that necessitates a change in what it should return. Since the bounds calculated for an object apart from that modifier are based on the renderer bounds, when the situation passed to GetModuleSize() is CURRENT, you should return 0, unless you want to specify a size different from your actual rendered size. STAGED and UNSTAGED should report as normal. Further, the size passed to the modifier will always be zero. Note this is a departure from the other modifiers' behavior, which report the prefab value and expect delta from the prefab.

Community Resource Pack. RealFuels requires it. @the_pazter And sure enough, looking at the modlist above, it's not there. CKAN will autoinstall it with RF, and RF comes with it in the zip, so...not sure how you're lacking it. But you are...

@the_pazter Then you either don't have CRP, or don't have the correct build of KSP (1028).

I'm seeing a metric shedload of exceptions in that log. I'd suggest starting clean. Just install RSS. Try that. Then install RO only, with only what CKAN prechecks, and try that. Then RP-0, only what's checked. Also, make sure the BuildID in your KSP folder says it's build 1028.

@Nucluer look just to the left of my posts.

Notgoogle notmaps is by far the best texture source.

Yep, at this point need a log.

@Maxsimal Sorry for the long delay here. Been a bit busy. First things first: great to hear, and feedback is always welcome! 1. Yep, targeted experiment/altitude/time or season would be good for early on, and all the satellite stuff needs replacing. 2. DMagic Orbital Science doesn't autoinstall in CKAN, it's merely suggested. We will have to consider how to handle mods that add more science. That said, Normal and even Moderate are IMO too easy on all counts. 3. Ironically, satellite avionics have the most options AFAIK: Early Controllable Core, Ranger I, Ranger III, Surveyor, and the 5t Satellite Bus. What areas are lacking for them? (And yes, they are expensive.) 4. Yep, known issue, engines need (and will get) a cost overhaul. 5. That's getting fixed, there's an issue on the repo about it. Regarding funding...I agree, we're looking at BROKE very eagerly. Can you post the log for the CTD you got?

@lextacy why would I remove a restriction form a 1.0.5 build of RF? That build of RF does not work in the slightest in 1.1. Thanks @Svm420 that about nails it.

@PedroLOLXD I suggest downloading CKAN and using that to install RSS. It should take care of things for you, if the installation instructions in the first post in this thread are confusing.

@OhioBob I haven't had a chance to touch bodyloader. It should be ok after a recompile, probably? And it remains up for grabs

It doesn't say penalties. It says fund loss. Or perhaps more clearly, costs. So it affects facilities, crew, failure, etc--any cost other than part cost.

Yeah, the simplification is that it's just the resource quantity, so you want to conceptualize the curve 'backwards' as it were, then convert to frontwards. Mathier folks could integrate from a time:thrust curve to get a prop_remaining : thrust curve.

@FreeThinker I hope you mean you return the delta between prefab mass and dry mass, and prefab cost and dry cost, or you will be implementing the interface incorrectly and leaving the user with more mass and cost than you wish. @pellinor it works just like the others: you report the delta from the prefab. If the prefab's bounds are 5,6,7 and the current object's bounds are 10,11,5 (and you caused that change) then you should report 5,5,-2.

Anybody actually tried the thrust curve stuff?

@DocUrlaub you're most welcome! FYI the issue there isn't so much that things aren't balanced in terms of costs and contracts (although they are), it's that RO drastically changes what parts even are. For example, the LR-1 is cloned to become a starting engine (while the original is left as a mid-tree RCSlike thruster); the LV-T45 is actually a midgame engine and the Mainsail a starting engine, etc. So having a tree where part placement hasn't been altered to comport with RO will lead to, hmm, how did I put it last? Running a marathon with a Ferrari and stilts.

Yep, even with no suggesteds you probably need to be running in OpenGL or Direct3D11 mode (both are explained in the RO thread's first post). @kerbalstar you nailed it

Fixed for next pre.

So, @Red Iron Crown just made a much more comprehensive version of the point I was trying to make. Kudos, +1, etc. Agree with every word. I do want to duck back and try to add a bit of a coda to the continuing impasse, though, because I don't think this has been covered sufficiently (or sufficiently explicitly); apologies if I am repeating. That point is this: modders don't have the same goals as each other, let alone their users. If you are trying to persuade a modder to do something on the basis of a shared goal (more enjoyment for the community) that is going to blow up in your face because, for many modders, that simply isn't their goal. Ferram, for example, is quite clear even in the name of his mod that FAR is a research project: it's "how to model aerodynamics in an environment without fixed geometry, and over gigantic ranges in freestream properties." Many modders mod because there's something the game lacks for them so they make it for them, and then put it out for general use on the supposition that others might like to use it. That's a far cry from the goal being "for the community to have a great mod." So if your argument is "but then the community won't have a great mod", it's not going to do much swaying. Here's how all this connects to what Red and I are saying above: you can try to make that a goal for a modder. Not by arguing or guilting her into it, but by making the community something to which she wants to give further enjoyment, something she wants to have continual access to her work even after she moves on. It will not always work. And if you try to make that happen where it's not--by descending into argument with the modder, rather than making a better community by example (and by exhortation, but mostly by example)--then, well, even modders who do share the goal of a happy, mod-saturated community will start to have second thoughts. So please do bear that in mind.

While I don't disagree with the General Modder Line (tm) which I think has been ably expounded (though I am sympathetic to the not-opposite-so-much-as-orthogonal points @soundnfury is making, and this is generally the approach I take towards my own mods), I'd like to proceed in a slightly different direction, and perhaps offer a more constructive approach. The best way to encourage open licenses is for you--yes, you, dear reader!--to yourself foster an open community. If you like a mod, help out where you can--and I don't even mean coding or anything big like that per se. But there will be tons of support requests on the thread: try to answer them. The dev may ask for feedback or testing: try to provide it. Someone might get a bit harsh: try to calm them down. Let's look at three effects: 1. The mod dev has an easier, happier experience, thus inducing her to keep working on the mod. 2. The mod dev thinks: "ah, this is a nice, open community, I ought to reflect that in my own behavior and my license."* And, "even if there are a few jerks, well, the community will deal with the fallout of that and less harm will come to me." 3. It makes it much more likely that potential successor-maintainers want to get involved (and do get involved), so if the mod dev does need to step away, there are people there to whom she can turn to continue work (if she hasn't already farmed some out!) This is how RO has managed to go through four main maintainers over its time, and rather seamlessly at that, with many of the same people working on it still, just being more or less active at times. "Be the change you want" is a hackneyed phrase, but particularly in this thread it cannot be overemphasized. If you want to persuade mod devs to behave a certain way, the best way is to model the behavior you want to see. Arguing with someone what they should do with the stuff they have already offered to you is...not usually a recipe for success. Instead of telling people how to behave, show them how. *Note: just because a license isn't open doesn't mean a modder isn't open to a successor taking over; so the main point of 2 is that it leads the mod dev to be open to successors carrying on her work, not necessarily having an open license per se.

1. Yes: because stock has obsoleted this mod, this mod is obsolete. 2. This mod is an MM patch that adds modules to parts, combined with a dll that hackily makes those parts be treated as fuel line targets. The suggested replacement is an MM patch that modifies a single cfg file to use new, non-hacky stock functionality. 3. If you want crossfeed to be toggleable, add ModuleToggleCrossfeed, just like decouplers have. That's what it's there for. No, I will not be reworking this for 1.1, since it was a dirty hack. :]