komodo

So I ought to at least deploy a working copy after having said all that... Find the file below the fold. Name it zROMini.cfg (make sure that the ending doesn't do something like .cfg.txt, or KSP won't use it.) and enjoy! Please report any issues, and I will try to address them in a timely manner as best as I am able. Cheers!

At the moment on mine, it's being very perplexing... Something in the config is causing KSP to blow up when trying to generate and/or read a float curve, which I assume to be the drag curves based on the log context around it. The perplexing part is this is after I stripped out the portion of the script that deals with drag cubes, and any other float curve I can find... i'm peeling back patches until I can find the offending block. I think I have it on the run, in that I have a stripped out version that loads, while the full original copy doesn't. Now to add back in pieces until it fails again. OK. Of course. It's something in the Stock Procedural Fairing Scaling/node scaling... code behind the fold below. It's 12:30 am now, so I am out of time to debug it, but this patch gives a very quick bomb on my install, as soon as it starts compiling parts. I think the drag cube thing was a fluke. The patch: The Errors: This one threw me off the trail for a while... It occurred right before the halt, but I think its a fluke at this point: Now: There's a reason i'm laughing. This is the block of code that I borrowed/adapted to make the script to generate the node MM patches for in the first place. So the concept works fine... However, I do recall running into this during development/testing as well: I suspect that it's leaving a comma trailing in a float somewhere, or something. ... Yep, that's it exactly... I had to work around the fact that the last index in a node_stack definition is optional. (And its not very nice to complain at an author for not using an optional parameter , so better we handle it here.) It worked on yours by virtue of happening to have procedural fairings with all six indexes defined. From the python script: //I am attemting to strip out the trailing comma and replace it with a whitespace. (That didn't work so well, so maybe we can set it to "1") @{0}[5] ^= :,$:,1: In MM syntax, that'd be... @node_stack_top[5] ^= :,$:,1: @node_stack_bottom[5] ^= :,$:,1: We need to add these just after we reassign our scaled nodes to the original name(s). I *think* that only adds the one if the trailing character is a comma, but i'm not sure. In either case, it's unlikely to be mission critical, as far as I know. As the note I left to myself says, I tried to just strip the comma, but was unsuccessful. I'll get this all wrapped up into a new PR whenever github gets my account straightened out

Danger Will Robinson! I just spent the last few minutes puzzled as to why I had no science experiments in my new career save. There's a duplicate experiment config in the resources on github, and it made KSP make a very rude statement to me, lets say. Just a friendly heads up to other testers if they find they can't science either.

I am looking into it now, actually. It should be much simpler in the end with several changes in 1.1. It hasn't appeared yet officially as github managed to get my account all mixed up, and i'm waiting for them to straighten it out. I'm running down bugs in my own 1.1 install as well, so it might take a few minutes

Right, so, good/bad/weird/"what?" news to report: We'll go in order. Good: I have a tiny bit of free time again, and have started putting the 1.1.2 pieces together to get up to speed on this release. (I don't use CKAN. This takes a while.) Bad: My resulting performance on OS X is *awful*. Or, more specifically, the flight view was managing about 1-2 fps. Map view was fine. This is a chronic (for me at least) OS X issue with the ocean/water ... things. I've solved it in years past by adjusting... something that eludes me at the moment in the settings regarding the ocean depth variables. I don't even know if that's still applicable. Weird/mixed: In contrast, on my linux install, the performance is great! Same hardware, still opengl, night and day difference. Full gfx, scatterer, etc. No slowdowns really to speak of. Good job OS X But, the mixed part, is that evidently I get hit by the apparently known issue of the GC in Unity goofing and calling free() twice under linux and crashing the whole mess to the desktop. Good job Unity This of course happens on scene change, but not every scene change. (Just like 0.90 in OS X, come to think of it, haha.) I'm investigating workarounds, but it's clearly hard to chase down an intermittent (probably) engine bug. I sympathize with your plight. "what?": Apparently for some inane reason, Github has flagged my account as a possible bot. I have no idea why. I have a ticket in with them to get that straightened out. I discovered this when going to make up a new PR, of course. Blahhhh >< In other news, it handily gives me a bit of time to poke at it to see if any further bugs shake out... I made some changes, but they're somewhat guesswork at the moment. tldr: i'm trying. The assorted gremlins of software development impedance are afoot to an extreme, however. 1.1.2, what i've been able to sneak in, is pretty damn fun though So, I guess the moral is to take any bright side you can get!

On mobile, so excuse possible wacky formatting... On the titan_3seg_srb, is the fuel load out sane? It has wayyyyyy less than the two segment above it. But yeah, mobile github as well... So... It could be that too otherwise, looking good thus far. That poor Srb rebalance patch though... (hoping to get some play in tonight, *finally*...)

Right. Another week. Another weekend. Another Play Session! Woo! I'm checking out the new bits and bobs, and thus far things look pretty good. I'm clawing my way up the tech-tree as fast as reasonable... which is pretty fast without KCT and a rescale in place Immediate notes: The RT antennas patch has one botch and one omission: Typobotch is not actually in the patch, but the bluedog_telstarAntenna didn't actually get named that, and is simply bluedog_telstar in its own cfg. The other is the Agena antenna missing out of the RT patch. I wildly guess stats as twice those of the simple antenna based on a extremely gross appraisal of their similarities. (One is an extendable coat hanger. The other is also an extendable coat hanger, but presumably of higher quality. Make stats 2.5x ) Find code behind the fold. I'll update as/if I find things. Looking good thus far!

Thank you for your reply. Please note in my original message, I mean precisely what I had asked: Is there a way to modify via Modulemanager, the RemoteTech_Config.cfg: While you are entirely correct that it is quickly and easily possible to add additional stations, etc., via an additional config, this is unfortunately not at all what I was asking about (By which I mean things such as adjusting the global range modifier in particular: This is of tremendous utility for playing on arbitrary rescales.) In my experience, MM is unable to apply changes to the config as it is able to with many other mods. I had just wondered if anything had/would/could change(d) recently. Thanks much! (And wow, what a difference a week away makes... Looking at the updates, i'm looking (even more) forward to 1.1 )

Is there any way/chance that the RT config could be made accessible by modulemanager? I know a couple mods would love to access the settings globally, and for myself, I maintain a tweaks folder of assorted personal adjustments/balances; having a "one stop shop", with out adjustment on each release is always handy i may be talking out my hat, as I haven't tried in a while. I know last time, it was unsuccessful for whatever reason. In any case, huge thanks for picking up the baton, I'm looking forward to unleashing RT on 1.1 soon! (Who's betting on 1.1.1 though, despite the testing? )

Strange contract text would seem to fit perfectly with the stock descriptions No, I'm sure it will be fine. Thanks for taking a look, this was one of my favorite mods in 0.25... Which is the version I apparently did the most ambitious builds in, according to my screenshots. Hopefully we can top that soon

The science transmit, or lack thereof is a remote tech bug. Check their thread , even the last page or two have commiserate bugs

Unlikely, as the suggestion was only made in light of a very nice part already existing (and trialed for this role) in the Prometheus 1 stage two decoupler for the standalone part, of course the integrated one should stay in place

I like the textures a lot! the hatches might probably be This issue/thread from the prerelease add on forum. (I think. It would make sense.) Feedback/ suggestion on Trails: possibly disable the built in decoupler when installed with/along side BDB? I've never been able to make mechjeb/KER play nice with dV read outs on such parts. I suggest this as a slim 1.5 m decoupler is already in the pack; it looked pretty seamless to my untrained eye testing still pending on that other stuff, solids et al. Plumbing problems rarely are scheduled nor fun

I think KSP-I used a similar mechanism for their beamed microwave uber widget thingy (Very Technical Terms), but it's been forever and a day since i've played around with that... 0.25 or so. Were not most of their models public domain of some sort? It also is late at night and I could be hallucinating the entire thing

I'll dare a quote... Trying out the dev pack, and I notice a doubled/residual/missed LOantenna in the antennas folder (What an odd place for them... ) , and curiously the Mercury/Hermes pod has ablator added as well as a separate heat shield; I'm still waiting for the game to load, so I don't know if the heatshield has been whacked and just missed for removal, or what... we'll see in a few minutes PREEDIT-EDIT: Game loaded, but RL stomped in. Testing pushed off until tomorrow. I'll try to get some configs/testing on the new antennas RE remotetech as well (Am I the only one who enjoys that mod here?), but I wanted to give a shout out about initial impressions. Also, burns suck. You take care of you first!

Query/thought: instead of needing to model entirely separate parts and textures, is there any way for stock (1.1?...) or DMSA to do a dependency check, more or less? That is, have the mass spec as it is, but perhaps helper parts to be shared across a few instruments to do it in a kinda abstract/handwavy way: "The manual for the mass spec says it comes with the atmospheric package out of the box, but the vacuum and solids packages are sold separately.", and have some sciency looking widget to be attached to the craft (as a separate part) to represent the vacuum ion trap/surface scoop/whatever. You could still make a lander out of an orbiter, at the cost of an extra part, but that may be a reasonable trade off. What other experiments would have such variants in flight/space/landed? I'm having a brain fart.

Cassini is kinda a tank, isn't it? (!) im going to try to get some play time in on 1.0.5 tonight, I'll try to focus on probes if possible. (These in particular, I mean. ). I need to trim the mod trees a bit first, things are getting a bit over grown

I think I've heard it said that unity does not like the entire everything that KSP does/needs, so an animation hiccup here or there shouldn't be too worried about. Looks good!, aside from the corrugated iron part, yeah

That Srb/SII concept is like an Aries I from hell... I like it. on rescales, I would say keep the proportions "right", with fuels fudged to somewhere between "stock" and "fun". Balancing against stock is folly as it doesn't seem balanced against itself half the time (some would probably say it's more "kerbal" that way, but I don't wish to start that holy war...) if they don't come out to stock diameters, it should be a fair compromise to figure out the right scale for an adapter. (I suspect the model scale nodes could deform any existing one so a new model isn't needed, but that's just a supposition on my part... Hm.) looks good on the whole though! I keep not quite making it far up the tree enough to really dive into them, but they provide a good motivation!

Two thumbs up for sure, that looks *awesome*. The scaling looks smack on. If NASA had mechjeb, it'd be a perfect photorealistic shot (The aux engines are still marked/named as monoprop after moving to LFO, I think. I'll double check mine.)

Looking good! There is a very flickering amount of 1.5 m parts floating around... It's somewhat of a niches niche of a size, but it does exist. (What would I even stick a 1.6 m part on to launch it?... Haha) The trusses are quite shiny as well. Looking forward to this to go with 1.1!

Depending how systemic the filename changes need to be, that could be a sed problem, as much as I dislike its syntax; it does do good work in the right situations... But I feel you for sure on the bytes>string>bytes thing... It's always something silly like the whole "bytes" part not working, right? (Mine are usually of the style "well you worked perfectly, only you did something entirely different than I intended...)

Wouldn't the ratio just be that? Isn't this an ISP knob to turn? It goes directly to efficiency, I think. How much fuel for a given thrust, etc... That said, I don't know for certain, but I would check that number as well. (It'd be the thrust curves... Are they marked atmospheric curves in engine modules? I think that's them...)

Addendum to my post above, following some sleep. I entirely forgot I'm playing on an up scaled system size. My numbers may be totally hosed up. But it's also via SMURFF, so maybe it cancels out?... ill try to load up a ... Stock... (Ugh!) system later to see what science has actually wrought.

This is me just smashing numbers around. There was at the beginning an idea to realign the numbers to something more matching reality. That kinda went by the wayside in favor of 'fun/feels/etc'. The other part is me trying to do a thing which apparently doesn't work; i'd love to have the SafeSolid system (great marketing, btw!) available such that the on/off is done via throttle and not activate deactivate. I could have sworn that RO managed such a thing, open the throttle even 0.001% and it comes on full. They may have been using their black magicks though, for all I know. Anyway, find some MM mashup behind the fold. If someone else wants to have a play with it to tell me how it feels gameplay wise, that'd be great. After decent gameplay, balance can come in. Basic goal was to make the light things lighter, and the heavy things heavier. Fun fact to find out that in contrast to many parts which scale down for KSP, the Pioneer 4-a-like actually scaled UP. We sent some really glorified model rockets off once upon a time, didn't we? The Sargent numbers are taken from reality, but smacked by a 0.64 multiplier. It occurs to me now this doesn't take into account the KSP dry mass ratio. Crap. Oh well. They seemed fun, at least! As it says at the top of the file, this is "Whack 1". I hope to have a chance to get back to it this week, on my supposed vacation, but we shall see! Night all!