Firov

Hey drtedastro. What you're wanting to do actually is possible. The arrows are for moving in larger increments. If you want to set the altimeter (or any smartpart) in finer increments you can click and drag directly on the green bar. So adjust the distance to 0 meters using the arrows, then drag the green bar until it gets up to 2 meters. This is actually already possible, to a certain extent, using the "Drainex 1" auto stager. It can't detect if a resource goes above a certain level, but it is capable of detecting any resource (including electric charge) dropping below the predefined percentage. This has been asked for a couple of times, and is definitely something I will consider adding in the future once I finish fixing some of the minor issues that have cropped up and developed the intra-vessel proximity detector. I'll be honest. So far, I'm not having much luck tracking down exactly what's causing this bug. It's related to KSPAPIExtension and it's resource change tracking, but I don't know why it's causing these null argument exceptions. Out of curiosity, beyond the log messages, what actual effects are you seeing ingame, and when are you seeing them? That might help me localize the source of this particular error. Honestly, I've never had good luck trying to stage RealChutes parachutes. To confirm, I just tested it and staging it fails to deploy the chute, whether it's being staged manually by me or by a smart part. However, activating it via action group (arm or deploy), it works perfectly. Honestly, I think this may be an issue with RealChute since the stage function on SmartParts is functionally identical to you hitting the stage button. You may want to bring this up in the RealChute thread.

For some reason new post notifications from the KSP forums were being directed to my spam folder (fixed now), so I only just noticed this. Anyway, it's definitely possible to do this, but it would require a pretty extensive rework. When I created this, I never imagined anyone would want to do intra-vessel proximity detection. Right now proximity sensors will only register themselves on the global list if there's not already an entry for that vessel on that channel. Furthermore, as you've noticed, the position used for this is the vessel's CoM, not the CoM of the proximity sensor. I think it's possible to get the position of an individual part, but I'll have to look into it. Honestly, I don't think I want to make the mainline release work this way, since it likely wouldn't be quite as... user friendly, but it may be an interesting challenge to make. I honestly can't promise anything, but I'll see what I can do. This problem is, a little difficult to pin down. Per your GitHub bug report, I've fixed at least a few instances of this, but it still shows up in my latest developer build in other situations. I'm still trying to pin this one down.

Hello everyone. Version 1.6.6 is good to go. It's now compatible with KSP 1.0.4 (it technically was before, but KSPAPIExtension caused issues) and fixed the bug with the auto stager firing prematurely while set for 0% activation. It should now only fire when once the resource it's monitoring is no longer being drained (AKA the engine has stopped firing). Also, thanks to InsanePlumber, I've switched over to DDS textures, which will improve load times and reduce memory usage. Please remember to delete the old Smart Parts folder before you install the new one, otherwise it may still try to load the old TGA textures. As always, you can find the latest release at my GitHub repository below. Let me know if there are any issues! New Releases

Hey Dear Leader. It's not on hiatus. I'm working on an update now, and should have it out in the next day or two. I've just been busy lately. Note though that the problem you're experiencing is definitely a result of an outdated KSPAPIExtension.dll, somewhere. Unfortunately, even if you update the KSPAPIExtension.dll in the SmartParts folder, it will still use the outdated KSPAPIExtension.dll if it exists ANYWHERE else in your mods folder. So if you have any mod that hasn't been updated for 1.0.4, it will use it's KSPAPIExtension.dll. Frankly, as linuxguru pointed out, it really shouldn't do that. If anyone has any ideas on how I can get it to always use the latest version, I'd love to know. Anyway, what I would suggest is doing is doing a search for that file in your entire mod folder and replacing all of them with the latest version.

Sorry for the delayed responses everyone. I've been travelling for business the last week, so I haven't really had a lot of free time. Anyway... That's definitely strange. I've not been able to reproduce it. Is there any chance you can make a mostly stock (some major mods like KW Rocketry are also fine) craft that experiences this and upload the craft? Until I can actually see what's going on, it's going to be tough to fix. Thanks, I'm glad you like it. If you're using the latest version of the mod and you set it for 0% detection, it should wait until fuel is no longer being drained (AKA there is no more thrust) before staging. Do you have it set to 0%? Also, Virtualgenius. I got your craft file and I'll start investigating what's going on here. Thanks!

I'm curious. Were you still using fuel when it staged? For example, did you have a rocket motor firing? If so, then that's definitely a bug. Otherwise, it's actually working as intended. Unfortunately, due to floating point errors, the fuel sensor will actually fire at less than 1% when it is no longer draining fuel. This is done as a workaround to another bug where tanks occasionally don't drain all the way due to KSP floating point errors. In such a situation, the fuel sensor would never actually stage. I may be able to bring the stage % in a bit if it's causing issues, but unfortunately, it's going to be impossible to do away with this logic entirely, simply because of the way KSP works.

I have to admit, I've not really looked into this yet. Though, I'm not surprised that the auto fuel balancer plays havoc with the fuel detector. Depending on how exactly it works, there are all kinds of ways the fuel pump could be breaking resource monitoring. Unfortunately, the gears action group is... very finicky, and likely not something that can really be added into Smart Parts. The reason for this is the fact that the wheel deploy/retract status really doesn't have to correspond with the current status of the gear action group, so sometimes you have to hit the gear AG twice for it to properly synchronize. You've probably occasionally run into this within KSP just using the gear AG manually. As far as I can tell, 'fixing' this with Smart Parts would require iterating through all of the parts on the current craft to figure out the status of the landing gear. Doable, but... messy. You can, however, use normal AGs for gear. Thanks for the suggestion, eodh! I likely will be doing a rebalance of the SmartParts tech tree and will definitely keep this in mind. True. Though I do like to think that Smart Parts can still add quality of life improvements later in the game. Anyway, I'll not put the Smart Parts too late in the tech tree when I rebalance the tech tree. Any specific suggestions?

Okay. That's definitely strange. When you put it in a test environment with just KW and SM, let me know if you can still replicate it. In fact, if you upload the craft file somewhere, that would be even better. On my end, the fuel stage seems to work properly. Also, the fuel stager supports down the 0% (technically, <1% and no longer draining resources due to rounding errors). Anyway, definitely feel free to upload a craft file if you can replicate this. If there is a bug that's affecting your craft, I will find it and I will kill it.

The LiquidFuel detection being "unlit" isn't actually a problem. You see, that's actually a slider. The reason it's "unlit" is because LiquidFuel is just the first resource in the list, and so the slider is at the 0 position. Much like with that "Scale" slider there. However, if you leave it on LiquidFuel detection, it will detect liquid fuel rather than Oxidizer. Finally, what happens if you manually fire AG1? Do the decouplers detach as expected? Thanks.

Perfect! Thank you! I'll be sure to switch over to these in the next update. I have to admit, looking at that remarkable contraption, I'm not surprised the proximity sensor isn't working properly. It currently goes off the CoM of the vessel it is attached to. You'd need sensor to sensor detection and a lot more precision to make that work. Though, I'm curious, have you tried timers? Timers can activate/deactivate, or reset other timers. Either way though, very impressive! With the fuel detector, you can choose which resource it monitors. You should be able to set it to monitor liquid fuel if you like. As for the AG problem, very strange. Does the fuel detector actually fire? What % is it set for? Finally, what AG have you configured it to fire?

Now this is the kind of honest feedback I need! Seriously though, I'm glad you're enjoying the parts. Feel free to report any bugs in this thread, and if you have any comments or suggestions as you get more familiar with the mod I'd like to hear them. Also, as promised, I've got a new update ready to go. v1.6.5 is pretty minor, mostly just bug fixes to the proximity sensor and altimeter. You can download it here. New Releases The proximity sensor now works properly when docking as well as with multiple sensors on the same vessel, either when they're listening on the same channel or on different channels. It 'should' be pretty safe to use at this point. Still, if you run into any bugs, be sure to report them in this thread. The altimeter now ignores ASL when orbiting planets/moons that lack an ocean, and includes a toggle to use ASL exclusively. Note that the altimeter will still use AGL on oceanless planets, even if configured to use ASL, and similarly, just as it has in the past, it will use ASL when over water in AGL mode. Finally, I did a quick pass over the part configs to fix the node issue as well as rebalance the cost, weight, heat, and crash tolerance values. I'd appreciate any feedback on these tweaks.

Manux, it definitely sounded like an issue with action group corruption. No SmartPart modifies action groups directly, so if you're sure the action groups are being corrupted through no action of yours, you may want to file a bug report with Diazo on his AGX thread here, http://forum.kerbalspaceprogram.com/threads/74195 I don't use AGX myself, so I'm afraid I can't be of much help here. What you can do in the interim until Diazo has a chance to look into your action group troubles, is configure the fuel sensor to stage instead. Just make sure you have a single fuel sensor per stage and you should be good to go.

Hey Azimech. Excellent suggestion with the enabling/disabling of the sensor via AG. In fact, that's something that is fairly standard on the other smart parts, truthfully, I just forgot about it for the proximity sensor... As far as bugs go, the version you've currently got available to you has some issues with multiple sensors on a single vessel, both in single-channel configurations as well as multi-channel, as well as a problem when docking/undocking. Basically, when docking/undocking, the proximity sensor won't register or deregister itself from the global list. You can work around this by going back to the space center and returning to your vessel, which will force all proximity sensors to re-register themselves. My current dev version has fixed these bugs. As long as I don't discover any major game breaking bugs, you should have your hands on this version before the end of the day. As far as problems getting it to work, for now, make sure you have a single proximity sensor per vessel, and on the same channel. When a proximity sensor detects another vessel passing through the target distance on that same channel within range, it will fire the locally configured action. Also, right now the proximity sensor works based on distance between vessel center of mass, not distance between sensor parts. Manux, this is definitely strange. The way the fuel sensor is set up right now, it's impossible for one fuel sensor to interact with another. The code simply lacks the ability to 'fire all smart parts'. If you go through and manually fire the action groups, rather than staging, does it work properly? It almost sounds like your action groups have been corrupted. Also, another suggestion, try having only one fuel sensor per stage, rather than mirroring them across both tanks. You're using AG's, so it shouldn't matter in this case, but a single fuel sensor per stage should be sufficient here, since you'll otherwise have both sensors fire the selected action simultaneously. Is there any chance you can replicate this using stock parts and upload it somewhere? Also, out of curiosity, are you using Diazo's action groups expanded mod? I seriously doubt it, but maybe there's some strange interaction there, as the AGX integration is still a somewhat new feature. I don't use the mod myself, so it's hard to say for sure.

Hey Manux, I'm as Diazo pointed out, this is almost certainly an issue with the fuel sensor sitting on the first tank to drain on the third stage. If you move it to the last tank to drain, it should function flawlessly. Still, if you post a picture that clearly shows the fuel lines I can say for sure. I may rework the logic in the future to take into account the entire stage fuel, but that adds a whole new level of complexity. I'll have to research it a bit first. Also, it's no problem, but just for future reference, the Smart Parts mod is mostly a product of dtobi's hard work. Since then, I've gone through and overhauled the logic on a lot of the parts. The only new part that has been added recently is the proximity sensor, which I created in 1.6.0. Since dtobi's departure, I've taken responsibility for maintaining Smart Parts. That said, Diazo has helpfully added support for his action groups extended mod and created a module manager patch for KIS compatibility. On that subject, I'm still on track to release the next update this weekend, likely either later today or early tomorrow. I think I've ironed out all (most?) of the bugs with the proximity sensor (aside from it recycling the radio model, that's going to take some more time). I've also fixed the node issue with the fuel breakers, and will be enabling ASL detection on the altimeter. Before I give the *.cfg files an overhaul, does anyone have any comments on the part pricing and placement in the tech tree? I have to admit, I've not ever played the 'campaign', so I'm going to have to go off public opinion here.

That's not a bad idea, but I don't think I could work it into the altimeter. It would have to be a new part, as the logic would actually be quite... different from the logic the altimeter uses. Hmm. I'll take a look at the fuel flow breaker. It could be something was screwed up somewhere along the line. Out of curiosity, what is the exact part name, and which nodes did you flip to fix the issue in the CFG? Also, as of right now, for the next update, I'm planning to include... Some bug fixes for the proximity sensor A fix for a bug with the altimeter that Diazo pointed out affecting planets without oceans A toggle to allow the altimeter to use ASL Adjusted heat and breaking strength values for all parts And the above fix with for the fuel breaker nodes (if it's a problem) I'm hoping to have the next release out this weekend. I just need to track down one more bug with the proximity sensor. The rest of the above is easy.

That's not a bad point. I will think about adding it in as an option at some point in the future. I actually did wonder if someone would bring this up when I was writing that. I guess I shouldn't be surprised, considering this is the KSP forums. Anyway, to the best of my knowledge, it's not officially known as 'nuetronium', it is in fact more normally called 'neutron degenerate matter'. Though as I recall, degenerate matter is actually more of a gas than a liquid. Anyway, you're right. It's super dense, but is only held 'together' by the force of gravity. In this case, let's assume I am referring to the rather common science fiction trope of a super dense and strong metal alloy consisting mostly of nuetrons, as found in Star Trek, Star Wars, Stargate, and likely any other fiction with the word "Star" in it. Otherwise, it ruins the joke.

Yes, unless you're making an incredibly low aerobraking pass (how are you not catching fire and exploding?!) or have the altitude set way too high, I don't see how aerobraking could trip a sensor meant for landing. As Diazo said above, I'd suggest setting your target altitude lower. In any event, this isn't really something that can be changed at the moment due to the way the altimeter logic works. I was meaning to ask you about that suggestion. I was a bit surprised when you mentioned that was something people had suggested. In fact, the very first iteration of the altimeter actually did use ASL at all times, but that was changed as soon as I overhauled it. Right now, it uses AGL when over land and switches to ASL when it detects that its over water (AGL can actually go below sea level in KSP). Honestly, I see no real use case for going back to the bad old days of always using ASL, but if someone can make a convincing argument for adding it back in, it would be easy enough to do as an option. Ah, I see you've discovered the advantage of using solid neutronium for the SmartParts outer casing... Seriously though, I'll go through and do a pass over all of the SmartParts max temperature and breaking force to bring them more inline with stock KSP electronics. Thanks for the report!

For those who haven't noticed yet, this feature has been added as part of the latest SmartParts, starting in v1.6.0. It's still a bit experimental, but feel free to give it a try and post any feedback. It works with multiple channels out to 2000 meters, and allows triggering actions on approach, departure, or either. Like the altimeter smart part, it's also able to reset/rearm itself. In reference to Diazo's post above, this was definitely an interesting challenge to create. In the end, it turned into a bit of a hybrid of the altimeter and radio smart parts. Much like the radio, each proximity smart part registers itself to a globally accessible list, which allows easy detection by other proximity alarm parts without having to iterate through all local vessel part lists, which would add potentially crippling overhead for larger vessels (ie space stations). I also use this list to determine the channel the remote proxmity part is operating on. With this info, it's a relatively simple matter to iterate through the list and find the closest proximity sensor that's on the same channel as the local part, as well as it's distance and velocity relative to the local vessel (important for altimeter/trigger logic below). From there, I wanted it to be able to trigger actions on approach, departure, or either, while also allowing the trigger to automatically reset. That last bit is the tricky part because, as Diazo pointed out, proximity to something, be it the ground or another ship, is a constant status. With the part having the ability to reset itself, you could potentially fire the action constantly when the distance conditions are met. Ideally, you could fire at exactly the specified distance, but in practice, that's not possible due to floating point errors as well as the fact that KSP only calculates physics at a specific time interval, .02 seconds per frame, in my case. So you would almost certainly never actually hit the exact distance the part is looking for. The solution is to calculate a sliding window that scales based on the relative velocity between the ship and the target (ground or other ship) as well as the current KSP physics calculation time. The faster your ship moves, the larger the sliding window has to be in order to ensure that the action is triggered. This window is then used in conjunction with the user configured target distance to establish the endpoints of the window. If the sensor detects that it's inside of this window, it triggers the action. The next physics frame, it recalculates the window, and upon discovering that it is now outside of the window, resets the smart part so it can be triggered again when it re-enters the calculated window, assuming that auto-reset is enabled. Fortunately, I'd already worked through all of this with my altimeter smart part (after much frustration), so I was able to just copy that logic for the proximity detector with a very minor rework.

Ugh. I can not believe I did that... Good catch. I've uploaded a hotfix, version 1.6.4. Note that this may break any craft using the old part. I highly recommend removing the old proximity sensor from any craft using it and saving before upgrading. In theory, it should simply replace the proximity sensor with a radio control, but I'm not sure on that.

Good news, everyone! The reports of my death have been greatly exaggerated! Anyway... awkwardness aside, I'd like to thank Diazo for stepping up to help maintain the mod while I was away. He did an excellent job, and I'm sure he's going to continue taking an active role in it's development going forward, which I fully support and encourage. As far as my absence, truthfully, I was mostly just taking a break from KSP while waiting for version 1.0 to roll out. Now that it's here, I've prepared another official update (or six...). The big news is that I was able to implement a much requested feature... the proximity detector. Incidentally, it was a very interesting challenge. In the end, it ended up being an amalgamation of the remote control and altimeter parts. Like the remote control, it uses the concept of discrete 'channels', up to 20 in total. Each proximity sensor will listen to other proximity sensors broadcasting on the same channel, once it hits the target distance to the nearest sensor on the same channel it will activate whichever action is configured for that proximity sensor. Note that it's also able to fire actions on remote vessels, just like the other smart parts. Like the altimeter, it's capable of firing actions during approach, departure, or both. It's also capable of resetting itself. Unfortunately, because I was never able to get the original model/texture files for Smart Parts, I had to temporarily reuse the model of the remote control. I plan on fixing this, in a way that won't break vessels that use it. I just need to figure out how to import KSP models into 3DS Max. I've tested it fairly extensively, but it's still a bit experimental. As such, I wouldn't rely on it 100% for high priority missions. If you find a bug with it, please let me know. Anyway, beyond that, the timer bug has also been fixed thanks to NobodysNightmare. Furthermore, I've corrected the auto-stager bug that can occasionally prevent it from staging at '0%' due to floating point errors. As long as it's below 1% of total capacity and it's no longer drawing resources, it will still fire. Finally, Diazo's KIS compatibility module manager patch has been integrated. I still need to read through this thread to see if there are any new bugs that have cropped up, but beyond that I plan on making the fuel gauge/controller bi-directional in the next patch, which will be a boon with the addition of mining, and possibly the fuel cells. As always, you can get the official release from my GitHub page here... New Releases Changelog v1.5.2 Bug Fixes * Timer now accounts for timewarp (Thanks to NobodysNightmare) v1.5.3 KSP 1.0.2 compatibility and bug fixes * KSP 1.0.2 compatibility * Auto stager now properly activates when rounding errors result in minor fraction (<= 1%) of resource remaining in tank v1.6.0 Proximity Sensor * New proximity sensor part * Allows up to 20 individual 'channels' to monitor * Capable of firing actions on both the remote and local crafts * Will select nearest object on the same channel as target * Similar logic to altimeter smart part - fire on approach, departure, or both * Works out to 2,000 meters * As placeholder, shares model with radio. Planned to change in future. Will not break craft. v1.6.1 Version File Update * Updated SmartParts.version file v1.6.2 Proximity Detector Bug Fixes * Fixed (hopefully) bug that could prevent proximity detector from firing actions on remote craft v1.6.3 KIS Support * Added KIS support (Thanks to Diazo)

Unfortunately, no. This is pretty much impossible, because KSP "packs" vessels that are outside of rendering distance. They no longer exist as a physical entity at this point and are effectively on rails until you either switch to the craft or move within rendering distance again (~2km). There are a few mods that increase rendering distance to up to 500km, or at least there used to be, but they're a bit buggy.

Fair enough. I figured it was a longshot anyway. This would be fantastic, and definitely be a huge help as engine selection, even with KW, B9, and AIES, is severely lacking in many cases, especially for Kerbal 64k. One thing I'd love, and I know it's just a pie in the sky dream, is a minor rebalance on some of the smaller engines to bring them up a bit closer to real values, just for usability in Kerbal 64k, or other non-10x rescales. Take the real life Merlin 1D for example, which appears to be no larger than ~1 meter in diameter. It produces 620kN at sea level, and ramps up to 690kN in vacuum. The best 1.25 meter engine available between KSP, KW, and AIES is probably the KW Wildcat, producing a miserly 230kN of of thrust at sea level, and 280kN in vacuum, resulting in a maximum TWR of just over 80, compared to the Merlin's ~155. This comparative lack of thrust on the smaller engines really hurts the ability to produce useful lifters using engine clusters in anything other than stock scaled Kerbin. I actually thought my clustering days were over until I stumbled into SpaceY, and its 'Kiwi' engine. That perfect little 1.25 meter engine produces 411kN at sea level, and 455kN in vacuum, while managing a maximum TWR of ~120. Still not equivalent to something like the real life Merlin 1D, but that's fine since I know that Stockalike isn't meant for 10x rescales, like RSS. In many ways, the 'Kiwi' feels like the perfect middle-ground for a 1.25 meter engine, since it compares a lot more favorably with the larger engines in terms of thrust to diameter ratio. Unfortunately, the comparative weakness of the other 1.25 meter engines makes them kind of a hard sale. In fact, it's largely impossible to use any other 1.25 meter engine, alone or in clusters, on anything larger than stock Kerbin. Still, I know that trying to go through and rebalance all 1.25 meter engines against the Kiwi would be quite a chore. Besides, maybe you'll include some new, more powerful 1.25 meter engines in these extra configs? Either way, I do love the mod. It, combined with Kerbal 64k, makes for a refreshing challenge.

I really, really like AMD, and would love for them to succeed in the CPU product space again as they did during the wonderful Athlon 64 era... but, the unfortunate fact is, right now their processors just aren't a match for Intel at the top end, or even the mid-range now that Intel is providing at least equivalent performance per dollar with their newer I5's. Really, AMD is only competitive in the budget/low-end range, and that's mostly due to the their APUs which provide decent graphics performance for an integrated solution. Core for core, hertz for hertz, Intel processors are simply faster than AMD's best, and usually by a fair margin. Worse still, Intel's processors are vastly more power efficient too, due to Intel's serious advantage in chip fabrication technology. I'd guess that Intel is a minimum of 2.5 to 3 years ahead of AMD at this point, which is bad for everyone but Intel. At least AMD is still reasonably competitive in the GPU sector, I guess...

On the subject of all of the unused fuels in Stockalike Engine Configs, would it be feasible to remove them so that they no longer show up in the resource list? I'm mostly talking about the resources like the various "MON" mixtures, Aniline, Ethanol75, and a number of others. As far as I can tell, these fuels aren't used anywhere in the Stockalike configs, so they just clutter up the tank menu. Naturally, it would make sense to keep some "unused" resources like the lead ballast (perfect for testing payload capacity). Anyway, great work on the Stockalike configs. I can't imagine playing 64k without it.

You might take a look at the following links. The equation described is meant as a "simple" equation for determining the velocity lost, and resulting orbital contraction, during aerobraking. https://solarsystem.nasa.gov/docs/5_Forget_Aerobraking_Equation.pdf http://solarsystem.nasa.gov/docs/5_a167.pdf Note that even though these are meant to be "simple", that's simple in relative terms when compared to other means of calculating the effectiveness of aerobraking.