Minor Full Cockpit Bind/Display Discoveries
-
- I should be able to fix the generator ties switch animation for you easily.
- Sorry about the firewall/extinguisher valve covers. That's baked into the model, but also a relatively easy fix for the next update.
- Yes, that logic for the generator switches is 100% correct.
As you may have seen elsewhere on this forum, the double screens is how I keep Starship performing better or comparably to the default aircraft that simulate maybe 1/100th of what Starship does. Performance has always been very important to me, so I wanted to make sure that anyone was able to enjoy Starship without buying a new graphics card. I knew there would be some cockpit builders like yourself who would have to be resourceful. I imagined a solution just like what you are describing, but that alt-tab problem is unfortunate.
When you first mentioned your solution, my initial thought was to just arrange the monitors vertically in the windows positioning tool, so all the copilot's displays hang off the right of the screen and into the void. Does this not work with your setup?
As I said elsewhere, I will consider a free "cockpit builders edition" that sacrifices performance for convenience, if there is enough demand.
@Black-Square Thank you for the response. It's tough on the displays as you can imagine because making movements of them can cause a lot of issues unless you're just flying one plane. For example, if I go into DCS, all exported displays are coordinate based, so dragging around windows would mean doing so again when changing sims, plus windows drag feature isn't pixel perfect, especially when you have so many displays of different sizes (for things like standby instruments, etc..). End of the day though I can manage with the current setup.
While I totally get time isn't infinite - in today's world where CDUs are now just over $100, I hope in your infinite (j/k) free time you can poke at how to expose the CDU to something like SpadNext. As you can imagine - building cockpits is kind of a thing I do and the Starship has me thinking it may be the basis of my next large physical build. Here's an image of the F18 in Starship mode, not sure if it will link.
-
Bus tie switch movement has now been implemented.
I'm sorry about the screen compromises. I hope you understand that this was a "benefit of the many versus the few" situation. To be frank, I also figured that it wouldn't be long before someone came up with a clever solution using some 3rd party software. Sometimes a few hundred dedicated minds can come up with something far better than I could have.
Thanks for sharing your photo. Seeing people's home cockpits is actually one of my favorite aspects of interacting with the community. Please elaborate about what it would mean to "expose the CDU to something like SpadNext". I haven't played with the new CDU hardware, but I think everything is in place for you to interact with the CDU via hardware.
Lastly, I just came up with a possible solution for the window problem that would be extremely easy to implement. Let me check to see if it works, and then I will get back to you.
-
You're in luck! I have a very simple way to get down to one set of screens for the pilot's side. I'm going to leave you notes on how to do it here, but I might make a package everyone could download in the future. Thanks for encouraging me to think outside the box!
For each panel.cfg file in Starship's directory, you can make some simple edits to get one of two effects:
-
Option 1: The pop-out window is correctly sized for just one instrument, but the instrument is distorted in the virtual cockpit.
-
Option 2: The pop-out window is double the size of just one instrument, but the instrument displays normally in the virtual cockpit. You can still resize the window after it's open, though.
For each method, you will search for the following entries in each panel.cfg:
SduScreens
AsiScreens
AltScreens
PfdScreens
CduScreensUsing SduScreens as an example, we will want to divide the screen width (1000) by two.
[VCockpit03] size_mm = 1000, 500 pixel_size = 1000, 500 texture = $SduScreens htmlgauge00=NavSystems/bksq-aircraft-starship/SDU/SDU.html, 0, 0, 1000, 500For Option 1, we will divide all three appearances of this width.
[VCockpit03] size_mm = 500, 500 pixel_size = 500, 500 texture = $SduScreens htmlgauge00=NavSystems/bksq-aircraft-starship/SDU/SDU.html, 0, 0, 500, 500For Option 2, we will only divide the last appearance of this width.
[VCockpit03] size_mm = 1000, 500 pixel_size = 1000, 500 texture = $SduScreens htmlgauge00=NavSystems/bksq-aircraft-starship/SDU/SDU.html, 0, 0, 500, 500This will currently not work for the CDU, but I have fixed that for the next update. Not sure why it was different in the first place...
Please let me know if you have any questions! As long as you're not trying to build a two-place Starship cockpit right now, this should work perfectly for your needs!
-
-
Bus tie switch movement has now been implemented.
I'm sorry about the screen compromises. I hope you understand that this was a "benefit of the many versus the few" situation. To be frank, I also figured that it wouldn't be long before someone came up with a clever solution using some 3rd party software. Sometimes a few hundred dedicated minds can come up with something far better than I could have.
Thanks for sharing your photo. Seeing people's home cockpits is actually one of my favorite aspects of interacting with the community. Please elaborate about what it would mean to "expose the CDU to something like SpadNext". I haven't played with the new CDU hardware, but I think everything is in place for you to interact with the CDU via hardware.
Lastly, I just came up with a possible solution for the window problem that would be extremely easy to implement. Let me check to see if it works, and then I will get back to you.
@Black-Square said in Minor Full Cockpit Bind/Display Discoveries:
Please elaborate about what it would mean to "expose the CDU to something like SpadNext". I haven't played with the new CDU hardware, but I think everything is in place for you to interact with the CDU via hardware.
I haven't gotten much further than getting all the primary switching bound and the AP functions bound to phsycal hardware. But for the PU Air Korea CDU I'd need a single windows popout and with all CDUs we'd need to be able to bind each letter/number and function to a seperate key. (Though if you do have a var that can intialize the keyboard input within spad I could set the keyboard input var + wait + keyboard key)
This is a pretty big ask I think for a small crowd of people and considering the relative simplicity in navigration with these avionics I don't know what benefit making it work on a CDU head unit brings to flying the plane other than I have hardware I want to use ha! But for those that have it I know we'd appreciate it but wouldn't demand it.
-
Thank you for explaining. We will have single window support from my modifications above, and all CDU keys already have their own events. I will post them here, but I only ask that you share a picture of the working CDU when you are done
H:CDU_Line2L_1 H:CDU_Line3L_1 H:CDU_Line4L_1 H:CDU_Line5L_1 H:CDU_Line1R_1 H:CDU_Line2R_1 H:CDU_Line3R_1 H:CDU_Line4R_1 H:CDU_Line5R_1 H:CDU_RangeKnob_Inc_1 H:CDU_RangeKnob_Dec_1 H:CDU_RangeKnob_Inc_1 H:CDU_RangeKnob_Dec_1 H:CDU_TiltKnob_Inc_1 H:CDU_TiltKnob_Dec_1 H:CDU_TiltKnob_Inc_1 H:CDU_TiltKnob_Dec_1 H:CDU_TiltKnobPush_1 H:CDU_HsiButton_1 H:CDU_RadarButton_1 H:CDU_ArcMapButton_1 H:CDU_SourceButton_1 H:CDU_RadarControlButton_1 H:CDU_BearingButton_1 H:CDU_ComButton_1 H:CDU_NavButton_1 H:CDU_AfdButton_1 H:CDU_TransponderButton_1 H:CDU_FlightPlanButton_1 H:CDU_SystemControlButton_1 H:CDU_IndexButton_1 H:CDU_DirectButton_1 H:CDU_UpButton_1 H:CDU_DownButton_1 H:CDU_VnavButton_1 H:CDU_MessageButton_1 H:CDU_1Button_1 H:CDU_2Button_1 H:CDU_3Button_1 H:CDU_4Button_1 H:CDU_5Button_1 H:CDU_6Button_1 H:CDU_7Button_1 H:CDU_8Button_1 H:CDU_9Button_1 H:CDU_0Button_1 H:CDU_ClearButton_1 H:CDU_LetterButton_1 -
Bus tie switch movement has now been implemented.
I'm sorry about the screen compromises. I hope you understand that this was a "benefit of the many versus the few" situation. To be frank, I also figured that it wouldn't be long before someone came up with a clever solution using some 3rd party software. Sometimes a few hundred dedicated minds can come up with something far better than I could have.
Thanks for sharing your photo. Seeing people's home cockpits is actually one of my favorite aspects of interacting with the community. Please elaborate about what it would mean to "expose the CDU to something like SpadNext". I haven't played with the new CDU hardware, but I think everything is in place for you to interact with the CDU via hardware.
Lastly, I just came up with a possible solution for the window problem that would be extremely easy to implement. Let me check to see if it works, and then I will get back to you.
@Black-Square Don't stress on the screen export I didn't know the benefits at the time and agree with you; with Pop Out Manager its very manageable. As for the CDU... Ok, so there are the Airbus and Boeing CDUs out there, while many smaller companies (PU Korea) did theirs where it has a separate HDMI port you connect to it - where you can put a pop out window on it - WinWing's is all in one through USB. The downside to that approach is there is a different method to getting screen data on it.
So the dev of SpadNext has "bridge" software in their app that nabs the data from the screen and pushes it to the WinWing CDU. This works for the Aerosoft CRJ, FlyByWire, PMDG, and iniBuilds planes. For the C90, CJ4, Asobo 737 max 8, and Piaggio P180 one uses the mod from DementedMonkey that I think links the CDUs of those planes to the approach used for the others. He also has a separate "web server" executable that allows one to have a virtual CDU. Here's their github: https://github.com/dementedmonkey/cj4-mcdu
Heck, at the end of the day, if the lines of text on the CDU were in variables of some sort one could just use SpadNext and create the display from those. Basically if its a 14 line screen or something, with left and right halves, you'd have 28 variables for the text shown in those areas. I know Spad supports extended ASCII for symbols and stuff. Yet, I think it may be easier to just use an approach thats working for Aerosoft/FlyByWire/PMDG/iniBuilds for SpadNext. As I've never made a plane though I don't know for sure and only you could say what challenges it creates.
-
@Black-Square said in Minor Full Cockpit Bind/Display Discoveries:
Please elaborate about what it would mean to "expose the CDU to something like SpadNext". I haven't played with the new CDU hardware, but I think everything is in place for you to interact with the CDU via hardware.
I haven't gotten much further than getting all the primary switching bound and the AP functions bound to phsycal hardware. But for the PU Air Korea CDU I'd need a single windows popout and with all CDUs we'd need to be able to bind each letter/number and function to a seperate key. (Though if you do have a var that can intialize the keyboard input within spad I could set the keyboard input var + wait + keyboard key)
This is a pretty big ask I think for a small crowd of people and considering the relative simplicity in navigration with these avionics I don't know what benefit making it work on a CDU head unit brings to flying the plane other than I have hardware I want to use ha! But for those that have it I know we'd appreciate it but wouldn't demand it.
@Qazme If you have the PU Air Korea you are already supported since you can pop out the CDU and map all of its keys with the H events that Black Square provided. With WinWing CDUs being only $150 - that "smaller crowd" won't be small for long.
-
You're in luck! I have a very simple way to get down to one set of screens for the pilot's side. I'm going to leave you notes on how to do it here, but I might make a package everyone could download in the future. Thanks for encouraging me to think outside the box!
For each panel.cfg file in Starship's directory, you can make some simple edits to get one of two effects:
-
Option 1: The pop-out window is correctly sized for just one instrument, but the instrument is distorted in the virtual cockpit.
-
Option 2: The pop-out window is double the size of just one instrument, but the instrument displays normally in the virtual cockpit. You can still resize the window after it's open, though.
For each method, you will search for the following entries in each panel.cfg:
SduScreens
AsiScreens
AltScreens
PfdScreens
CduScreensUsing SduScreens as an example, we will want to divide the screen width (1000) by two.
[VCockpit03] size_mm = 1000, 500 pixel_size = 1000, 500 texture = $SduScreens htmlgauge00=NavSystems/bksq-aircraft-starship/SDU/SDU.html, 0, 0, 1000, 500For Option 1, we will divide all three appearances of this width.
[VCockpit03] size_mm = 500, 500 pixel_size = 500, 500 texture = $SduScreens htmlgauge00=NavSystems/bksq-aircraft-starship/SDU/SDU.html, 0, 0, 500, 500For Option 2, we will only divide the last appearance of this width.
[VCockpit03] size_mm = 1000, 500 pixel_size = 1000, 500 texture = $SduScreens htmlgauge00=NavSystems/bksq-aircraft-starship/SDU/SDU.html, 0, 0, 500, 500This will currently not work for the CDU, but I have fixed that for the next update. Not sure why it was different in the first place...
Please let me know if you have any questions! As long as you're not trying to build a two-place Starship cockpit right now, this should work perfectly for your needs!
@Black-Square The info on splitting the screens is awesome. Will dig into it.
-
-
Amazeballs.. Option 2 worked perfectly. Thank you so much for the time to provide that idea.
-
Wonderful! This is why I am so happy that we have these forums. It's such a simple solution, but I never would have thought of it without a nudge in the right direction.
-
F friedmaniac referenced this topic
