[1.0.4] Smart Parts v1.6.6 | DDS Textures and Bug Fixes | July 5

[Diazo]

@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.

So how is the altimeter part supposed to handle it when you enter on your final pass to land, but you are still going fast enough when you pass your trigger altitude that your status is still ORBITAL, then 15 seconds later, your status becomes SUB-ORBITAL but well below your set trigger altitude?

Rather I'd argue this is a case for activating/deactivating the timer so it only triggers on the last pass. This can be done on the "Active" field in the right-click menu, or via action groups as the timer has both an enable and a disable action available.

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.

D.

[Firov]

@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!

[macdjord]

I can see a couple uses for ASL triggers.

For instance, things like ditching stages or deploying drogue chutes during reentry. Those are things that you want to at a certain stage of your reentry sequence, i.e. at a certain point in the atmosphere. You want to fire drogues when the atmosphere is thick enough to have slowed you down so they won't get ripped off, but still high enough for them to slow you down and orient you before the mains fire; it doesn't make sense for them to go off earlier because there happens to be a mountain under you at the moment, especially since at that point you're still high enough up that the altitude of the terrain under your vessel now has nothing to do with the altitude of the terrain you'll actually be landing on.

Alternately, if you're firing a suborbital sounding rocket, you want the experiments to trigger as soon as you are out of the atmosphere, i.e. 70km ASL.

... actually, now that I think about it, with the exception of firing parachutes just before landing, every task you might want an altitude trigger for is better served by ASL triggers than AGL. (Well, you might want AGL triggers for some things in the early stages of a launch, but that's a wash; you launch from a constant altitude, so you could just use ASL triggers and add 67m to everything.)

Ah, I see you've discovered the advantage of using solid neutronium for the SmartParts outer casing...

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.)

Edited May 12, 2015 by macdjord

[Rohaq]

It's possible to approximate aerobraking before hitting the atmosphere to determine whether you'll eventually hit the ground, though this has been made more complicated by the new aero model.

As for not exploding: Heat depends on your velocity moving through the atmosphere; I can usually aerobrake coming back from the Mun at about 45km to reduce my Ap considerably without exploding, and lower my Pe by 5km at the new Ap to reduce it even further, since I'm moving more slowly through the atmosphere at the new orbit means a lower aerocapture is possible.

But coming in for the final aerobrake capture, I'd like to jettison my service modules upon hitting the atmosphere. Even in the unlikely event that the reduced mass/surface area affects the aerobraking, and I miss the ground, I'd at least still get captured on the second run.

[Firov]

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.

[SpaceNomad]

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.

To add a few more reasons for ASL: Enabling/disabling RemoteTech antennas and dropping fairings on ascend also don't care about where the ground is, but about how high in the atmosphere you are.

[Tivec]

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.

The long version: I have a couple of launchers that I reuse for different payloads. I try my best to not leave debris in LKO, but depending on payload weight I tend to sometimes have a little bit extra left over on the lift stage. With my addition implemented, I would be able to trigger an action group (or stage) when my periapsis reaches above 10km, allowing for the lower stage fuel valves to kick in. For my launcher, this would result in the lower stage engine shutting down due to lack of fuel, and staging can be initiated. The upper stage will now only need to spend a few m/s delta-v to finish circularizing, while the lower stage tumbles through the atmosphere and burns up.

Thoughs on this?

[Barhandar]

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.

Edited May 14, 2015 by Barhandar

[Firov]

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.

[Diazo]

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.

I know what is going on here, KSP 1.0 changed how attach nodes work and the part.cfg files need to be updated.

I'll get this in to the next update.

D.

[Barhandar]

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?

All four Fuel-Breakers (kb-fuel-breaker1, kb-fuel-breaker15, kb-fuel-breaker2, kb-fuel-breaker3) and changing sign on 1.0 value - config says it's "Up X" - of node_stack_top with node_stack_bottom. It adds pixel-hunting during construction, as with most two-node thin parts (surprisingly stock stack decouplers are not affected despite having nearly same values), but it's more than compensated by not needing to pixel-hunt as severely as with clipping during flight.

[ManuxKerb]

Hi Diazo,

I finaly got aroud to test your new parts!

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.

Craft fiele is here: http://s000.tinyupload.com/index.php?file_id=27769332334179157130

I also changed something after i attached the parts. I hope this is not a problem and the "forget" bug is not showing its face again :-)

Thanks for looking into that :-)

Edit:

Just to clarify: The sensors are on all 3 tanks on the top one of two. But this does not seem to be an issue on the first two decouplings/tanks. There is also the top tank drained first and they dont decouple. But the last one in the aspargus does on the empty top tank.

Edited May 16, 2015 by ManuxKerb

[Diazo]

Okay, I can't open the craft file because it has non-stock parts.

However, the 3rd stage going early at 50% is interesting. Can you double check that the sensor is attached to the last tank to drain in the stage?

The Fuel Sensor triggers when the percentage on the tank it is attached to is reached, not the stage it is attached to.

I'm assuming you have fuel lines in the asperagus setup and that they are doing something odd to your fuel flow.

The test would be to open the right-click menu on the tank the Fuel Stager is attached to and see what KSP thinks is left for resources in that tank, that should match the setting in the Fuel Stager when it triggers.

D.

Edited May 16, 2015 by Diazo

[Firov]

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.

Edited May 17, 2015 by Firov

[Azimech]

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.

Edited May 17, 2015 by Azimech

[ManuxKerb]

Hello Firov,

Here is a picture: http://postimg.org/image/xosxstqhd/

As you can see on all the aspargus tank-setups (1 setup = 2tanks) the sensor is on the top tank.

So i understand that it should fire when the tank it is attached to is empty.

However the first two decoupers get fired by ag when _all_ the tanks of this staging are empty and not only the top one where the sensor is attached to. But the last group (number 3, staging no 7) gets fired when the top tank is empty (as it should).

I hope i explained it clearly enough :-)

Thanks

[Diazo]

@ManuxKerb: The test needed to see is to right-click the tank so you can see exactly what KSP is reporting for the amount of fuel the tank has left when the Fuel Stager fires.

Looking at the picture, I think everything is working as intended, this issue is a quirk of how KSP handles fuel flow.

On the asperagus stages, you have the fuel lines connecting the top tanks. Because an engine draws fuel from the tank farthest away from it that it can (by part count, not physical distance), this location of the fuel lines means that while the engine in that stack is drawing fuel from the top tank as intended, the engines being fed by the fuel line are drawing from the bottom tank. Therefore on your early stages, the bottom tank is in fact draining first.

Then once you drop enough stages, there are no longer enough engines drawing fuel via the fuel lines and so on those later stages the top tanks are draining first. This would explain the behavior you are seeing.

The one catch is I can't actually tell for sure this is the issue from the just a picture, but it is my best guess.

D.

[ManuxKerb]

Hi

Ok now i put the smart parts on the bottom tank (on the first two) and they just decouple way to early! So i put them back how they where. (the first two on the top tanks. last one on the bottom)

What happens now is: when the first stage is empty it decouples but not just the one it should. All of the smart frt fire and everything decouples!

Note that i did not change anything in the config of the parts. I just replaced them a couples of times.

Edited May 17, 2015 by ManuxKerb

[Diazo]

Okay, let's stop speculating.

I assume you have several seconds between stages to do this test.

1) On the pad, right click the tank the Fuel Stager is attached to. Note the Liquid Fuel resource display in the bottom of the window that opens.

2) Launch and then note when that Fuel Stager fires. (The right-click part window should stay open.)

3) Repeat for the rest of the Fuel Stagers in your rocket.

Now, does the amount of LiquidFuel in the right-click menu of the fuel tank match the setting on the fuel stager when it fires?

If it does, it is a KSP fuel flow issue and nothing we can do about it. If there is a mismatch then that is in fact an issue with the Fuel Stager we would have to track down. Notably the output_log.txt would be a big help.

D.

[ManuxKerb]

Hi

Answer 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.

Edited May 17, 2015 by ManuxKerb

[Diazo]

Odd.

Can you upload the current version of your .craft file? I won't be able to load it but I can look at the raw data and see what the Fuel Stages are saving for their action group.

That will help narrow down where the disconnect between what you are seeing on the screen is and what is actually happening.

D.

[ManuxKerb]

Hi

Unfortunatelly i did not save it and removed the parts so i can actually play a mission to minmus. When this is finished i will reattach and post the file if it is still happening.

[Firov]

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.

Hi

Answer 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.

[ManuxKerb]

Hi

I use only one per stage.

Now it happend again. One Smart part in the booster fired and then all other smart parts did also fire wich basicly disassebled my craft mid flight.

I did build a new craft with new sensors. But i can report, that i worked the first time i flew the vessel. But due do design flaws i needed to launch a new one which then showed this behavior.

It could be that the AGs are messed up. I use AG extension from Diazo.

Here is the craft file: http://s000.tinyupload.com/index.php?file_id=01556781223590476364

EDit:

Ok i can confirm that the AGs are getting messed up. When i made them i hab only two decouplers in one ag but after the lauch of this second vessel now there is everything in all definded action groups. So basicly they mixed all the seperate action groups into one big one and then put this big one in all definded action groups. So if i press "1" all the definded stuff in every action group will be activated.

Edited May 17, 2015 by ManuxKerb

[Firov]

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.