Jump to content

Firov

Members
  • Posts

    302
  • Joined

  • Last visited

Reputation

170 Excellent

Profile Information

  • About me
    Sr. Spacecraft Engineer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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.
  3. 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
  4. 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.
  5. 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!
  6. 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.
  7. 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?
  8. 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.
  9. 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.
  10. 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?
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
×
×
  • Create New...