Creat

Just wanted add my +1 to the issue Boomerang is having, even though I'm actually using cybuteks version at the moment. Otherwise, I have a question about the interface. All those flight-parameters you've added to be able to accurately simulate air-breathing engines, switching thrust to a more realistic model and so on. Would there be a way to usually hide them, or put them in the actual GUI and not the context menu, possibly even adding a dedicated dialog for them? After all, you're not trying to tune parts of a rocket/ship but the simulation of parameters. I ask because I add KER to my pods/probes, so their context menu becomes quite cluttered, and most of the time I don't actually need the options (while I'm glad that they're there when I do). As a simple solution, if that's even possible, it would be fine to just have a single context-menu-entry 'Show advanced', which then adds the other entries, but I do think that an actual GUI window would be better (or something that extends the existing windows).

No the regular version works fine, it's been updated for 0.24. Some stuff is a bit wonky (like stock toolbar integration but, Blizzy's works fine as ever). You will want the experimental version if you do a lot of spaceplane stuff, as that can be simulated better. This also clutters the context-menu a bit though, which is mainly a problem for those who add engineer to pods/probes (like me). I think that's all

Yea, I'm quite aware that you were only doing that every 200ms, but whenever it did happen it introduces a visually intrusive 'jump' for some reason (I can upload a short video or something showing this, just for demonstrations sake). So since I was changing it anyways, it's now only called every 200ms (or whatever you set wait_active to) or 2s respectively (when not active --> wait_idle). Less overhead on the main thread is always better, as CPU is almost always the limiting factor for this game. And even when it is called and there is nothing to display, it only clears the LCD once now and not every time (since that's what was causing these jumps for me). All in all it's a tiny patch, excluding comments it's maybe 20 lines or something of actual code (so not really counting { and }). I know that you were not really doing anything even when the 200ms were up, clearing the LCD is just writing the string to the bitmap and showing it (for every 'lcd-screen'? just once? didn't look into weather a 'Device' was an actual device or a screen, like orbit, target, ...). I'm just as baffled as you are as to why that would cause such hiccups, as the normal code writes to the LCD much more frequently and doesn't cause this as far as I can tell. No idea why....

Well, I've actually (mostly) sorted out the problem with the stuttering. It's not completely gone but much reduced. I'm just gonna send you a pull-request on GitHub, I hope that's fine (but I also just give you a patch-file if you prefer). What I've done is changed the LCD update from using Update() to a Coroutine. It's not called on every frame draw, but only in defined intervals. I've also split them up between 'idle' and 'active', so it doesn't try to update so often when it's not needed, and it only clears the LCD once (and not on every call). I'm actually still interested to find out why not doing anything there takes so long, might have another look tomorrow unless you have a clear idea?

That really makes no difference, he has the opposite of the usual problem: he can control the probe when he shouldn't be able to. You can see on the map that he neither has a connection nor line-of-sight to KSC (no relay has, either), and even if he did: it's reporting "Local Control" for an unmanned craft... ModuleManager is clearly working, or Signal Processor and Technology Perk wouldn't be there. The plugin itself is also there and working, as you can see the red dot on the map where the KSC is (I'm pretty sure it's missing when the plugin isn't loaded, isn't it?). I know that probes are uncontrollable in 0.24 when there's no signal (so everything is working as it should) because I had that yesterday when deploying some simple sats (which was fine and part of the plan, but does show me that it works). Are you possibly using 64 bit and it has something to do with that? I'm on the 32 bit version of KSP (as I don't have enough high-memory-mods to require 64 bit there's little point). Honestly, I'm thoroughly confused, especially since the modules are shown to be there (and are correct as far as I can tell). (to actually answer your question: The Omnis are clearly not activated and he said the dish is pointed at KSC, which means it's active or you can't point it anywhere. Unless he pointed it and deactivated it, I guess.)

I've played around with it for a bit, and the non-flight scenes are still quite jittery. The framerate is mostly fine, but it still stutters for me multiple times per second. This is very noticeable in the main menu as it scrolls horizontally on clicking 'Start Game' / 'Back'. This is clearly not an issue here as nobody stays there for extended times, but it is almost as noticeable when panning in the KSC scene or even in the VAB/SPH. Out of curiosity I took a look at the code, and you really aren't doing much when there is no flight active, but you do clear the screen every time and write the waiting for flight message. Maybe doing that only once until there is a flight in progress again would be enough to stop the stuttering? If it doesn't you'd probably have to really check what's taking so long to cause I also kinda got a bit curious now if it's possible (and easy) to detach the LCD updates from the full frame rate (as that's certainly overkill). So since I wanted to check out the basics of KSP plugin development anyway I'm just gonna play around a bit. Mainly out of curiosity though, but something might still come of it...

Yea I've noticed by now. For me it mostly happens when I open the "Load Craft" dialog in the VAB, but then change my mind and click cancel. I always click 'through' and grab a booster or whatever else is behind it...

I think they're cheaper than stock, but it's playable. They aren't so expensive that it breaks the bank or anything...

It will load from anywhere within GameData, so if you have one in GameData and one in any subfolder it'll load twice. Just search from GameData for "ModuleManager", only a single .dll should come up (and that should be the newest version available, if possible).

It works perfectly fine on 0.24.

Do you have module manager twice by any chance? That is usually the cause of this...

It's actually rather trivial to make it partless. I always do (like a wrote a page back or so). All you need is a module manager config to add it to probe cores and pods/cockpits. This is the config I use. It explicitly adds it to all stock KSP 'command' modules (probe cores, pods, cockpits, lander can and external seat). You could do it with a single category, but I'd rather add specific configs for mods that provide probes or pods (at the moment, I don't have any). Just put this in a file with .cfg extension somewhere in GameData (obviously needs module manager). If you don't want the kerbal engineer parts anymore you can just delete the three subfolders from the 'Engineer'-Folder in your GameData (NOT the PluginData folder though!). @PART[probeCoreCube] { MODULE { name = BuildEngineer } MODULE { name = FlightEngineer } } @PART[probeCoreOcto] { MODULE { name = BuildEngineer } MODULE { name = FlightEngineer } } @PART[probeCoreHex] { MODULE { name = BuildEngineer } MODULE { name = FlightEngineer } } @PART[probeCoreOcto2] { MODULE { name = BuildEngineer } MODULE { name = FlightEngineer } } @PART[probeCoreSphere] { MODULE { name = BuildEngineer } MODULE { name = FlightEngineer } } @PART[probeStackLarge] { MODULE { name = BuildEngineer } MODULE { name = FlightEngineer } } @PART[probeStackSmall] { MODULE { name = BuildEngineer } MODULE { name = FlightEngineer } } @PART[landerCabinSmall] { MODULE { name = BuildEngineer } MODULE { name = FlightEngineer } } @PART[Mark1Cockpit] { MODULE { name = BuildEngineer } MODULE { name = FlightEngineer } } @PART[Mark2Cockpit] { MODULE { name = BuildEngineer } MODULE { name = FlightEngineer } } @PART[Mark3Cockpit] { MODULE { name = BuildEngineer } MODULE { name = FlightEngineer } } @PART[Mark1-2Pod] { MODULE { name = BuildEngineer } MODULE { name = FlightEngineer } } @PART[mk1pod] { MODULE { name = BuildEngineer } MODULE { name = FlightEngineer } } @PART[mk2LanderCabin] { MODULE { name = BuildEngineer } MODULE { name = FlightEngineer } } @PART[cupola] { MODULE { name = BuildEngineer } MODULE { name = FlightEngineer } } @PART[seatExternalCmd] { MODULE { name = BuildEngineer } MODULE { name = FlightEngineer } } @PART[crewCabin] { MODULE { name = BuildEngineer } MODULE { name = FlightEngineer } } EDIT: I think this is the simplest MM config that will just add it to everything that can control a vessel. It's obviously much simpler and shorter. @PART[*]:HAS[@MODULE[ModuleCommand]] { MODULE { name = BuildEngineer } MODULE { name = FlightEngineer } }

Wow that was fast, thank you! I saw your post that you'd have a look when I went to bed and just came here to say that I'm very much looking forward to that, but I already find the updated AND fixed version. Kudos! As for the 64 bit issue, I remember reading somewhere that you had to jump through a few hoops to even get access to the external calls, so I don't know how much help this will be, but have a look at the open source LCD Miscellany. It's actually quite similar to LCDSirReal (but open source) and Lcd Studio (but not so god damn huge, Studio can take multiple hundreds of MB). It's released as both a 32 and 64bit build, and I know he accesses the LCD somehow directly, as it's the only program I know that will work perfectly fine even if the Logitech software is NOT running (drivers do have to be installed though, obviously). It will still use the Logitech Gaming Software if it is running though and can be managed there. Additionally it's extremely light on memory (8 MB or something). If you don't know it, might be worth checking it out just for your own use, even if it's not as helpful as I hope. It takes a bit to setup (all done with text-based config files) but it's incredibly flexible and powerful! I use it for basic system stats on my LCD when I'm not in a game, as well as a simple process manager (allows me to kill a process from the LCD directly) and weather forecast/display.

Here: "[...] then you are not targeting the playerbase you think you're targeting. You in fact are targeting a player who's skill, understanding and concern is almost on par with FAR!" At least that is how I understood it, though it was apparently not what you meant. My apologies. Despite the fact that I mention you, this post wasn't actually addressed at you (or meant as a reply to you), let alone an attack on you. I thought I made that pretty clear when I said I just wanted to elaborate a bit. It wasn't even in defense of ferram4, but it was somewhat addressed at him as a thank you for creating this (apparently favorite) toy of mine I've known about for all of a few hours. It just so happend to be your post that got me thinking why I was quite excited to see this be released - to my own surprise I might add - hence my mentioning your name. So I decided to put my thoughts it in a post, also to continue the discussion/reasoning from Geoff-AU's thoughts on realism-heavy mods, and why this fits much more comfortably into an otherwise mostly stock game than FAR or even DREC. I'm sorry if this bores you, but there's little I can do about that...

New firespitter.dll has been posted in the official thread, everything should be fine with that (if it wasn't already).

A very simple counterargument (or rather counterexample) to rynak's reasoning why this fills niche that isn't there: This is exactly what I wanted, and it is what FAR isn't for me. There were already quite a few others in this thread with a similar sentiment. Let me elaborate a little on that. The reasons I've never used FAR (in a serious way, apart from playing around with it a bit) are incredibly similar to the stuff listen under "What it doesn't do, that FAR does". Frighteningly so. I essentially want it to make a difference what end (if any) of the rocket I point towards where I'm going (or if I'm going sideways). I want nosecones (or aerodynamic shapes in general) to make a difference and not just add weight (and now cost, have you looked at the prices of those things!?). I do not want things to get shaky just because I'm crossing the mach boundary, and I don't want stuff to fall off because it happens to be where the shockwave of another part ends up. I know this comparison is a bit off, but in my mind I don't care about the mach boundary just like I don't care about relativistic effects when planing or executing my maneuvers. I rarely build planes, but when I do the stock model immediately puts me off again and I go back to rockets (also in career mode, which is what mostly play these days, there's barely any point to it). In addition, I agree with all the stuff Geoff-AU touched on above, full-scale FAR (and DREC, and others) cause too many problems that were just not considered when creating the current contracts, for example. Or the TechTree. There are obviously replacements for the latter, but at least for the moment there is no contracts-mod that gives you usefull missions for specific mods (I'm sure they'll come, hopefully soon, but they are not yet and can hardly be here yet). For those reasons I also just removed DREC (for now, at least) because relatively simple things can become tedious, like weird contracts that want you to test some stuff at strange speeds and altitudes. The only other realism-mod I'm still running at the moment is RemoteTech, and that's unfortunately another thing that goes (almost) too much against the grain of the stock design. I want to use it, my inner self almost dictates it, but setting up a (primitive, but reasonably realiable) relay-network just to get to the Mün with Science-limitations for available parts, and no Contracts that have suitable objectives is not always fun, but can be a bit of work (and not just fun). KSP has all these awesome features, and there are all these awesome mods. I would love to use all those at once with the shiny new features we just got, but they just won't quite fit together (yet) as nice as I had hoped. It's like the toy for toddlers where you have some objects shaped like circles and squares and the corresponding holes in a box to push them though. I have all these shapes but not the perfectly fitting holes like the toy. Some can be squeezed through holes with a bit of wiggling, but it's not a real good fit, and others won't fit though any of the holes at all. NEAR is finally a piece I can easily push though one of the holes, and it fits perfectly. I am VERY glad it exists, so thank you for creating it (or for repackaging it from your very capable FAR codebase).

I had Padishar's version installed until you released the update. I'm honestly kinda glad you didn't include everything, as I like to add KER to all my pods and cores. I always want to have it available, and I don't want to be able to forget to add it so some sub-ship (like a satellite I deploy or something). This causes my pod/core-context-menu to be quite overflown. One solution to that would be to have another (physical) part that is the only one that has a new module, which contains those tweakeables. As I understand it, most of the mare mainly useful with aircraft/planes, so how about just AircraftEngineer in addition to FlightEngineer and KerbalEngineer? That said, the one thing I'd really LOVE is the biome display. I've been hoping and waiting for it for quite some time (but I refused to switch to void just for this) EDIT: Seriously!? WHY? I hope in a few weeks everything will just use the official toolbar, that's what it's for!

While I can report that this plugin still technically works with 0.24, I would strongly advise against using it: It absolutely cripples the framerate. It took me quite a while to isolate this as the cause. Or more precisely, it seems that loading DmcLgLCD.dll (by putting it into the main folder) is the problem. Though to be fair the plugin itself probably doesn't do anything if that library isn't loaded... On to my actual problem: I've set the graphics to settings that my card can easily handle, and with VSync off I get about 180 FPS in the main menu (as that's the highest fps limit that can be set in the options) and over 60 fps for the KSC scenery, in the VAB and so on. The moment I activate the plugin (copying in the mentioned DLL) I don't get more than 30 fps anywhere, ever. Everything also feels sluggish, even just mouse movements. If there's any way this could be fixed, I would highly appreciate it as the additional display on my LCD is just so much better than anything in a window on screen.

There seems to be a problem in 0.24 with the plugin. Near as I can tell, the functionality is fine but clicking something on the tree-selection-UI clicks 'through' it and causes building like the VAB or Research Lab to be selected (entering that scene). The best way around it is to just move the camera away from the KSC complex. I don't know weather this is a problem with the UI code in KSP itself or with the plugin, but I had also clicked through an unrelated plugin-popup that was shown over the main menu (suddenly I was in settings, though I wanted to click OK). Another question for Yargnit: Will you be updating your tree to account for new parts and/or changes to the stock tree from this release?

Like MeCripp said, they will if you picked the right dishes. All dishes have a cone in degrees. For long-range dishes this is significantly smaller as they are intended to be used for long ranges (obviously). If you use them at significantly shorter ranges, targeting a planet or moon will not work then, as the radius of the signal at that range won't be wide enough. You'll essentially have a circle on the surface where you have reception, but not in orbit unless it happens to be passing thought that circle at that moment. So you'll have to do a little trigonometry to check if a certain dish will work for a certain planet at a certain distance.

What do you mean by "SOI targeting"? Do you mean targeting a celestial body in the target list?

You'll have to be more specific. What about it is inconsistent? I know cones are inconsistent (as you outline below), and that's scheduled for fixing...My first issue is that 'Active vessel' works like a targeted connection, not like a cone. Take the example from my last post, if the probe is behind the Mün, it should automatically route via the relay-satellite because it's inside a cone. I have told the sats around Kerbin to connect to whatever I'm trying to control, so trying a little harder would seem reasonable. This would allow relays to use 'Active Vessel' instead of always having to manually target cones at wherever I'm operating at. This is not a big deal, I'm just explaining it in more detail as I remember that I was really surprised when I learned that active vessel would only establish a direct connection and not just act as if the dish was just aimed at the active vessel (i.e. cone targeting). As a side note: I'd love to have even directly targeted connections work with a cone, because in reality they would. You just point the dish in some direction, if a signal comes from that direction it'll be received (provided it's the right frequency and stuff, but we don't model that [yet?] ). But I can understand how that would probably start causing performance problems on large or huge networks, especially with the fixed cone behavior giving more potential targets. Finding connections and routes for signals should stay relatively cheap, the game has enough stuff to do after all... My second issue isn't one: On the page before my post someone said it didn't work outside SoI, so I took their word for it (as I haven't used it since the 1.x days and thought it might've been changed since then). Sorry for that... I did try to look this stuff up, but the wiki is still under construction it seems and I didn't find anything about it... Sure thing. I've corrected and refined the text a bit and posted it to that thread. I really hope it'll find some use or at least provide some inspiration, as we do need a way to actually diagnose a problem. It might also be helpful having access to target lists (or a visualization of targets) set for any satellite from the map. I've added a paragraph to the end detailing that idea a bit more. @Everyone: please do go to that thread and add your ideas, a bit more attention from users might make the devs take a look at it sooner

I'm not yet aware of any changes that are already coming in that respect, but can I suggest adding consistency to Active Vessel a priority? Most problems with RT2 posted here (or anywhere else) have to do with this feature. I agree with those that say it has it's uses, but at the moment the actual use cases are extremely limited due to its limits, which are neither obvious nor explained (or warned about) in the UI. Part of the problem is also that it's not very obvious why a certain link is (or is not) active when looking at the map, the/only primary tool to diagnose a network. A player controlling a probe/sat currently above the Mün - intended as a relay for crafts in it's shadow - can see the connection to their main network around Kerbin, because those satellites have AV as a target. As far as I know there is no way to see why the connection is made (is it targeted? inside a cone? due to active vessel?). Once he switches to the vessel behind the Mün - which would now need that relay - he get's no connection and doesn't know why. He's not told "Active Vessel: no line of sight", "Out of range" or anything else along those lines. All this could be in a tooltip (if KSP allows that) or drawn as text next to satellites (with a new button in the lower-right corner to toggle this). As a more minimalist and less intrusive alternative, color-coding the relay-satellite-icons (and potentially the lines to the target) could also work. Preferably with a key at the side to explain what it all means, like so: Green (normal line): Connect/Targeted' Green (dashed line): 'Connected/Active Vessel' Green (dotted line): 'Connectec/In target Cone' Yellow (normal line): 'LoS Obstruction' Yellow (dashed line): 'LoS Obstruction/Active Vessel' Yellow (dotted line): 'Connectec/In target Cone' Red: same as above, meaning 'Out of Range' Some things are also due to the actual mechanic of Active Vessel (and how targeting planetary objects works). It is severely limited in what it can do, but the idea of it has endless possibilities. From the posts just before mine (which finally made me write this out here), apparently AV only works within the same SoI (and possibly child-SoIs)? Some more wide-ranging limitations, that AV works like a targeted connection and not like a cone: I can't fly my probe to Duna where I have a small relay-network and have my main interplanetary relay at Kerbin targeting AV. It would only try to reach the probe directly but not use the relay network (which would be perfectly inside the cone when centered on the probe). Things like targeting a planet works great, unless you're in orbit around one of the moons. Why doesn't the cone include 'child-orbits', like targeting Duna checks for targets around Ike? I remember vaguely that these limits were due to performance concerns, but it seems a bit too conservative to me. Even around Jool, iterating over 5 moons should still not be an issue in that regard. This would obviously exclude targeting Kerbol, as that would needlessly check against everything... Lastly, I do hope I have my facts straight. I've been reading the whole old thread (back when it was the active one) and keep up-to-date with this new one, but that is exactly my point: these things aren't exactly that clear...

Please stop recommending specifically geostationary satellites (especially more than one), there is just no advantage compared to any other (reasonably high) orbit. The only thing that can make sense there is to have exactly one right above KSC, acting as a relay to other parts of a network, but even that is rarely necessary and just complicates everything. It's more useful with more complex setups, like having additional polar relays and the like. You don't need to be that high up to allow coverage with only 4 satellites: If you put four sats in orbit at about 1 Mm (1000 Km), they are within omni-reach of each other (distance of about 2.25 Mm, omni range is 2.5 Mm), can reach KSC easily (and at least one can always see it) and have quite a bit of room left to make sure the connection between the sats isn't blocked by Kerbin (see screenshot for all those things). As an easy to set-up approximation pick an orbital period of 2 hrs (about 1068 Km orbit or so), as this makes deployment much easier... So four trivial sats of just a core, battery and omni will already suffice to cover everything up to at least 1000 Mm equatorially. If you add just one dish each, pointing at "active vessel" you have full coverage of the Kerbin subsystem (except when actually behind one of the moons). Add a couple more and you're as flexible as you want to be, for example I generally use 2 dishes each, pointing at Mun/Minmus respectively. Here two screenshots, showing how this looks in map mode and the trivial sat described above (2 batteries, 1 probe core, 1 omni, 2 dishes, fill up with panels).

Is there any particular reason you're going through all this trouble? Why not simply have a few (4-6) satellites in a relatively low orbit? If you pick it low enough they can communicate with each other using omnis and only need dishes to reach farther out places. One will always have contact with KSC. If you really want you can setup a second ring, but it isn't even necessary... For deep space stuff you can have just two (possibly three) in a highly elliptical polar orbit (evenly spaced of course) and you'll always have contact (they'd talk to the low orbit ones with a wide-angle dish, and to 'active vessel' with some long range dish. Possibly add another few dishes to target places where you need a similar receiver network. Short version: I have no clue what the obsession with geosync for comsats is about. The only place that makes some sort of sense is to have one (and only one) exactly over KSC, but that's it.