Help needed updating Citation II

[kuifje09]

After spending a lot of time searching for a solution, I gave up more or less.

I want to update the citation II, and then for these things:

Flying in the night some buttons and dials are unreadable, maby it is so in real life, but not easy for me.
So I did already a lot in changing some textures/xml and ac files, to make it more eadable, and added ( maybe unrealistic ) some
enhancements to change autopilot setting from the panel ( instead of the menuus ) which is very nice to it that way.

But now the problem, I want to make the radios, com/nav/adf better readable.
Adf has i.e. 1 button with some light in it, but not all, com and nav not at all.

I want to change them but cant find where to do it. I wish they were just ac-models but they ar'nt

Can somebody assist me with this issue ?

[Octal450]

What do you mean that they aren't .ac models?

All FGFS model files are .ac unless its a canvas instrument, but canvas is not used for radios I don't believe.

Josh

[Necolatis]

All FGFS model files are .ac unless its a canvas instrument

Nope, they can be all kinds of formats, AC3D is just the most common used.

For example it can be dxf, 3ds, md2, obj, flt and many more. See the full list here: http://trac.openscenegraph.org/projects ... es/Plugins

[kuifje09]

Alright, stop searching and thank you.

I found them, top down, because I did not what to look for. But looking at the rgb and png files in the Aircraft/instruments3d, I found the names.
Then searching for the names I found them in the Citation/Models/Instruments/panel-layout1.xml . Then you ask yourself why it did not catch the eye in the first place...
Its about : TDR-94 ADF-462 VHF-22 and the VIR-32. All global or general instruments. ../Aircraft/Instruments3d
The other are all local at the plane itself.
A bit strange these instruments do look like eachother but differ a lot in how they behave in emission at night.
I will change the models, at least for myself, to have more visibility at night.
As global update ? Don't know if it would harm other planes using the same instruments.

[Thorsten]

You can have a local copy of the xml file defining different material values (emissive property,...) referencing the global 3d mesh and textures (which are the 'heavy' resources and the reason there are shared instruments).

[kuifje09]

Thats right Thorsten, but as far I tryed not satisfactory. I mean, not all instruments behave to i.e. emisson as I would.
For some it works rather well, but others not. Most other buttons and dial do well with just a little change in the materials/ac or with the xml
I will change them to have only the white circles and letters to jump out at night. For some it showed to be the whole background texture.
It is usable, but not real nice. But thanks for your reaction.

EDIT : Maby as example, the difference between the ADF and the COM/NAV , then the TDC is just between them.
( all lit, none lit, and half of it lit )

[Octal450]

woah... never seen that before. Only .ac models in all the planes I've D/Led so far...

[Thorsten]

Thats right Thorsten, but as far I tryed not satisfactory. I mean, not all instruments behave to i.e. emisson as I would.

Then maybe you ought to try again. Using material animations and/or effects should be able make whatever is declared in the *.ac file as material properties obsolete. That's what xml-wrappers are for - you do not need to copy 25 MB of mesh to give the mesh a different color - a simple change in the xml wrapper does that.

You should be able to give the instrument almost *any* lighting scheme you want in the xml file without ever having to touch the mesh file.

That's how the scheme is intended to work - please consider using it that way

[Hooray]

All FGFS model files are .ac unless its a canvas instrument, but canvas is not used for radios I don't believe.

Note that, for the time being, Canvas is mainly used for 2D rendering purposes - as such, it is not too useful for anything involving 3D (well, Thorsten's shuttle ADI proves that wrong ...) - anyway, unless you have a strong background in 3D maths, you are unlikely to benefit from using Canvas for 3D instruments - apart from that, the Canvas system itself is usually used to model complex avionics (MFDs, PFDs, EFIS-like setups), but pe se it doesn't really care/matter if you only use it to show a simple radio stack.

In fact, it can do pretty much everything (and much more) that the legacy 2.5D cockpit panel system can do, including even rendering those instruments/panels specifically - it would take the equivalent of the pui2canvas parser to parse existing instruments/cockpit XML markup and use that to populate a Canvas property tree structure to render fully functional avionics/panels, without having to modify any C++ code - the approach would work for HUDs, too.

The main benefit would be modernizing OpenGL related rendering code in the main loop to use more modern OSG code, that interacts better/more reliably (more portable and often faster) with OSG/OpenGL than the legacy OpenGL code currently used in various places.

http://wiki.flightgear.org/Howto:Parsin ... the_Canvas

[kuifje09]

After I uploaded the new citation, this is no longer needed.
The developers did a good job, and I see you took also some general instruments to the local level.
Also the startup cyclus.... funny to see you did something like I did too.

Somthing to make it better, No startup lights(white) should be lit when It cannot be started I think, and the ignition leds, should be brighter.
But whoami to tell....