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

[NathanKell]

Cool! That should do it.

Yes please--I've been using it as the required gimbal module for RftSEngines (one of the engine configs for Real Fuels) so it's been making those engines unusable for anyone using that mod...

[dtobi]

Cool! That should do it.

Yes please--I've been using it as the required gimbal module for RftSEngines (one of the engine configs for Real Fuels) so it's been making those engines unusable for anyone using that mod...

I'll send you the dll. Please keep it updated and replace it in your mod when I update SSE. It is still under development. Woudl you like to have the KM_Gimbal as an extra mod without smart parts and all the other stuff?

[NathanKell]

Cool! Thanks. And I've been very careful not to distribute it, just say it requires SSE/SmartParts.

Actually, if you could offer a link to the DLL only (you needn't separately compile) that'd be great, for folks who don't have memory spare for Smartparts or SSE but want to use RftSEngines and/or my (soon to be formally released) realism patch for FASA that will also use that gimbal.

[Elvaron]

Cool addon, a couple of suggestions I would enjoy

- As I wrote before, for altimeter a simple editfield into which meter numbers can be typed instead of having a pre-set list of values to chose from.

- A delay setting for fuel / altimeter parts. E.g. if I were to set delay to 5 seconds, once the trigger hits, it would count down for 5 seconds then execute the action.

- Ability to add countdown to the staging. For one, this would allow for manual delay even if above suggestion weren't implemented. For another, it would make for a nice launch countdown. You could also then add the countdown to one's staging: First stage has an engine, the tank of which has a fuel trigger that hits the next stage. Second stage decouples the spent stage and activates a countdown trigger. X seconds later, the countdown triggers the next stage, activating the next engine. Without this delay step, there's risk of catastrophic consequences This would allow for some nice multi-stage launch automation.

- Ability to display delays/countdowns on main screen would be cool.

- I've had cases where a fuel part triggered pre-maturely, subsequently staged and thus blew up my entire vessel

- It seems when set to activate stage, the empty "stage group" remains in the queue, forcing me to hit spacebar numerous times to manually execute the next stage. Not a big bug, but worth looking into?

[Elvaron]

Cool addon, a couple of suggestions I would enjoy

- As I wrote before, for altimeter a simple editfield into which meter numbers can be typed instead of having a pre-set list of values to chose from.

- A delay setting for fuel / altimeter parts. E.g. if I were to set delay to 5 seconds, once the trigger hits, it would count down for 5 seconds then execute the action.

- Ability to add countdown to the staging. For one, this would allow for manual delay even if above suggestion weren't implemented. For another, it would make for a nice launch countdown. You could also then add the countdown to one's staging: First stage has an engine, the tank of which has a fuel trigger that hits the next stage. Second stage decouples the spent stage and activates a countdown trigger. X seconds later, the countdown triggers the next stage, activating the next engine. Without this delay step, there's risk of catastrophic consequences This would allow for some nice multi-stage launch automation.

- Ability to display delays/countdowns on main screen would be cool.

- I've had cases where a fuel part triggered pre-maturely, subsequently staged and thus blew up my entire vessel

- It seems when set to activate stage, the empty "stage group" remains in the queue, forcing me to hit spacebar numerous times to manually execute the next stage. Not a big bug, but worth looking into?

[dtobi]

Cool addon, a couple of suggestions I would enjoy

- As I wrote before, for altimeter a simple editfield into which meter numbers can be typed instead of having a pre-set list of values to chose from.

Thats not possible with teh default tweakables. otherwise I would have done that. Maybe it becomes possible with a future KSP update. So long we'll have to deal with sliders (I won't go through the hassle of making my own UI, sorry. I have enough to do even without that.)

- A delay setting for fuel / altimeter parts. E.g. if I were to set delay to 5 seconds, once the trigger hits, it would count down for 5 seconds then execute the action.

You can already do that. Just trigger a timer device and let that timer device execute the action. This works well.

- Ability to add countdown to the staging. For one, this would allow for manual delay even if above suggestion weren't implemented. For another, it would make for a nice launch countdown. You could also then add the countdown to one's staging: First stage has an engine, the tank of which has a fuel trigger that hits the next stage. Second stage decouples the spent stage and activates a countdown trigger. X seconds later, the countdown triggers the next stage, activating the next engine. Without this delay step, there's risk of catastrophic consequences This would allow for some nice multi-stage launch automation.

Adding staging for the timer is on my list.

- Ability to display delays/countdowns on main screen would be cool.

Maybe this can be done. We'll see.

- I've had cases where a fuel part triggered pre-maturely, subsequently staged and thus blew up my entire vessel

Can you send me the craft file so that I can check it? Best would be without other mods.

- It seems when set to activate stage, the empty "stage group" remains in the queue, forcing me to hit spacebar numerous times to manually execute the next stage. Not a big bug, but worth looking into?

Yeah, KSP staging is quite messy. Maybe I can do something but I can't promise it.

Right now, Version 1.0 of SSE has priority, though.

And don't get me wrong: Your suggestions are very very welcome!!

Edited January 18, 2014 by dtobi

[Absolute Human]

I like this mod a lot! However, I also have some suggestions for it.

First of all, I don't want to waste anyone's time and my rules always are not to harm anybody with my wishes.

I tried to make a test flight to the Mun and back without hitting stage or any action groups and faced some problems.

So yeah, some seriously considered good ideas by me. None of them requires much changes, but they all make improvements in gameplay. Also looking forward to removing empty stages from listing and adding stage triggerable timers!

-As someone stated above, built in countdown timers for fuel level triggers will come handy instead of using separate timers for this.

Saves part count and action group space, why not to have? Seems legit to me.

-"enable after launch/at launch" option. I didn't quite get it... What does it do?

May be I am wrong, but I got it like it allows the trigger to geather information after some altitude, am not I right?

If it is like that, then why not to replace it with slider to determine this altitude? Otherwise, please explain me what it does.

-"enabled/disabled" state button switches when trigger fires.

I am the second one to point that it blocks the capability to have auto retracting/deploying landing gear.

Why not to make an option to automatically reset the trigger, when the condition activating it is no longer presented?

For example:

You are landing.

1 the Retracting trigger is temporarily disabled because you are already above 50 meters.

Ones you are lower, it starts to wait when you get above 50 again.

2 the Deploying trigger waits when your altitude is lower than 30 meters, then it fires.

You land safely and launch again.

3 When you get above 30, the Deploying trigger is set to waiting.

4 When you get above 50, the Retracting trigger fires.

You can land again, and everything will be reapeated!

I tried doing it with this version, but it is impossible, the triggers fire only once.

BTW "enable after launch/at launch" button switches too for some reason, don't know what to do with it.

-"enabled/disabled" state button is only accessed manyally.

Why not to add an ability to bind it to an action group? Adds much more possibilities. One sensors could enable/disable others, cool!

-"do nothing" option for the flameout detector.

Why? To use it with symmetrically placed engines and avoid multiple action groups/stage events or other unpredictable things.

-the last but not the least, stack attachment nodes leave rather big gaps around the model of fuel flow brackers. My OCD doesn't allow me simply to go past it. Module Manager already serves me with it, but I seriously want you to consider using new numbers, already figured by me. They are more than precise:

node_stack_top = 0.0, 0.08038, 0.0, 0.0, -1.0, 0.0, 1
node_stack_bottom = 0.0, -0.08038, 0.0, 0.0, 1.0, 0.0, 1

Pictures for better explanation:

Before-

After-

And, just in case, English is foreign language to me, so excuse me any mistakes, I hope I made myself clear.

Edited January 19, 2014 by Absolute Human

[dtobi]

I like this mod a lot! However, I also have some suggestions for it.

First of all, I don't want to waste anyone's time and my rules always are not to harm anybody with my wishes.

I tried to make a test flight to the Mun and back without hitting stage or any action groups and faced some problems.

So yeah, some seriously considered good ideas by me. None of them requires much changes, but they all make improvements in gameplay. Also looking forward to removing empty stages from listing and adding stage triggerable timers!

This is on our list.

-As someone stated above, built in countdown timers for fuel level triggers will come handy instead of using separate timers for this.

Saves part count and action group space, why not to have? Seems legit to me.

Its not strictly needed but I'll consider it. You are the second person to ask so maybe there is a demand.

-"enable after launch/at launch" option. I didn't quite get it... What does it do?

May be I am wrong, but I got it like it allows the trigger to geather information after some altitude, am not I right?

If it is like that, then why not to replace it with slider to determine this altitude? Otherwise, please explain me what it does.

If you set it then you can "disable" the condition tracking until the condition is not true anymore. Consider a altimeter part that says "fire below 100m" in order to extend the landing gears after reentry. If that part would be active at start, it would fire when leaving the launch pad. So "enable after launch means": ignore the altimeter until the condition is met the second time (at reentry, not at launch).

-"enabled/disabled" state button switches when trigger fires.

I am the second one to point that it blocks the capability to have auto retracting/deploying landing gear.

Why not to make an option to automatically reset the trigger, when the condition activating it is no longer presented?

It is a necessity. If you want to fire below 100m, it would also fire at 50, 10, ... You can add a second part that activates teh first part at a given condition (see the feature that will be implemented soon below).

For example:

You are landing.

1 the Retracting trigger is temporarily disabled because you are already above 50 meters.

Ones you are lower, it starts to wait when you get above 50 again.

2 the Deploying trigger waits when your altitude is lower than 30 meters, then it fires.

You land safely and launch again.

3 When you get above 30, the Deploying trigger is set to waiting.

4 When you get above 50, the Retracting trigger fires.

You can land again, and everything will be reapeated!

I tried doing it with this version, but it is impossible, the triggers fire only once.

BTW "enable after launch/at launch" button switches too for some reason, don't know what to do with it.

-"enabled/disabled" state button is only accessed manyally.

Why not to add an ability to bind it to an action group? Adds much more possibilities. One sensors could enable/disable others, cool!

This is already implemented and comes with the next release.

-"do nothing" option for the flameout detector.

Why? To use it with symmetrically placed engines and avoid multiple action groups/stage events or other unpredictable things.

I don't get your use case/application here. Can you elaborate?

-the last but not the least, stack attachment nodes leave rather big gaps around the model of fuel flow brackers. My OCD doesn't allow me simply to go past it. Module Manager already serves me with it, but I seriously want you to consider using new numbers, already figured by me. They are more than precise:

node_stack_top = 0.0, 0.08038, 0.0, 0.0, -1.0, 0.0, 1
node_stack_bottom = 0.0, -0.08038, 0.0, 0.0, 1.0, 0.0, 1

Pictures for better explanation:

Before-

http://i.imgur.com/fGVz4Oe.jpg

After-

http://i.imgur.com/wWVkAFV.png

And, just in case, English is foreign language to me, so excuse me any mistakes, I hope I made myself clear.

I'll change it. Thanks for the suggestion.

[Elvaron]

I don't quite get his use case either, but a "do nothing" option would be cool none-the-less.

It also gave me a new idea/suggestion. Maybe this is already possible with the existing triggers, if so, I'd love a short explanation

The idea would be to have an optional AND-logic channel (default is 0: No Channel. I don't see a use-case for an OR-logic here, but maybe someone comes up with one) and a part that goes with it. Heck, you could even just add a version of each trigger that doesn't fire any action, just broadcasts it's trigger status on a channel. Anyways, let's say you have 3 symmetric engines with seperate fuel supply. You want staging to occur when all 3 are empty, not when the first one is empty. If they for some reason don't empty at the same time, even if the difference is in the microseconds, bad things happen. So you place a fuel trigger on all 3, set them to do nothing, yet assign them to channel 1. You place a single channel receiver, set it's action to stage and it's channel to 1. When all triggers broadcasting on channel 1 (I guess you'd iterate the vessel parts at launch and put them in a vector. If a part gets detached from the spacecraft it is ignored.) have switched to true (condition met at some point) it executes the action, in this case it detaches the stage with the 3 symmetric engines once all 3 are empty.

You'd even get some nice combo effects. Say you have a trigger that fires pretty much at start and a trigger that doesn't really fire at all (say under 4km while disabled during launch and the use case is relevant much before re-entry). You'll get a true and a false on that channel so a channel receiver wouldn't fire.... Until the trigger that evaluates as false gets detached from the ship thanks to staging. The use case for this is, of course, activating an action group with parts that aren't on the staging queue, or else there wouldn't be any point

As for the altitude trigger and your response: I see, that's unfortunate. Could we maybe get more options than just Meters and Kilometres? This plugin is perfect for re-entry scheduling, yet the altitude trigger has no values in the range between 100m and 4km.

[asdfCYBER]

some suggestions: a tank-is-full trigger, or a that-amount-of-kethane/electricCharge/whatever-is-reached trigger. It would be nice to get an automatic kethane farm, or self-deploying solar panels

[Absolute Human]

Its not strictly needed but I'll consider it. You are the second person to ask so maybe there is a demand.

The reason of me saying that, is that stages decoupling instantaneously as the fuel tanks are empty tend to collide into things quite often.

The delay I'm talking about is something between 0 and 1 seconds, that can't be tuned with the existing timer, but doesn't replace it neither.

So, I think the ability to change the delay by tenths of a second would be nice.

If you set it then you can "disable" the condition tracking until the condition is not true anymore. Consider a altimeter part that says "fire below 100m" in order to extend the landing gears after reentry. If that part would be active at start, it would fire when leaving the launch pad. So "enable after launch means": ignore the altimeter until the condition is met the second time (at reentry, not at launch).

Oh, so, this it the "activate sensor after the condition activating it is no longer presented" option you were talking about, now I got it.

It is a necessity. If you want to fire below 100m, it would also fire at 50, 10, ... You can add a second part that activates teh first part at a given condition (see the feature that will be implemented soon below).

But now I'm somewhat confused. I thought that shouldn't be a necessity if the triggers functioned as I expected.

Lets see. You have two switches, four variants to set them up before launch. As far as I figured and with some testing:

1-"enabled", "at launch".

Means that the sensor will activate the trigger as soon as the condition appears, no difference if it was "above" or "under".

2-"enabled", "after launch".

Means that the sensor will activate the trigger as soon as the condition appears if it wasn't presented or it will wait until the condition isn't presented and then switch to "enabled", "at launch" and start to work like it.

3-"disabled", "at launch".

Does nothing

4-"disabled", "after launch".

Does nothing either.

That is rather complex and unconvenient, I suppose.

I expected the sensors to have three states: "off", "ready for activation", "waiting when the condition is not presented".

This way it they don't need any additional buttons.

If the sensor is "on" it can alternatively be in two states.

When it detectes the condition it fires and switches from "ready" to "waiting" state but not to disabled and it wouldn't "also fire at 50, 10, ...", it would fre only once, when the states switch. And then it switches back to "ready", when the condition ceases. Is it what you want to implement in the next version? It makes much sense. In fact it eliminates the need in second button, one "on/off" is enough. May be a button could be used to block firing a trigger again, but nothing more. Am I wrong?

I don't get your use case/application here. Can you elaborate?

Actually, never mind, I understood that it wasn't really necessary, I was trying to make something to avoid colliding with decoupled stages and had some strange ideas

Oh! And one more thing, I tried landing on water a minute ago and it says "alt = -1" and fire all "Lower then x" triggers.

Edited January 21, 2014 by Absolute Human

[dtobi]

V0.3 Fuel Valve and Detail Improvements

* Activation and deactivation action group commands for altimeter and fuel detector

* Beep command to beep when a condition occurs

* Fuel valve to drain excess fuel

* Staging for the timer

* Improved fuel drain detection (should not fire prematurely)

I addition: I would like to welcome Firov as an additional author.

Edited January 23, 2014 by dtobi

[Absolute Human]

You have accidentally copied "description = " twice in the config file of some fuel brakers, just letting you know:

// --- editor parameters ---
TechRequired = composites
entryCost = 5800
cost = 200
category = Utility
subcategory = 0
title = Fuel Flow Breaker 3.75m
manufacturer = Klockheed Martian
description = description = Can stop or enable the fuel flow between two tanks or between a tank and an engine. Control it by action group or context menu. Use this to control your CoM.

// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision
attachRules = 1,0,1,1,0

Another thing, the fuel controllers don't have TechRequired and Entry Cost parameters and thus are unavailiable in the career mode:

     
    // --- editor parameters ---
    cost = 30
    category = Utility
    subcategory = 0
    title = KM Fuel Controller - Default Off.
    manufacturer = Klockheed Martian
    description = Can be used to control the fuel flow of fuel lines. Attach this to the source tank and attach a fuel line to it. Turn it on and off via the right click menu or action groups. Off by default.


    // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision
    attachRules = 0,1,0,1,0
    node_attach = 0.0, 0.0, 0.028, 0.0, 0.0, -1.0, 1

I also have some more precise numbers for your flameout detector if you don't mind:

node_stack_top = 0.0, 0.159, 0.0, 0.0, -1.0, 0.0, 1
node_stack_bottom = 0.0, -0.159, 0.0, 0.0, 1.0, 0.0, 1

"Fixed fuel sensors", you say? This way may be nobody will now want staging delays for them

Still don't see any reasons why not to implement altimeters capable of multiple activations, should be rather doable if they had two "on" states instead of just "cocked" ("cocked", really? Google Translate says me that it is translated as "cocked", but reverse translation disagree with that ) and "fired"

[Andersenman]

I am curious as to the scope of this mod. Obviously there are several limitations that come into play: There are only a few distinct modules (which is cool), only limited space on a craft to place them, and limited action groups to link them all together. On the other hand there are requests for quite a few functions that at first look could result in potentially unwieldy Tweakables menus (eg. a timed altimetric fuel-metric stager). I could imagine that at some point a particular feature request results in "Sorry, but that's beyond the scope of this mod".

At least that's my chain of thought whenever I play with this mod.

Also, alternatives to 'cocked' would be 'armed' or 'primed'. 'Cocking' is usually associated with trigger mechanisms in guns, isn't it?

[Wahgineer]

Also, alternatives to 'cocked' would be 'armed' or 'primed'. 'Cocking' is usually associated with trigger mechanisms in guns, isn't it?

Yeah, using armed/primed instead of cocked is more correct, and also doesn't allow for crude jokes.

[Firov]

I am curious as to the scope of this mod. Obviously there are several limitations that come into play: There are only a few distinct modules (which is cool), only limited space on a craft to place them, and limited action groups to link them all together. On the other hand there are requests for quite a few functions that at first look could result in potentially unwieldy Tweakables menus (eg. a timed altimetric fuel-metric stager). I could imagine that at some point a particular feature request results in "Sorry, but that's beyond the scope of this mod".

At least that's my chain of thought whenever I play with this mod.

Also, alternatives to 'cocked' would be 'armed' or 'primed'. 'Cocking' is usually associated with trigger mechanisms in guns, isn't it?

This is actually a good point and while I've toyed around with the idea of one universal part, the fact is it's simply not feasible within the current constraints of the tweakables system. It would just be too unwieldy. I'm afraid we'll all just have to deal with a multitude of smart parts until Dtobi or myself can think of something better.

That said, my next objective is the overall improvement of the altimeter, primarily to fix bugs such as the -1 over water problem, but also to improve accuracy and probably add another unit scale, perhaps decameters, as someone requested.

As for a request that keeps popping up in this thread, I'd actually really like to implement a system so that it triggers "at" the set altitude rather than "above" or "below" and is capable of automatically resetting. I see the use for this in, for example, having a single altimeter that can extend or retract a RemoteTech antenna at a set altitude, or control landing gear for both takeoff and landing. Both of which would be useful for either reusable landers or spaceplanes. It's sort of possible to achieve this effect with 2 altimeters, but even then they don't really reset.

The first version I came up with when creating an altimeter that could handle high altitudes actually had that ability, and would deploy within a set distance of the target altitude. Overall it worked reasonably well, but it did have a problem in that at extremely high vertical velocities (~500 meters per second) it could blow past the defined target window (~3.5 meters) faster than the game could recognize it, thus missing the trigger point. I have some ideas on how to fix this, such as scaling the size of the window based on velocity and switching over to OnFixedUpdate(), but at this point it's too soon to promise that I'll be able to get that working.

[Mokmo]

Came here to make suggestions, i see one (action group to activate/deactivate detection on altimeter part) and as another user had suggested, something to act in case the electric charge gets over/under a certain level.

[dtobi]

Regarding the scope. Originally it was made to make shuttles easier to handle (fuel controllers, empty tank detector for external fuel tanks, ...) I found that tying that all together via action groups worked really well and so more action group devices were created. I tried to create distinct tools where each solves one particular problem.

The fun part is that the collection of parts adds a new aspect to the game: planning actions and behaviors before launch.

As long as something fits that scheme, I am fine with doing it.

Space is hardly a problem, even for probes. Aesthetics may be a problem. That is why I tried hard to make these parts as good-looking as possible. It is entirely possible to just put every function to one single part and I have been thinking of things like a slot concept where you just add something like extension cards to a main module. For now, I think the separate parts are OK. Should the number of parts keep growing (maybe with Firov's help) we might consider switching to something else. As Firov said above: the focus is currently on getting the best user experience out of the current set of functions.

[Tassyr]

I just wanted to say that this is, so far, one of the single most useful mods I've run into! Keep it up!

[dtobi]

A new update is out. Thanks to Firov for his work to improve the altimeter!

Please note: Delete the old folders and replace the altimeters on your saved ships in the VAB.

V0.4 Improved fuel sensor, valve and altimeter

* The stager now works with any resource (including electric charge and custom resources)

* The valve now works with any resource (excluding electric charge). Other resources (e.g., real fuels should work, too.)

* Removed double word in descriptions

* Tweakable added to allow removal of timer staging icon

* Altimeter altitude detection logic tweaked. Now works over water and buildings!

* Altimeter no longer requires specifiying if it fires "above" or "below"

* Altimeter now supports automatic reset as a result of above change

[Firov]

It's mentioned above, but I'd just like to reiterate that you'll want to replace any altimeters on saved ships with the new and improvedâ„¢ altimeter part. Since the logic and even variables changed so much from the old altimeter part (it's basically a complete rewrite) using old parts is going to result in all kinds of oddities, most of which surely won't be pleasant. Also, I'd welcome any feedback on the altimeter or suggestions on possible improvements.

Also, just one other other minor clarification on the above patch notes, as some of you may have realized, true staging was added to the timer part in v0.3. In v0.4 I improved upon that by allowing you to remove (or add) it's staging ability(and icon) with tweakables at which point it operates just like the old timer.

Anyway, that's it on my part. I hope everyone enjoys the new parts. If you run into problems or have suggestions on new features or parts, I'd like to hear them.

Edited February 7, 2014 by Firov

[SirusKing]

Does the fuel valve work on all resources, or just fuel?

[dtobi]

Does the fuel valve work on all resources, or just fuel?

Yes. All but electric charge.

[boywithumbrella]

I have a suggestion / request:

a part that would trigger action groups based on speed (preferably in mach instead of m/s). Point is, I'd like to automate increasing/decreasing flap deflection (for use with FAR) based on airspeed.

EDIT: a bug(feature?) I noticed: the Altimeter allows to select any action group but gears. The Selection goes from Stage through Custom01-10 to Light, RCS, SAS, Brakes, Abort, Beep - is there a specific reason why Gears wasn't included (in case it's deliberate)?

Edited February 9, 2014 by boywithumbrella

[Firov]

I have a suggestion / request:

a part that would trigger action groups based on speed (preferably in mach instead of m/s). Point is, I'd like to automate increasing/decreasing flap deflection (for use with FAR) based on airspeed.

EDIT: a bug(feature?) I noticed: the Altimeter allows to select any action group but gears. The Selection goes from Stage through Custom01-10 to Light, RCS, SAS, Brakes, Abort, Beep - is there a specific reason why Gears wasn't included (in case it's deliberate)?

Good catch. Though this was actually something I was aware of. In fact, no smart part can directly activate the gear action group. When I asked Dtobi about it he mentioned that he experienced problems in getting the gear action group to fire properly when he first created the mod, and so dropped it. This is actually something you have probably already experienced, if you've ever had to hit the gear key twice for it to actually do what you want.

I have some ideas on how to get that fixed, but I was too busy with the altimeter and timer improvements to really look into it for the last release. I may have something for the next release, but at this point it's too early to make any guarantees, since it's really a bug with stock KSP.

For now, I'd just assign your landing gear to an action group and use that.

Edited February 9, 2014 by Firov