dewin

KER bases dV calculations on the root part, so if your root part or staging are wrong you may get wrong results. Also, did you have enough electrical power to run the ion engine? It's possible that's factored in to burn times.

Heh, to clarify, my original response about MM configs for stock probe cores was never intended to be a request for it to be a standard part of the mod -- more my thoughts on implementing it either myself (since I'd already given it some thought) or having someone else who's interested take a stab at it. My thoughts were more towards integrating it with probe cores based on their location in the tech tree vs. the currently parts, assuming the current parts follow Moore's law. The only problem is that I don't think there is much in the way of tiny probe cores near the end of the tree -- so I'm not sure what the stock analog to KAL9000 would be. It's worth noting that kOS already does have some features gated by the tech tree -- e.g. those that require sensors to be installed on your ship. That said, I'm against any sort of hard restrictions based on tech tree progression. The only two limitations I could imagine that would make sense (and perhaps be reasonable to implement) is having actual speed be part of the progression (e.g. having the earliest processor run at a brisk 10IPU) and memory limits (it doesn't matter as much if I'm limited to 5k disk if I can fit the entire contents of the archive in memory). Actually, it'd be neat if all of the storage worked in terms of bytecode (Rather than COMPILE output) size, other than being less than intuitive. This probably falls under the realm of gameplay over realism, and I'm fine with that. (Though imagine EVAing to a satellite to perform a firmware upgrade and praying you don't brick it.).

So, I'm in the process of writing a code minifier/installer for kOS scripts... in KerbalScript. When run against itself, the current build reduces the file size by 40% at maximum settings (and it doesn't yet alter variable/function names or do other abuses). It's probably wholly unnecessary on anything but the first kOS module, but meh. (It also helps grab everything a particular script needs in the transfer process, though I'm still working that out.) TL:DR: This is really long. Oops. Discoveries: Compiled code size is partially based on line count. The minify step that reduces a file to a single line of code yields significant filesize savings. This actually caused me headaches before I discovered it, since I was comparing file sizes as a quick check to ensure the minifier didn't accidentally alter how kOS interprets things. (kOS devs: could the KSM representation be smaller with a single bit indicating "this opcode starts the next line" and a virtual "seek" instruction for cases where more than one line is being jumped? Or there could be the notion of a separate debugging symbols with no line information in the KSM file, but that's probably overkill) In any case where a period's purpose is ambiguous, kOS prefers the option that consumes the most input. 'print 1.print 2.' works as expected. 'print 1.2.3.4.' is valid code that prints 1.2 and has a '3.4.' instruction that is effectively a noop. This applies in other contexts as well, e.g. "42foo" parses as two separate "words" before it is rejected as invalid syntax. 'e' is an operator, not a number format. '1 e 2', 1e 2' and '1e2' are valid. '1 e2' looks for something named e2 because it's a valid variable name. '1 e+2' works because variable names can't contain symbols. kOS doesn't support non-ASCII variable names; anything outside of 0-9 a-z and underscore is not handled by the parser at all. I'm thankful for this because I can't ask if something is a letter within KS, so I see if it's contained within "abcde...". Non-English speakers are probably less thankful. The colon (as does the deprecated '#') follows the same whitespace semantics as operators: 'ship : orbit' is legal. Annoyances/Requests/Pie in the Sky Wishlist: (With emphasis on "Pie in the Sky") Compilation/parsing time: On my (reasonably old, but handles KSP at max settings) machine, there's a fairly lengthy ~5 second delay before the install script even starts. The script itself is only 20k ish (with lots of comments), so that is a bit surprising. I can live with it, but that's there. Exceptions: It'd be nice to have some limited exception handling. Tokenizing a KS file within kOS is expensive, so I temporarily change config:IPU during execution and revert it back to the previous value after. There's also some temporary file use (e.g. compiling to the archive and copying the complied file rather than requiring the target to have enough space for both source and result). If my code aborts for any reason, the revert never happens and temporary files are never cleaned up. Other processors: If there was a way for one processor to run code on another, I could work around IPU limitations -- idea being that I could have a literal build bot with multiple kOS cores sitting near the launchpad. I could probably rig together a signalling mechanism involving changing ship control states on one core and waiting for them in another, but that's about as ridiculous as writing a code minifier in KS . IPU: Being able to exceed 2000 IPU while on the launchpad would be useful -- maybe a "IPU Multiplier" setting. This is assuming that this is actually my limiting factor in speed. File I/O: This gets its own list. - There is no built-in way to copy a file to a destination under a new name; it requires reading and rewriting the file in KS. There's also no way to specify both source and destination volumes (meaning a SWITCH TO is required if not doing it within KS). Volume:Copy could fix one or both of those issues. - There is no way to compile to a volume other than the source, or compile from a string rather than file contents (which would allow a way around the first problem) - If you want to overwrite a file that may or may not exist, you need to test for its existence or delete it first. Bug: DELETE fails if the file doesn't exist, vol:delete does not. - There's no way to check modification times of a file, or get real world time (extension to kuniverse?). If there was, my script could use make-like semantics of keeping its output for files that haven't changed since the last run Strings: - WTB regular expressions. - WTB string escapes (instead of SET Q TO CHAR(34). - Joining a very large list of strings is super slow for some reason, and KSP locks up for the duration. Terminal: - There is way to control the cursor besides AT. There is also no way to get the current cursor context. - It'd be nice to have a way to send terminal commands to the actual running program (since the terminal and RUN have separate states.). Right now the workaround is to write the desired command to a file and then run the file. General language questions/comments: - In terms of both kOS instructions and real overhead, how expensive is LOCK? If I'm frequently referring to somelist[ix] where ix is changing, is something like 'LOCK cur To somelist[ix]' worth it to reduce typing/filesize? (I'm guessing that it's a lightweight function, but how light?) - Well-behaved libraries shouldn't pollute the global namespace. When I had a group of functions that needed to share some state, I wrapped them in braces to create a local scope and assigned func@ to a global variable to turn them into global functions. Declare global function would be nicer - It'd be nice to be able to get a handle to a ON or WHEN construct that can be used to, among things, cancel it. The current option is to have the event check for a global cancelled flag and not run/preserve if it is set. I have some code that draws prograde/normal/radial vectors that could use this. (ON Time is an easy way to add code that runs every tick ad-hoc)

FWIW, one of the Mechjeb parts attaches radially and works fine as a control source. As far as I can tell, all's the control source does is determines your reference point and direction for movement (and what section of a ship you retain control of when staging/undocking). That said, I think it'd be make more sense from a balance perspective to add kOS to probe cores rather than the other way around -- they're already technically computers anyways. The biggest difficulty would be balancing the MM .cfg against the tech tree progression (since kOS modules have an improving disk-space-to-mass ratio, but probe cores are so much more than just a computer). I'd also love a "partless" kOS, and already run a MM .cfg for MJ/KER everywhere.

I'm guessing that you either installed the mod incorrectly or you're using an incompatible version. You should have something that looks like KSP\Gamedata\KerbalEngineerRedux as a single folder with the .dll and other files in it -- as opposed to multiple nested folders e.g. KSP\Gamedata\Gamedata\KerbalEngineer or anything else along those lines. Wild guess from my phone though; I'm not anywhere near an actual install at the moment.

I've had a mod concept that would do precisely this for awhile -- the idea being to replace the current building upgrade system with something akin to the tech tree, but unlocked using funds (and/or possibly other prerequisites) instead of science. It'd also allow you to upgrade building aspects independently and add in some integration potential with other mods. I even started brainstorming names and flavor text for the nodes -- for instance: - Slide Rules: Unlock maneuver planning. - Calculators: Increase max number of conic patches to X (How many maneuvers/SOI changes out the orbit predictions will show. Stock doesn't limit this currently) - Reverse Kerbal Notation: Unlimited max conic patches. Visual upgrades to buildings, then, would be based on total funds spent on technologies related to that building.

Heh. I'm still in the early "Can I even do that?" phases myself. What I probably should do first is see if I can throw together something basic that ignores fuel usage altogether, considering that this is my sole KSP modding experience so far. I wonder if modelling fuel consumption is something that KER's VesselSimulator is capable of (which is also used in some other mods). It has the means to calculate dV, so it'd seem that something could walk that path in reverse to 'subtract' it. (I also think there'd definitely be utility in a standard "Simulate activity of unloaded vessels" plugin that other things can hook into for acurately figuring out things like EC/fuel usage and recovery of unloaded vessels.)

Out of curiosity, how are you handling resource consumption during stationkeeping? I've had some ideas for a satellite synchronization/stationkeeping mod, where you'd group a handful of satellites, define the desired orbital characteristics of that group (e.g. "maintain orbital period of 6 hours +/- tolerance and separation of 360/n degrees +/- tolerance"), and then the mod would periodically plan the necessary maneuvers to get the group back in sync and simulate them while the group is in the background. There's lots of reasons why that mod would be a challenge for me (I'm new to writing KSP mods for instance, and need to learn a lot of math regarding maneuver planning) but simulating fuel consumption seems like one of the more difficult parts. What I'd really like to do is say "consume 50 dV worth of fuel" and have the right things happen.

By the sounds of it, you're experiencing a bug involving Krakensbane -- the point about 6km up where KSP moves your craft to the center of the universe for more accurate physics. Any number of mods can cause it -- when I last saw it, it was due to a symmetry bug in Realchutes.

Can we get an option to sort threads by when the first post was last edited? Since most mod authors update the OP when they release a new version (or otherwise have news to share), this would allow us to effectively sort mods by date updated, as opposed to date of most recent bug report/question/etc.

@cybutek I have an open PR on Github that adds some readouts regarding the current body -- namely its name (can't believe that wasn't already there) and the various altitudes for flying high/space low/space high. I'd love feedback when available. Screenshots: http://m.imgur.com/a/OAClk Also, how hard is it for another addon to add readouts of its own? @all: Since I'm working on this already, are there any other "save a trip to the wiki"-type readouts you'd like to see? In the case of the above, I figure they would be arranged in a window that's only toggled on briefly to look at rather than something taking space all of the time.

I'm in favor of a dV indicator being stock, and without any gating behind career upgrades. (Even though it'd work very well with my ideas for a career tree mod with smaller, cheaper upgrades.)

@taniwha The metadata for the most recent release of your mod ended up being one of my first contributions to CKAN (not counting my last KSP binge over a year ago). Hurray. One minor observation/request as a note: If you happened to use Github releases, it'd be trivial to have CKAN notice new versions of your mod automagically.

ReRe: Remotetech and networks that don't drift: I'd love a proper stationkeeping mod that could handle this with small behind-the-scenes burns (I.e. it would just change orbital parameters and remove a corresponding amount of fuel when the vessel isn't active): Configuration: Allow satellites to be assigned to a group. Set a configurable target SMA or orbital period for all sats in the group along with acceptable tolerance. Set a configurable max phase variance (see below) Set a max dV per correction. Phase: As a satellite completes an orbit, its phase goes from 0.0 to just under 1.0 and then resets. (Or 0-360 degrees) This is based on time into orbital period, not relative position of the planet. This allows separation to be maintained even when using eccentric orbits. Phase=0 is defined as the point where this orbit is closest to all other orbits in the group. (For perfectly circular orbits, this is arbitrary and doesn't matter as much). This might be defined as lowest max distance or lowest average distance. Satellites in a group aim to be 1/n phase apart. Orbital corrections: Periodically scan the group for satellites out of SMA/orbital period tolerance. Select the satellite that is furthest out of tolerance, if any. If no satellite is selected, select the satellite that is most out of phase tolerance, if any. If all satellites are within tolerances, do nothing; otherwise Plan maneuvers to bring satellite into tolerance -- either adjusting SMA back into tolerance, or adjusting orbital period until the satellite catches up/calls back into place and and then resetting back to target SMA -- and execute them. No other adjustments to the group occur while maneuvers are planned. If a satellite with maneuvers planned is in physics range, aborts all planned maneuvers (though they'll be replanned later when the sat isn't in range.). If any satellite in the group is in physics range, planning is temporarily suspended. If a satellite in the group is ever on a suborbital, escape or intercept trajectory, all planning is suspended. If a satellite is ever in a different SOI from another satellite, all planning is suspended.

Whoo! Official update. I'd heard the unofficial build was occasionally causing some quirkiness so it'll be nice to see if that fixes any of my minor issues. (I run mod-heavy, so hard to tell the cause.) @TriggerAu minor request/reminder to update title and OP?

I'm a fan of @5thHorseman's suggestion -- in fact, I came here to suggest it myself. This would mean that sorting threads by title descending would provide a list of all updated mods by KSP version and then date -- despite the fact that it's an alphabetical sort. In fact, one of the advantages of using ISO dates is that they will sort correctly regardless of whether they're being treated as dates, numbers, or just plain strings. Edited to add: Half of this would be moot if there was a way to sort by date of last edit of the first post.

FWIW, the thread title still advertises 0.5.5 for KSP 1.0.5. I saw the newer version on CKAN so popped over here to look.

So, there were a few discussions about the new orbit lines in 1.1, to the point where there was a last-minute addition to make it possible to reverse their direction. A few people had indicated their concerns with this addition: it would make it harder to understand what's going on in screenshots (and streams...), particularly if your setting is the opposite of someone else's. This could be particularly problematic with new players who don't know about the setting looking at screenshots from people who have it reversed. While I have no intention of changing my settings from the default direction and thus wouldn't directly benefit from it, it occurs to me that a mod that forced the direction to "normal" when taking screenshots (but otherwise respecting the user's preferences) could be useful to the community. Thoughts?

I've seen that occasionally as well, but what I'm actually experiencing is -- after I've plotted the node and left map view, it disappears the moment I try to do anything with it. That said, I've stopped being able to reproduce it in my current save so I'm not sure what's going on. I think Trajectories +/- adds/removes how many conic patches you see if e.g. you have a route going through several SOI, guessing by the Precisenode option that did similar.

The problem went away when I removed PreciseNode, so if it's not the direct cause it's conflicting with something else. It's quite maddening too -- I'm able to set up the node perfectly but as soon as I try to do anything involving it (add an KAC alarm for the next maneuver node, or use SAS to point towards the maneuver). The maneuver in question was for the circularize burn after launching to LKO. I'll do some binary searching to see if I can link it to a combination between PreciseNode + another mod. Some possible candidates might include MechJeb (because it has/had its own maneuver node editor, which I somehow don't have anymore -- maybe due to early Science/Career game) and RemoteTech (but this was a manned vessel).

Best thing to wake up to I've heard in awhile. EDIT: Something is still making maneuver nodes disappear before I can actually use them though

Ah, that confirms for me that this is the mod that's doing it. (I haven't taken the time to properly bisect yet). Are you having any issues with maneuver nodes randomly disappearing as well? (To the point where the node is 100% gone before you can even use it)

@sarbian Just poked around at the default config file to get an idea for it. It's close to what I'd want to see as a framework for a mod (and at least establishes that said idea is possible), but not entirely there -- it adds additional levels that I can see, but I don't see any sort of way to do the sort of 'branching' idea I originally had. The ultimate end goal a year ago was to have something akin to KSP's science tree/the talent tree used in MMOs/etc -- where individual parts of a building can be improved independently from each other (but with some "Option X requires both Y and Z"-type things.) -- so you can make smaller incremental upgrades to the things you actually care about rather than upgrading the building as a whole. Maybe I'll eventually teach myself C# and poke at the source and dabble... but UI is my weakness in -any- language so I don't even want to imagine how that'd go.

Hmm, a year ago I posted this idea/mod requests of making KSC upgrades more like a tech tree of sorts: Would this mod make that possible?

Considering that Squad has hired several mod developers in the past, I imagine some of them definitely play with mods. ISRU in stock is the brainchild of Karbonite/Regolith developer RoverDude, for instance.