Jump to content

flyer10au

Members
  • Content Count

    21
  • Joined

  • Last visited

Community Reputation

0 Neutral

About flyer10au

  • Rank
    Member

Recent Profile Visitors

1,237 profile views
  1. Thanks for the reply. That is a shame. I know other devs also have this limitation but I know Aerobask for instance has a way to make their custom popouts work without the 3D cockpit showing. Hopefully you guys and the other devs can lobby LR to fix this limitation.
  2. A related question. When the G1000 displays are popped out do they still operate as normal if the Xplane view is set to outside only. I.e. No 3D cockpit shown. I have had issues with other developers aircraft that require the 3D cockpit to show. I want to be able to only show outside view. This question also applies to SR22 and other G1000 equipped models. Wanting to purchase but need this to work.
  3. Yes that helps. Good information for when the API documentation finally gets updated. Thanks again.
  4. Thanks Ben. I thought I'd tried that but must of been finger trouble last time. It now works like a dream. Out of interest what is adding return 1 to the end of OnStart actually doing different to not using return 1.
  5. I'm not getting it. I have the following code and the custom dataref only increments by 1. Nothing happens when I hold or release the button. The button is running a custom command created with xp.newCommand("sim/custom/button", "Button", "button"). The dataref is declared elsewhere. button_count = 0function button_OnStart() button_count = button_count + 1 dref.setFloat(CDRtest1, button_count) endfunction button_OnHold() button_count = button_count + 10 dref.setFloat(CDRtest1, button_count)endfunction button_OnStop() button_count = button_count - 1 dref.setFloat(CDRtest1
  6. Anyone have any success using the OnStop or OnHold hooks that should be called when executing a custom command. I have the same bit of test code in the OnStart, OnHold and OnStop functions but only the OnStart executes. I can't get button release or hold to work at all. I'm using the latest 13.11.05.0205 Gizmo release.
  7. Thanks for the confirmation. Shouldn't take too long with find and replace.
  8. I've just got round to updating my gizmo plugin to 13.11.05.0205 from an older 64 bit version (i can dig the version out if important). I am getting script error's in the console for all the xp.get and xp.set functions in previously working code. I have managed to figure out that by changing these to dref API functions clears the errors. I haven't changed every reference in my multi file scripts yet as I just want to be sure that xp functions will not function with these newer gizmo versions any longer and that dref is the new kid on the block and should be used in new script. I know dref has
  9. Thanks for the clarification. It's easy to deal with as you say. Just seemed a little weird to me, but your explanation at least makes some sense to the reasoning behind it.
  10. All Working. Now I understand what the built in OnDraw functions are for it makes sense. My problem was simply because I was trying to draw panel stuff with OnDraw_windows. The only thing that doesn't stack up is this. In the aircraft I tried (including xp's C172). If I make the planemaker co-ordinates 0,0 for a gauge the centre of it is aligned with the left edge of the screen as expected. However in the vertical plane the middle of the gauge sits about 256 pixels above the bottom edge of the screen. Therefore if I add 256 to my y co-ordinate plus half the gauges height I get the top of
  11. Jim, I have been using the font functions with success elsewhere so thanks for the tip about gfx.drawstring. I knew about the gfx.texOn() and gfx.texOff() but somehow managed to forget to include them. That now makes the png draw as expected from either OnDraw_Gauges() or OnDraw_BeforeGauges(). I think On_Draw_Gauges() draws stuff just the once and its likely best use is for one time drawing items that don't move or change based on changing dataref's. What I still don't understand is when to use calls from each of these functions and what the differences are. I assume anything that needs to
  12. OK back again. Working my way through the API trying to understand what's possible with Gizmo. This time I'm on to the graphics API and open GL drawing. I've got a couple of questions. My main question relates to how to align png images placed in planemaker with Gizmo code generated open gl drawing elements. What I can currently do is have some gl generated text and number elements drawn with font.drawString nicely align in the desired locations within a planemaker png while the screen size window is less than or equal to the panel.png resolution (1920x1080 in this case). I do this by readin
  13. Jim, I agree with you its safer to use nav.getNextNavAid just in case the database changes in the future. I was just pointing out that at this moment in time its the same, which is why my incrementing method worked until you pointed out the documentation error. This is however all now irrelevant for my use because as I previously stated I was able to get the findNavAid function working just as I needed. Once again thanks for your support on this. I'm sure I'll be needing some further help from this great community as time goes on. I could certainly help someone with a nav api question in the f
  14. Thanks Guys. It sounds like improved documentation is already on the agenda then. It really will help smooth the way for newer developers. We still have this great forum for help in the meantime. Ben thanks for the github reminder. I had been along there a few weeks back. Now I know a little more about Gizmo it may be of more use. Jim, The VOR_NavRef = nav.getNextNavAid( VOR_NavRef ) works as you suggest but is of little improvement over just incrementing the VOR_NavRef by 1 for each iteration until you reach the last VOR entry. This is simply because all the VOR's are in the database sequ
  15. Well I took Jim's advice and re-tracked this little project down the nav database lookup route. I've got to say the things that are possible with Gizmo and the relative lack of time they take to implement is absolutely brilliant. Take me a relative newbie ( about 6 weeks in) to gizmo development and I have been able to not only get all this working but in a matter of a couple of days. That said, I do wish the API documentation was better. I personally think some example code on each page of the API of how to use each function would help greatly. It wasn't all plain sailing but most of my tro
×
×
  • Create New...