IronGremlin

I'm sorry, we seem to be suffering from a rather profound miscommunication. I don't think it's really necessary to pick sticky case examples - As you made mention of earlier, those are bound to change soon as kOs grows - I mean literally, there are people who don't know what a data object IS. The idea that you could do something like KERBIN:POSITION at all is foreign to people who are new to this stuff. They don't understand what the colons are representing there, conceptually, or that it's the same basic idea as ETA:NODE. I don't mean tutorials on all data objects, I mean A tutorial on the concept of objects that have sub-properties. Let people refer to documentation to work out sticky particulars.

@Steve Madding: Just write irrelevant code for your tutorial. Something that prints ETA to app in an unending loop, etc. It doesn't have to do something useful to teach useful concepts.

@Steve Madding: Your tutorial is awesome! I love it, and it's wonderful, and I learned some things that I didn't know even though I've been writing functional scripts for a while now. I would request just one tiny addition: Find some excuse to go over a more complicated data structure, like body, vessel, or engine... Just something to give the reader a handle on how to access sub properties of an object - I know the code in the tutorial shows this already, but it might not click with some readers without being super blatant. Thanks for the great work!

Yes. What you could do, however, is make an executable shell script to extract all of the mods to the proper places in the proper order. It would be tragically easy for a knowledgeable person to do this in OSX/Linux, not sure about Windows, although I assume it would be simple enough. Assuming you used like, a real programing language, it'd probably get easier to maintain and do cross OS stuff. I was toying around with this a few weeks ago but got a brand new job before I got very far - good for me, bad for side projects. If you really want to see something of that sort, you could probably learn to make it yourself - it'd be a great way to learn basic scripting and/or programming skills, if you're into that sort of thing.

If your dead set on not including any executable code for reference, maybe you could at least link to a description of what "objects" are, and the syntax surrounding them? Calling out the syntax examples as syntax examples may also help people who are new to programming - it's easy to forget once you've spent enough time learning different languages, but typical code documentation practices are super unintuitive.

That's a fantastic point, but honestly I feel that the inaccuracies in the default data are at least a known quantity. I'd be more worried about how it doesn't calculate until you 'throttle up.' I feel that kOS suffers from a bit of an identity crisis; it's split between quick and dirty functional scripting, and trying to satisfy a small group of enthusiasts with prior coding experience that want a more fully featured language. I'm not sure how much of the 'quick and dirty' part comes from a desire to implement proof of concept ideas prior to fleshing out the particulars, and how much comes from trying to make basic script goals approachable. More on point: I'd lean towards saving this until functions are implemented, and making it a kind of ' included library feature' rather than a core language feature. It's one of those things that is a piece of code that every user will end up using at once point or another, so it seems silly not to include it at all. Including some basic importable scripts with things like a burn time calculator or a warp to time stamp script would save new players some headache and provide neat bits of learning material. Anyway, just some thoughts.

How do you feel about allowing KoS to call the estimated burn time value on a maneuver node? I've been on the fence about whether or not it seems like a consistent KoS feature myself, but am curious to know your take.

That can happen when a procedural part clips into a decoupler. Try opening up your craft in the VAB and re-attaching the parts. This happens to me semi frequently, the craft launches fine the first launch, then any subsequent launches require that I reload the craft in the VAB and re-attach all the fuel tanks. It happens most often if I have procedural tanks next to a procedural fairing base, but that hasn't been tested super thoroughly so it could just be confirmation bias.

NathanKell, would it be possible to get an inventory of parts used by the RftS Engines? I have an under-powered computer, and run into severe RAM utilization / performance issues while attempting to play my RPL/RO install - I've attempted manually curating all the various part mods, but I'm really running into trouble trying to figure out which parts are which, especially in the FASA pack. Having an inventory of 'this engine requires this part from this mod' would make this much easier.

Seconded! Also, this is a GNU license, so there are no restrictions on redistribution... If anyone has a copy of this, please upload it to Curse for the sake of posterity.

Nevermind. =/

Hey, no worries - Now that I figured it out I'm having a great time writing all kinds of fun scripts. Thanks so much for all the hard work on an awesomely fun mod! Just to check - This also kills aerodynamic control surfaces in absence of reaction wheels. They don't turn off, mind you, they just don't quite work - near as I can figure it provides some sort of weird attempt to hold current heading, but not real well. Once the reaction wheels exist, the aerodynamic control surfaces behave normally. Just wanted to be sure we're talking about the same behavior.

So this took me all day to figure out - not sure if this is a feature or a bug, but it sure as hell isn't documented... If you have no reaction wheels anywhere on your craft, 'lock steering to y' will instead try to maintain current vessel heading. Adding a part with reaction wheels restores normal function. Also, ship:control seems to be unaffected. Might want to post that somewhere where all the RSS/RO folks can find it.

So, sorry to play armchair coder, but I can't resist the suggestion: What about generating full map files for each save with your own logic - basically parsing the information directly from kethane persistence files and exporting it to a format that you can read with scansat? Then there is no need to check latitude against a specific hex. It wouldn't look pretty, and the default kethane overlay wouldn't be discovered by your scan, but you'd get useable information out of a scan that could be run in the background... It could be an acceptable compromise for many players.

Hello folks, I'm following this thread with earnest interest, but I'm getting a bit confused - as I understand it, the goal with this update is to allow scansat to detect resource maps for ORS and kethane using scansat scanning logic as opposed to the scanners in the other mods, thereby allowing background scanning and scansat map overlay integration. ORS is currently mostly working, but since kethane has a bunch of extra logic for its hexes, that's more complicated... The updates made it sound like the primary hang up was just getting the hex grid overlay working, which seems to imply that kethane scanning is expected to function with module manager tweaks, but that there is no scansat overlay for it yet, which just sounds too good to be true. How wrong am I?

What about site administrative functions? It seems like there should also be easy ways to do things like: change a mod name without killing search / statistics for the mod change a user name without killing the associated content etc. Additional functionality there would be largely dependent on what other features ended up getting added, but making sure that the site admin doesn't have to dick around with scripts and or DB entries any time we needed to change something would probably be good to work in early.

Both, actually

Hey guys, the link in the OP doesn't seem to be functional, does anyone know where I could get a copy of MM 1.5.6 ?

Yes, where it's available, geothermal energy is awesome. For example, in Iceland. The question is simply one of energy, and it's generally easier to produce solar energy in most locations. If you're in Iceland, obviously, geothermal is a better bet, but we don't yet have the technology to 'tap into' geothermal energy wherever we please. Solar thermal, however, is far more widely available. So, I guess this is a question of whether your raw materials are closer to a hot spring or a desert, more or less. Also important to note is whether or not the source of geothermal energy you're using is located somewhere that it is stable enough that you can actually use it for industrial purposes, and whether or not it's available for said purposes (as in, not a national park / natural monument, etc.) The size of a solar thermal facility that could do this on any appreciable scale would probably be pretty intense, and variable temperature would be a serious engineering challenge, but I'm guessing that the cost saved by not shipping your raw material half-way across a continent (or the world) to get to the nearest geothermal plant would probably end up making it worth it. Or you could do it the way most folks do this sort of thing - By burning hydrocarbons as your energy source. Depending on your raw materials, it's actually very possible to come out with a net chemical energy gain from that sort of process, and in fact, there are a number of facilities that can achieve this with simple organic materials, like farm wastes / meat processing by-products. It's not terribly efficient, but again, the question becomes one of logistics - carting around your potential fuel mass gets expensive fast.

You'd probably be better off trying to use captured solar energy - Tapping geothermal energy to convert a misc. raw hydrocarbon base is, with current technologies, limited to areas with pre-existing favorable conditions, IE, hot-springs and such. Solar thermal energy is much easier to find in large quantities at present - Maybe someday when we can drill much deeper...

Hiya, I am trying to create a comprehensive 'sandbox' style mission architecture, and I am wondering if this mod will allow me to do that in it's current state. The basic idea is to have a 'suite' of missions available for every orbital body, and then allow any given vessel to choose to complete any given mission, or multiple missions, while in flight, with next to no requirements for selecting any given mission. Essentially the idea is to just assign cash rewards to a variety of objectives and then allow the player to decide how best to structure a mission architecture that can accomplish them. I have a few questions about how missions work - 1) Is it possible to complete multiple vesselIndependant missions in parallel? IE, assuming I have a ship that is in the Duna system, could I select a mission to orbit duna with an optional bonus for returning to Kerbin, then switch to a mission that gives me a reward for orbiting Ike and a bonus of returning to Kerbin, and then return to Kerbin and get both sub-mission bonuses? Or am I required to complete a mission before selecting another mission? 2) What is the documentation indicating when it says that vessel will become 'client controlled?' 3) If you have a part-requirement as part of a docking mission goal, does mission controller assess the total parts of both docked vessels, or only the vessel that you were piloting when you selected the mission? 4) Is it possible to string multiple repair mission goals together in a single mission? The idea is to create a time-trial of sorts where a Kerbalnaut must repair x modules in y time.

Hey, just curious - Whatever you're calling to present the arrows - Is that call-able outside the VAB? For that matter, are the stock indicators for center of thrust / center of lift presentable outside the VAB? It would be kind of awesome for debugging craft in-flight, or designing variable geometry craft. I've always wanted to build a 'dock-bot,' like a separate RCS platform that grabbed station components for assembly, for example. Being able to see this information live and in-flight could be super useful.

I thought I'd share my progress so far. I've completed the majority of the engineering necessary for the challenge, in the next few days I will be drafting my launch schedule and launching my first few flights. And maybe at some point I'll come up with a name for my mission... =/ This is a pretty bulky post, so I'll probably be documenting my progress going forward in another thread, but I got impatient. Moving forward, I also plan on (hopefully) being the first contestant to submit video documentation of my flights as well as screenshots and mission reports. I hope you guys like it, this is the first time I've done anything nearly this involved in this game, and I'm having a fantastic time! Module Inventory Dunar Rover Tech Demo

Get the B9 Aerobrakes. They're amazing, and far more flexible than a drogue chute anyway. That whole pack is worth it if for no other reason than the aerobrakes.

Hiya! I've been following this thread for quite awhile, lurking quietly while I designed my mission modules. I am very nearly done, and ready to start documenting and developing my mission profile. I am super excited! I had a couple points I was curious about clarifying, if sturmstiger would be so kind: 1) I've developed a really nifty re-useable launch system, however, it does experience some re-entry effects - I am playing with Deadly Re-entry, and the launch vehicle survives re-entry by using its engine as a heat shield. (I use a combo of B9's Aerobrakes and some probe torque to keep it pointed engine-side down). Additionally, the launch profile is such that I actually have time to circularize and then switch back to my final lifter stage to manually land it. Does that still count as re-useable? 2) Does the use of Ion-cross preclude the rule about supplies entirely, or are you simply allowed to ship Ion-cross oxygen containers as if the were supply units? I could see that going either way, although, I will say, actually needing to be concerned about the oxygen that your kerbals are consuming while in transit most definitely adds another layer of difficulty - The mass of enough oxygen to survive a Duna transfer drastically exceeds the amount of mass you'd need to ship up in abstracted RCS supply units for the same period of time, and any manned off-window transfer attempts are incredibly difficult. 3) Assuming I am using Remote Tech, can I launch my initial Kerbin relay satellites for without re-setting my launch window timer? I really enjoy how much challenge Remote Tech is adding to the actual Duna mission, but it seems a bit punitive to include those first few launches as part of the general launch limitations. Thanks!