[1.12.5, 1.8.1] ASET Consolidated- Avionics, Props, & IVA Packs (adopted)

[Stone Blue]

3 hours ago, Hippodingo said:

Is there something more to do than just adding the kOSTerminal in the space?

uhh.. *possibly*...
In some recent investigations into *other* stuff, it appears there might be some issues with the kOSTerminal even fully working.
I already have several other "irons in the fire", so I dont know how much/when I can help with this prop, if there *really* are issues with it.

On a side note, i just found at least a couple of older mods, that seem to be doing, or close to doing, what you are talking about, with having an interactive kOS autopilot... i dont kknow if you kknow of them, so:
 

 

EDIT: just saw *your* edit while I was posting.. lol

yeah.. thats part of what I was talking about... there are seperate PAGE definition files that go along with the kOS Terminal and the kOS MFDs...
There may be some ModuleManager patching issues, that may be affecting whether the MFDs work or not... also, as I noted before, if you're trying to use the *big* kOSTerminal, that has a full alpha-numeric kkeyboard on it, I guess most of the 85 keys/buttons on it arent hooked up for use, so do nothing when clicked? vOv from what I understand without poking it closer, I gather neither RPM nor MAS, have *their* code finished to fully utilize the prop vOv, so it would be on the RPM & MAS devs to take care of that part of it.

Edited March 17, 2023 by Stone Blue

[Hippodingo]

4 minutes ago, Stone Blue said:

In some recent investigations into *other* stuff, it appears there might be some issues with the kOSTerminal even fully working. 

No problem, I am going to see what I can do myself

5 minutes ago, Stone Blue said:

On a side note, i just found at least a couple of older mods, that seem to be doing, or close to doing, what you are talking about, with having an interactive kOS autopilot... i dont kknow if you kknow of them, so:
 

I knew the 2 first ones (I needed the kOS to AA interface to make Baker nearly work) but not the last one! Thank you

[Stone Blue]

5 minutes ago, Hippodingo said:

No problem, I am going to see what I can do myself

Excellent!... i didnt want to discourage you And if you find out about things that *do* or do *not* work with any of the kOS MFDs/Terminals, pleeze!, document & let me know.. either here, or post an Issue on the Github repo. It could help us all figure out what is/is not working, and why

Also, in case you do Discord, kOS Team has a pretty helpful/knowledgable Discord server

Edited March 17, 2023 by Stone Blue

[Hippodingo]

22 minutes ago, Stone Blue said:

Excellent!... i didnt want to discourage you  

You didn't!

The simple SAS script makes me think that I could interact with kOS through action group buttons, I am going to try something!

I am already on the kOS Discord, they helped me finding how to interact with Atmosphere Autopilot with kOS

Edited March 17, 2023 by Hippodingo

[10-gui]

Hey guys,

hope I’m doing this the correct way (I may have asked the same question in a different thread… sorry for that…)

I’m desperately trying to make a mod/ or find a way to have the MFDs in separate windows…

For context, I’m building a big big scale simpit for ksp, and absolutely need to run what’s happening on the IVA’s MFDs in separate windows…

I’m not that good with code, so its a struggle…

please please help 

Thanks !

(again sorry for postin in a different thread, I’m trying to get used to the forum  )

[Stone Blue]

Minor update released:

ASET Consolidated *Avionics* Pack

2023-04-13

v3.0.1

- Changes:

  - Converted all pngs to dds
  - Fixed a bunch of possibly semi-important typos in several .cfgs

Github
SpaceDock

& CKAN

[Buzz313th]

Hey Stone,

Was curious if would be possible to have an option in the IVA's that remove the scansat dependency to see a map on the MFD's?  I am right in the middle of a save that I started using only the stock kerbnet maps and would prefer to get the full functionality out of your MFD's without having to start using scansat.

 

Cheers 

[Stone Blue]

3 hours ago, Buzz313th said:

Hey Stone,

Was curious if would be possible to have an option in the IVA's that remove the scansat dependency to see a map on the MFD's?  I am right in the middle of a save that I started using only the stock kerbnet maps and would prefer to get the full functionality out of your MFD's without having to start using scansat.

Thanx for the post & suggestion... yeah, it does seem a little odd Kerbnet isnt already supported, but that would be an RPM/MAS thing.
And IIRC, RPM was in a long hiatus period, while MOARdV was switching over to developing MAS, and that may have been during the time stoc Kerbnet got added, so maybe support just never got considered vOv

I *have* asked JonnyOThan (current RPM dev), about it... I'll post back with his thoughts on whether its something he wants to look into adding or not.

[JonnyOThan]

Hey all, (relatively) minor update for ASET props:

Changes

• Merged meshes in many prop models to improve performance
• Added science and IRC pages to MFDs. Get the IRC mod here
• Fixed zoom buttons on docking port pages

[kurgut]

Hi ! 

Is it possible to change the ASET Resource_Display prop, so instead of displaying liquidfuel, it would read another ressources ? like lqlHyd, or some realfuels propellants.

I looked in Resource_Disp_CUSTOM.cfg, it seems it's defined here (for LF for instance) :

// LF
RPM_MATH_VARIABLE
{
   name = RESOURCE_DISPLAY_LF_STAGE_10
   operator = MULTIPLY

   sourceVariable = SYSR_LIQUIDFUELSTAGE
   sourceVariable = 10
}

RPM_MATH_VARIABLE
{
   name = RESOURCE_DISPLAY_LF_TOTAL_10
   operator = MULTIPLY

   sourceVariable = SYSR_LIQUIDFUEL
   sourceVariable = 10
}

Is this editable directly to whatever fuel I'd like ? Or is it something the plugin needs as is, and thus non changeable ?
(same question applies to others retro style analog gauges for ressources)

thank you !  

Edited July 2, 2023 by kurgut

[JonnyOThan]

4 hours ago, kurgut said:

Hi ! 

Is it possible to change the ASET Resource_Display prop, so instead of displaying liquidfuel, it would read another ressources ? like lqlHyd, or some realfuels propellants.

I looked in Resource_Disp_CUSTOM.cfg, it seems it's defined here (for LF for instance) :

// LF
RPM_MATH_VARIABLE
{
   name = RESOURCE_DISPLAY_LF_STAGE_10
   operator = MULTIPLY

   sourceVariable = SYSR_LIQUIDFUELSTAGE
   sourceVariable = 10
}

RPM_MATH_VARIABLE
{
   name = RESOURCE_DISPLAY_LF_TOTAL_10
   operator = MULTIPLY

   sourceVariable = SYSR_LIQUIDFUEL
   sourceVariable = 10
}

Is this editable directly to whatever fuel I'd like ? Or is it something the plugin needs as is, and thus non changeable ?
(same question applies to others retro style analog gauges for ressources)

thank you !  

Yeah, you just need to use the name of the resource in the variable.

[JonnyOThan]

ASET Props 2.0.6 just released:

# Changes

* Missed a SCI/COMM label replacement
* Fixed IndicatorCircular and IndicatorAdv meters (revert batching change)
* Changed font textures to .truecolor so they don't get blurry when the texture resolution isn't set to full

[nwillard]

I'm Commander Willard, and this is my favorite Mk1 Cockpit mod on CKAN.

[cyberKerb]

Hi @Stone Blue - thanks for picking up all of the ASET prop and IVAs, you are awesome to keep these masterful pieces of work from @alexustas

 

Diving back into IVA for KSP1, I found a small display issue on the Mk1 LanderCan retro IVA - Not the IVA thought - looks to be a base issue in the Resource Quantity prop

The Resource Quantity numeric display (Resource_Display/ RES_DISP_ModeSelector) shown on the left panel (has a dial to select between Off, Chrg, L/F/Oxid,Xenon) has an issue with the display order and content.

The text characters (8888888.8) are always shown, the value of the resource is then shown over the top and then finally the decimal point is rendered last covering a tiny bit of the digits.
It seems it's something to do with the colors assigned when displayed - I'd guess the 8888888.8 is meant to use the dull ZERO color to represent unlit segments of the numbers.
The Altitude display seems to work the same and have no issues.

Edit: I thought I found something that would fix it:
within the file:   GameData\ASET\ASET_Props\Instruments\Resource_Display\Resource_Disp.cfg
change Line36 to the following with a few extra lines:

positiveColor = COLOR_ASET_NUMINPUT_DISPLAY_ZEROCOLOR    
zeroColor = COLOR_ASET_NUMINPUT_DISPLAY_ZEROCOLOR
negativeColor = COLOR_ASET_NUMINPUT_DISPLAY_ZEROCOLOR 

I later installed ResIVA (you get the white 888888 issue whether or not it's used) and found that it was better to just hard code the default text colour from the ResIVA patch into the default colors file of the ASET props. I couldn't find any other props that use that color identifier

By changing the file: GameData\ASET\ASET_Props\GLOBALS\AsetDefaultColors.cfg it made all the 7-Segment displays to the same green as used in the DSKY (Timers / Mission Time / Stage number, etc..)

ASET_NUMINPUT_DISPLAY_POSITIVECOLOR  0,255,0,255
ASET_NUMINPUT_DISPLAY_NEGATIVECOLOR  0,55,0,255
ASET_NUMINPUT_DISPLAY_ZEROCOLOR      0,0,0,255
ASET_NUMINPUT_DISPLAY_GHOSTCOLOR     0,255,0,90

I couldn't find a way to change the layer / render order or transparency for the decimal point. 

Edited January 31 by cyberKerb

[JeromeHeretic]

In Mk1 lander can is also non functional switch on altitude display. Switching between altitude and radar altitude is not working.

But i wanted to ask why is not in ASET avionics any navigation for Desert airfield? There's no VOR, no directional navigation, no glide slope navigation.

I was looking if is possible easily add at least VOR, to be able to find airfield by navigation instruments, but as i was looking i noticed, that i absolutely don't understand it at all, so i give up.

Will be nice have it. That runway is realy short and is pretty hard land on it even with normal aircraft, land on that with big aircraft or with a shuttle is without instruments almost impossible. (And this runway is good for landing from polar orbit, because is in north south direction...)

[cyberKerb]

On 2/2/2024 at 9:08 PM, JeromeHeretic said:

In Mk1 lander can is also non functional switch on altitude display. Switching between altitude and radar altitude is not working.
<snip>

For the "non functional" switch, it is actually functional  (I know - it doesn't seem like it on the launch pad. After you take off and get over some terrain, you'll see it updates.. slowly)
However - in the prop setup for this IVA pack, the altitude background (dark grey 888888) and decimal point  values update every 1 second, but the altitude value only updates every 3 seconds.

The update frequency looks like it can be changed on Line 87: RetroAltitudeDisplay.cfg to 10 instead of 30

For the value itself - that's the main issue for . It seems to be reading the RPM variable TERRAINHEIGHT. I'm thinking that is returning  the height from sea level to the top of terrain.
If that is the case, that would be why it's doesn't move much - and will be 0 when over water even when you are 2km over the water. "Terrain Altitude" = 0 = "Sea Level".
Having said that, I've seen the Terrain Altitude indicator show -0.8 while over the Kerbin sea... sooo, not sure how it does that - it might be an old calculated variable that is usually clamped for other uses.

My guess is that it should be pointing to the variable ALTITUDEBOTTOM (variable from RPM here).
So the suggestion is to replace TERRAINHEIGHT for ALTITUDEBOTTOM  in that Line 17: RetroAltitudeDisplay_CUSTOM.cfg file and I think it would fix this issue.
Something for @Stone Blue to correct / investigate whenever they get time.

(Also pinging @JonnyOThan in case he want's to correct something I stuffed up.
RPM has a stack of different calculated "altitudes" (ALTITUDE, RADARALT, ALTITUDEBOTTOM, TERRAINHEIGHT, TERRAINDELTA)
I might of suggested the wrong one for this prop and I can't remember which ones only work in a certain height range.

 

[JeromeHeretic]

Ah so, will check it next time. I think (at least for me), slow refresh rate is OK for me. I need it just for orientation for start retro burn of last landing phase. Under 5000 meters there's other gauge. I'm using that display only for aproximation of retro burn start. After that it's not important for me anymore, using other gauges around window.

But thx for answer...

[JonnyOThan]

@cyberKerb if you can, it would be great to get all this info into an issue on github.  It's far less likely to be lost or forgotten there.

[cyberKerb]

47 minutes ago, JonnyOThan said:

@cyberKerb if you can, it would be great to get all this info into an issue on github.  It's far less likely to be lost or forgotten there.

Under the ASET-Consolidated-Props Github:

Issue #28 lodged for the Resource Display
Issue #29 lodged for the Terrain Altitude Display

 

[JeromeHeretic]

If you are collecting bugs for next release, so on this altimeter:

 

That tiny hand, with small triangle at the end, which looks as second hand on watch is in reality showing 10 000 (feets/meters/whatewa units), long hand, which looks as minute hand on watch shows hundreds of units and short one, which looks as hour hand shows thousands of units.

So what is on screenshot should be altimetry something like a 7900 meters (because tiny shows 7000, minute shows 900 and hour hand is completely wrong,, should be around 7) , but in game it is showing 1970 meters (hours 10 000, minute 900, tiny 70).

I don't know if this is extra setup in every IVA, or it is global settings?

[cyberKerb]

6 hours ago, JeromeHeretic said:

If you are collecting bugs for next release, so on this altimeter:

That tiny hand, with small triangle at the end, which looks as second hand on watch is in reality showing 10 000 (feets/meters/whatewa units), long hand, which looks as minute hand on watch shows hundreds of units and short one, which looks as hour hand shows thousands of units.

So what is on screenshot should be altimetry something like a 7900 meters (because tiny shows 7000, minute shows 900 and hour hand is completely wrong,, should be around 7) , but in game it is showing 1970 meters (hours 10 000, minute 900, tiny 70).

I don't know if this is extra setup in every IVA, or it is global settings?

The cause of this is the ASET model labels / part names & mesh being 'incorrect'
The 'incorrect' is given in air quotes as it matches how the stock altimeter works from the AltimeterThreeHands mu model.
That issue has been around so long, and so well know, it's mentioned on the KSP Wiki and if it matches stock, is it incorrect?

(IMO it's not correct, but that's down to how I play - it's up to the mod maker / maintainer to decide, the players don't get to overrule their preference)

 

The 'fix' is to modify the ASET object names in the model

I made an attempt (only to see if it's possible) to import the model into blender 2.83 via the old 'mu' plugin.
After changing the object names and mesh names, exporting to a mu file again, it seems to work in game - but it has the side effect of inflating the .mu file to double the size
Clearly I'm not using the correct tool for the job - but it works.

This Object		Show use this data value
ALT10_arrow 		ALT1000_arrow
ALT100_arrow 		ALT10_arrow
ALT1000_arrow 		ALT100_arrow

All info in this post was added to Issue #5 raised under the ASET-Consolidated-Avionics

Noting it can't be fixed in RPM as that mod just allows you to position the stock prop without any other IVA mods installed

I did a write a small MM patch, replicating an 11 year old fix by /u/deckard58 for the stock prop to change what data is used on what hand. 

@PROP[AltimeterThreeHands]
{
  @MODULE[InternalAltimeterThreeHands]
  {
    @hand100Name = MediumArm
    @hand1000Name = ShortArm
    @hand10000Name = LongArm
  }
}

[JeromeHeretic]

39 minutes ago, cyberKerb said:

That issue has been around so long, and so well know, it's mentioned on the KSP Wiki and if it matches stock, is it incorrect?

I see, this error is old as the game itself and ASET pack just inherit it from ingame objects.

Well, in my opinion it is incorrect. When you are doing pack of gauges and trying to make it so close to reality as is possible, is incorrect, when the gauge is not working as in real aircraft (absolutely independently on rules how original ingame gauges are working).

Isn't possible do workaround by some unity config? If is possible by config just swap functionality of tiny hand (as the values comes from game engine) with funtionality of "hour hand" as it comes from ksp engine, is problem fixed. Hundred hand is ok, just somehow swap values for rest two... I'm thinking on some workaround just swap that two values without touching models (but i don't know unity.... so it's just a question).

 

[JonnyOThan]

25 minutes ago, JeromeHeretic said:

Isn't possible do workaround by some unity config?

Yeah the hands are referenced by name in the cfg files so it should be fixable with a MM patch.

[cyberKerb]

Easier option than changing the ASET model - change the ASET config

ASET_ALTIMETER.cfg
change line 23 to: controlledTransform = ALT100_arrow
Add line into 34: controlledTransform = ALT1000_arrow
change line 46 to: controlledTransform = ALT10_arrow

ASET_ALTIMETER_Adv.cfg
Line 24: controlledTransform = ALT100_arrow
Line 36: controlledTransform = ALT1000_arrow
Line 48: controlledTransform = ALT10_arrow

(added to Issue #5)

Edited February 5 by cyberKerb

[JeromeHeretic]

And what about Desert airfield navigation? As i was looking, adding new navigation transmiters is not easy. It's defined on so many places. Do you understand to it?

BTW: It was just "nice to have" idea. Is teoreticaly possible build on planet real transmiter (probe core, battery, antenna) as VOR? Let say, i will do transmitter like this, and name it VOR_115.30, si it will be automaticaly visible by ASET pack as VOR on freq 115.30 MHz...

Like that you can do your navigation network on any celestial body, not just on Kerbin (you can do it anyway,  and use it as VOR by selecting it as target, but ASET pack will not see it and you can use it just like target on navball.)