Firov
-
Posts
302 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Firov
-
-
Thanks, Firov!
Is there a chance the prox sensor might see an expansion in possibilities in the future?
I've been looking at the code, and it seems changing the minimum distance is easy, however I don't see yet how "target" being the vessel, changed to "part", can be done.
And something else.
The code to switch action groups seems not too difficult ... maybe if I can find the way a part's temperature is handled, you could build a temperature switch out of it?
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.
I see an exception in the Log when loading the game (doing nothing in the game up to this point):I have 7 KSPAPIExtensions.dll all identical.
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!
-
I found replacing the kspapi dill didn't sort it. Got the missing lines in right-click menu issue. Is this mod on hiatus? There hasn't been any activity fir a while now.
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...
I was using 3 basic jet engines on an aircraft at full power. the sensors where mounted on drop tanks that had fuel lines draining the drop tanks to keep the main tanks full.Would it be possible to add in a new mode that triggers at a certain fuel level (using a decimal number) instead of a percentage? Even 0.99 can be a ton of fuel/Dv.
I will test it a bit later to see if it was because I only had 2 of 3 engines going or if time warp had anything to do with it or a combo of the 2.
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.
nice mod
Thanks, I'm glad you like it.
I have the same problem, some times bosters are staged still burning. Couldn't you make the fuel sensor only triger 1 second or something after the time it reads it sould stage?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 just found a bug with the Fuel sensor: Drainex 1
I had it set to stage at the default 0%, but it staged when the tank had 0.90 fuel in it. So it really wasn't set to 0 (the percent display needs to show decimals) or the fuel detection is off.
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 found the problem (http://forum.kerbalspaceprogram.com/threads/118176-GPOSpeedFuelPump-KSP-V1-0-2) I believe its when i set the tanks to pump fuel from the outer tanks to inboard tanks and balance that it fails, I can get it to separate at 5% but nothing lower than this but have narrowed it down to this plugin
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.
i missing the actiongroup gears, maybe it can be add in the next update and maybe there is a way to get the smart parts into the groupt "command and control" it makes more sence in my opinion (and i find it easier becouse soooo many parts are utility)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.
Here's a suggestion for tech tree along with a CTT (Community Tech Tree) config:Thanks for the suggestion, eodh! I likely will be doing a rebalance of the SmartParts tech tree and will definitely keep this in mind.
I should point out that, unless you're using RemoteTech or something similar, most of the utility in Smart Parts is in the early game, before you get fuel transfer and fuel pipes and good probe cores. Put this stuff too late in the tree and you'll only get it after you cease to need it.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? -
Yes manual works and oxidiser works fine liquid fuel doesnt not sure why i am shortly going to put it in a test enviroment with just smart parts and kw and see if i can get it to work to rule out other mods. Is 5% the lowest that you can set on the slider
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.
-
When i select Liquid fuel the resource just stays unlit when I select liquid oxidiser it lights up the action group I am selecting is custom 1 to fire a decoupler I hope these explain it better
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.
-
@Firov
Please use them in the next update, if you want to.
Perfect! Thank you! I'll be sure to switch over to these in the next update.
It probably almost works! Just not yet they way I've built it :-) Debug console doesn't show any proxsens activity.
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!
Having a small issue with a smart fuel detection it only detects oxidiser and not the liquid fuel its attached to a KW tank but also doesnt fire the AG, anyone else experiencing thisWith 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?
-
Just came here to say that I absolutely love this mod. I have been using it for only about a day or so, but it is absolutely fantastic and works flawlessly. Thanks!
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.
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.
-
Post
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.
-
I want to thank you Firov, for making my dream come true!
I'm curious though which bug(s) are present in the proximity sensor. I haven't been able to get them to work yet, or I might be using them wrong. I do have an idea for a future expansion: it would be terrific if the sensors could be manipulated with action groups as well: toggles for on/off and reset. This way the building of logic circuitry can really start :-)
As I understand it works by detecting the distances to parts, not the sensor itself? Would it be possible to have it detect sensor - sensor distance, even on the same craft? That would be useful for people using Infernal Robotics. And a possibility to have a distance of 0.1m would be very useful as well.
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.
HiAnswer to you question: YES
BUT __All__ decouplers fire, not just two. As you can see in the picture from the last post. there are 3 decoupler stages. When the first one gets fired with smart parts (correctly). It also triggers the other two smart parts to fire at the same time and does not wait till the other two parts say: "Im empty fire now" wich results in the other 4 booster stages to crash into my main ship above as they are not empty.
As they all use different ag i don't know how this can happen. I assume there is some "fire all smart parts" part in the code who gets triggerd when you do som reattaching of the smart parts.
Where can i find the output.log i only know where KSPlog and Player log are located.
I hope i made it clear what is wrong. If not please ask again.
EDIT:
I just tired and removed the smart parts who got so much re and detaching and put on brand new ones but the same happens. All the decouplers fire at one even they should use different ags and in the respective ags are only two decouplers each. So i dont know what is happening.
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.
-
I attached some fuel drainers on my aspargus and the first two aps. stagings went fine. The third one however did decouple much too early. The sensor was set to 0 Percent but it decoupled at rouchly 50 % of fuel still left in the tanks.
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.
-
The short version: I have a suggestion for a smart part modification to the altitude meter - detector for current apoapsis or periapsis above/below a certain value.
Thoughs on this?
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.
Fuel flow breakers seem to have their top and bottom nodes switched, resulting in clipping and needing to pixel-hunt (depending on tank) the breaker to toggle them in right-click menu. Switching the nodes in the config fixes the issue - it no longer clips, instead sitting between the parts in the stack.P.S. Having a fuel sensor be able to trigger FFBs directly (like "trigger FFB attached to this tank") would be great for career, too - by the time I get to custom action groups, which are almost-required to use automatic longer FFBs, I no longer need to build noodle rockets where CoM shift from fuel use would be an issue.
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.
- Some bug fixes for the proximity sensor
-
I can see a couple uses for ASL triggers.
That's not a bad point. I will think about adding it in as an option at some point in the future.
Ahem. Despite what Star Trek may have told you, neutronium is not a super-strong material. It is super-dense, but it actually behaves more like a liquid than a solid. It also spontaneously evaporates at anything like normal temperatures and pressures. (Though, to be clear, 'evaporate' here means 'instantly turn into massive amounts of gas', i.e. closer to an explosion than boiling water.)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.
-
@Rohaq: I'm not sure enabling that as an option is a good idea. Because you are talking about the altimeter part triggering on an aerobrake pass, I assume you have the altitude set quite high.
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.
While we are talking about the altimeter part, I realize I have potentially mislead people. I brought over the suggestion that the altimeter be changed so it can trigger on ASL or AGL because I assumed the altimeter currently always triggered on ASL.Having looked at the code, I was wrong. The altimeter currently works off of AGL (height above ground) 100% of the time so I'm not sure this is worth changing.
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.
Here's another one, unless it's intentional: the heat settings for the controllers are still set to the old default of 3600 - which means you can de-orbit them... unattached.I noticed this when Bill dropped a Radio-GAGA he was trying to bolt to the capsule while sub-orbital - and the thing landed at KSC to be picked up by StageRecovery.
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!
-
The biggest hurdle is that action groups are one-shot and proximity is an on-going status. I would look at the altimeter part for how to handle that probably.
The other-other thing is how to handle multiple sensors. It would probably be limited to only using the closest sensor. (On that channel of course so you can control which sensors activate each other.)
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.
-
I think i caught a bug before even starting the game: has in its config file. That'll cause problems for people who use the radio!
(The description is also fragmentary; I downloaded the pack off of github.)
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...
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)
-
is there any way to get the timer/altimeter to work even when not in rendering distance?
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.
-
RealFuels deals with the resources specifically, I just use them. And yes, there are a bunch I don't use.
Fair enough. I figured it was a longshot anyway.
I'm working on a set of extra configs that will take existing engines and either rescale them for another size, or be an upgrade of the engine. This is especially helpful to people with a ton of part mods who can't get a lot of the engines (like me). But, also adds some alternate engines into the pot. And while we're here, does anyone have some suggestions? Any holes in their engine list they need filled? I'm hopefully going to limit this to Stock/NASAMission, FASA, KW, and SXT engines. Possibly AIES. That'll give enough variety but doesn't break the bank mod-wise. I've already got upgraded F1 and J2 in FASA (thrust/Isp bumps), and a smaller KW SPS engine.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.
Anyway, I'll not put the Smart Parts too late in the tech tree when I rebalance the tech tree. Any specific suggestions?
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.
Good catch.
[1.0.4] Smart Parts v1.6.6 | DDS Textures and Bug Fixes | July 5
in KSP1 Mod Releases
Posted
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.