New Release D3D9Client Development

Loru, will this setting apply to other computers or is it only specific to mine. For example, if I make an addon with a saved reflection to a particular part etc, will this show on other computers. Also, presumably to apply these to a mesh only, without textures, I would need to do it manually using the actual mesh settings using notepad for example.

To make a saved setup appear in other computers you need to distribute the configuration file for your vessel class located in Config/GC/

This configuration file can also be a skin specific allowing different skins to have a different material properties.

---------- Post added at 20:45 ---------- Previous post was at 20:42 ----------

And yes what about "_bump"? In some previous version I just copied some gold foil.dds files - adding _bump so foils really had this bump effect, now they`re black (if viewed from most angles, except when grey "bump" reflections can be seen).
Sounds like the material is made over reflective. Try to use values like [0.3, 0.3, 0.1]

---------- Post added at 20:49 ---------- Previous post was at 20:45 ----------

Only, most of the meshes are "clipped", or maybe not clipped, but unrendered, so interior of ship is seen, or satellite can be seen through. Changing camera orientation changes this, rendering happens, so hole is closed.

That sounds pretty weird, it's not a material issue I am sure of that.
 
Make sure your _refl map has an alpha channel containing a grayscale copy of the reflection color.

The client should automatically create the alpha channel from RGB and replace any existing alpha. So, only a RGB texture is needed. Unless there's a problem with automatic alpha creation.
 
I make and save my textures in DTX3 with full mipmaps. This gives me an Alpha channel. Can this alpha channel still be used for masking etc, and can it still be used for various shades of grey to produce what is needed ie various full/part tranparency effects. And is this still saved when making changes using D3d9?.

We really could do with some sort of Manual, describing the various properties and which saving properties to use.
 
OK some error reports on the R9 version of D3D9:

- I have quite a few crashes of Orbiter in D3D9 since at least the R7 version. These crashes seems to come randomly with all sorts of add-ons being run. This happens when I press the start button to start a scenario, but instead of going full screen (as I selected) the desktop is still shown, except for a black pixel point on my laptop screen's upper left hand corner. I had to terminate the process in order to get back to the desktop, and checking my computer's logs shows them as CTDs.

Anyone here has a similar problem?

Unfortunately this still happens with version R10 and the latest video card drivers. However the Orbiter log shows something different:

Code:
**** Orbiter.log
Build Aug 30 2010 [v.100830]
Timer precision: 4.10528e-007 sec
Found 0 joystick(s)
Module AtlantisConfig.dll .... [Build 100830, API 100830]
Module AtmConfig.dll ......... [Build 100830, API 100830]
Module DGConfigurator.dll .... [Build 100830, API 100830]
Module EnergyConfigurator.dll  [Build ******, API 060425]
Module ProjectOutpostsConfig.dll  [Build 120604, API 100830]
Module ScnEditor.dll ......... [Build 100830, API 100830]
Module Framerate.dll ......... [Build 100830, API 100830]
Module FlightData.dll ........ [Build 100830, API 100830]
Module ExtMFD.dll ............ [Build 100830, API 100830]
Module ScriptMFD.dll ......... [Build 100830, API 100830]
Module LuaConsole.dll ........ [Build 100830, API 100830]
Module AeroBrakeMFD.dll ...... [Build ******, API 100830]
---------------------------------------------------------------
>>> WARNING: Obsolete API function used: oapiRegisterMFDMode
At least one active module is accessing an obsolete interface function.
Addons which rely on obsolete functions may not be compatible with
future versions of Orbiter.
---------------------------------------------------------------
Module BaseSyncMFD.dll ....... [Build 100616, API 100603]
Module CSSC_Spawner.dll ...... [Build 120331, API 100830]
Module GPCMFD.dll ............ [Build 111222, API 100830]
Module CustomMFD.dll ......... [Build 100830, API 100830]
Module LuaMFD.dll ............ [Build 100830, API 100830]
Module transx.dll ............ [Build 110130, API 100830]
Module Meshdebug.dll ......... [Build 100830, API 100830]
Module BurnTimeCalculator.dll  [Build 110301, API 100830]
Module LunarTransferMFD.dll .. [Build 100621, API 100603]
Module LaunchMFD.dll ......... [Build 120519, API 100830]
Module Rcontrol.dll .......... [Build 100830, API 100830]
Module OrbiterSound.dll ...... [Build 121120, API 100830]
Module uap.dll ............... [Build 110613, API 100830]
Module GS2.dll ............... [Build 130106, API 100830]
Module InterMFD55.dll ........ [Build 100826, API 100704]
Module D3D9Client.dll ........ [Build 130312, API 100830]
Module ScreenCapture.dll ..... [Build ******, API 060425]
Module LolaMFD.dll ........... [Build ******, API 050206]
Module ScnEditorTLE.dll ...... [Build ******, API 060425]
Module Themis_MFD.dll ........ [Build 130317, API 100830]

**** Creating simulation session
D3D9Client: [DirectX 9 Initialized]
D3D9Client: Sytem has XNA math support
D3D9Client: [3DDevice Initialized]
D3D9Client: [Compiling Effects for Shader Model 3.0]
D3D9Client: [Loading Stars]
D3D9Client: [Loading Constellations]
D3D9Client: [D3D9Client Initialized]
Orbiter Version 100830
D3D9Client Build [Mar 12 2013]
[B]Exception Code=0xC0000005, Address=0x00407F0F
EAX=0x00000202 EBX=0x00000000 ECX=0x00000000 EDX=0x00000000 ESI=0x00000202 EDI=0x00000000 EBP=0x00000000 ESP=0x009FEE80 EIP=0x00407F0F
C:\Users\Ivan\Desktop\Orbiter_2010\modules\server\orbiter.exe EntryPoint=0x004ACFAC, Base=0x00400000, Size=2097152
D3D9Client::RenderWndProc(hWnd=0x170838, uMsg=675, wParam=0, lParam=0)[/B]

I wonder if that will help pinpoint where the bug comes from? Thanks! :tiphat:
 
The Windows desktop isn't a 100% safe place (folder) where one should keep games, simulators, programs and such...

What is your Windows version?
 
The Windows desktop isn't a 100% safe place (folder) where one should keep games, simulators, programs and such...

What is your Windows version?

Hmmm..... I thought as long as it does not require installation it's OK?

I'm using the no-one-wants Windows 8. :rofl:
 
The Windows desktop isn't a 100% safe place (folder) where one should keep games, simulators, programs and such...
Any reason why it isn't a "safe" place?
 
The CTD is related to this code section:
PHP:
case WM_MOUSELEAVE:
{
       GraphicsClient::RenderWndProc (hWnd, WM_LBUTTONUP, 0, 0);
       return 0;
}

But, I don't understand why it is causing a CTD in your case. Also the code has been there over a year already.

This code is supposed to release the mouse button when the mouse leaves a window to disable dragging of thrust controls and etc. I suppose it should be possible to check if the button is held down before passing LBUTTONUP message. But would it solve the CTD issue ?

The CTD it self is occuring in the Orbiter.exe and I don't know what is it doing with the LBUTTONUP message.

Also, if this is a POST R7 issue then it doesn't really make much sence.

---------- Post added at 18:14 ---------- Previous post was at 18:12 ----------

I'm using the no-one-wants Windows 8. :rofl:

Have you upgraded your windows by any change after using R7 ? So, could this be a windows 8 specific issue ?
 
The client should automatically create the alpha channel from RGB and replace any existing alpha. So, only a RGB texture is needed. Unless there's a problem with automatic alpha creation.

This is a good idea. There seems to be a problem, though, when adding a RGB texture _refl map. Everything is fine up close to the surface, but as you back away and view from a distance, the surface turns black. Reflections still work correctly, but the diffuse texture goes black.

I think it might be an issue with mipmaps. Maybe the mipmaps for the alpha are auto-generated from what actually exists in the texture, instead of from what the client generates from the RGB. So if there is no alpha in the texture, the client-generated alpha channel is displayed up close, but as distance increases, the alpha mipmaps are generated from a blank alpha channel, which would default to 255. Since the diffuse texture is attenuated by the alpha channel, it would become black.

Using an RGBA _refl map (alpha being a grayscale copy of the RGB) has no problems, probably because the mipmaps have an alpha channel to use.

Here are some test files for the deltaglider, which go in the folder Textures2\DG.
 

Attachments

The CTD is related to this code section:
PHP:
case WM_MOUSELEAVE:
{
       GraphicsClient::RenderWndProc (hWnd, WM_LBUTTONUP, 0, 0);
       return 0;
}

But, I don't understand why it is causing a CTD in your case. Also the code has been there over a year already.

This code is supposed to release the mouse button when the mouse leaves a window to disable dragging of thrust controls and etc. I suppose it should be possible to check if the button is held down before passing LBUTTONUP message. But would it solve the CTD issue ?

The CTD it self is occuring in the Orbiter.exe and I don't know what is it doing with the LBUTTONUP message.

Also, if this is a POST R7 issue then it doesn't really make much sence.

---------- Post added at 18:14 ---------- Previous post was at 18:12 ----------



Have you upgraded your windows by any change after using R7 ? So, could this be a windows 8 specific issue ?

Could this be related to the fact that all these CTDs happen when I choose the Full Screen Window choice in the videos tab? I don't think this happens so far in the past when I updated my laptop to Win8 on the first day of availability, October 26.....
 
D3D9ClientR11 RC1

Here is a minor update.

- Reflection map alpha issue should be fixed.
- Shader file bug fix SpecS -> ReflS
- Attempt the fix the startup CTD issue.

If the startup CTD issue will still occur then please post the D3D9ClientLog.html from /Modules/D3D9Client/

Binaries are for the Orbiter 2010-P1
 

Attachments

Any reason why it isn't a "safe" place?
Yes, I have a couple of good ones:

when Vista and these "newer", "smarter" OSs were released (I'm still a 50year old WinXP guy), at my IL-2 website squadron, tuttovola.org, errors, "bugs", unexplainable weird things, were suddenly countless.
Every newbie constantly posted something about his "C:\Program files\IL-2 Sturmovik" not working as expected, now this mod was broken, now that config was not retaining its options...

You guessed it, UAC was responsible for that.

UAC was blocking and "protecting" some system folders (the Desktop was/is one of these) and files, so the user thought he indeed saved something, but it was not the case.
We (tuttovola.org admins, that is) wrote some tutorials, FAQs, troubleshooted many virtual pilots via TeamSpeak or TeamViewer, but, as you are admin here yourself, you know that there's always some "fresh noob" who asks the same over and over again...


And another reason:

at my daily work I humbly manage some 100 XP computers, and during my first years of work I received a great deal of calls from desperate colleagues who claimed: "I had this file/folder right here, directly on the Desktop, and now it...disappeared!! Help me I'm lost".

They were real "computer illiterates" and they had files/folders on the desktop just for practical reasons, because it was easier that way.
Now, after some years, they all have only shortcuts to what they need, and more importantly, they know the difference.

It can happen that you inadvertently select some files while again inadvertently pushing/moving the mouse.
Imagine a place where 30, 40 persons enter a room (with space for 8 workers). Maybe a birthday, or whatever...it's easy to scrub a mouse to make place for a cake...Or maybe you just fall, or lose balance, and give a bump to your mouse...
I did it, I mean it even happened to me once...so...
If you don't actualy look at the monitor in the same moment it happens, you don't know what you did.

For me these reasons are good enough to say that the Desktop isn't safe for anything but shortcuts.
 
UAC was blocking and "protecting" some system folders (the Desktop was/is one of these) and files, so the user thought he indeed saved something, but it was not the case.
But Desktop isn't a system folder, only user's folder, similarly like Documents folder where users have been installing Orbiter, too. Why would UAC protect the Desktop and place files from it in "VirtualStore" folder of the same user? :shrug:

For example I treat Desktop as a temporary location for different programs I test, which don't have their own installers, before I place them in more permanent location, or if they are for one time use only. I haven't had any problems with that neither in Windows XP, nor in Windows 7.

at my daily work I humbly manage some 100 XP computers, and during my first years of work I received a great deal of calls from desperate colleagues who claimed: "I had this file/folder right here, directly on the Desktop, and now it...disappeared!! Help me I'm lost".
Are those users sharing the same desktop? If they deleted something from their own desktop, it's their fault. If many users share the same user profile on a computer, and the same desktop, it's administrator's fault.
 
You are right.
But I never use it like you do (as a temporary location), and I still prefer to think of the Desktop as a "special" area, expecially at work.
 
But Desktop isn't a system folder, only user's folder, similarly like Documents folder where users have been installing Orbiter, too. Why would UAC protect the Desktop and place files from it in "VirtualStore" folder of the same user? :shrug:

For example I treat Desktop as a temporary location for different programs I test, which don't have their own installers, before I place them in more permanent location, or if they are for one time use only. I haven't had any problems with that neither in Windows XP, nor in Windows 7.

If I'm not mistaken, in Win7, if anyone other than the logged in user tries to save files to, or launch programs located on, that user's desktop, you must get administrative privileges to do so via answering the UAC Ok prompt to gain the privileges. Programs don't run as the logged in user, so unless you run as Administrator, you may run into an issue.

My guess here is that since the Orbiter folder is on the desktop, this security is propagating down and Orbiter_ng.exe isn't able to launch \Orbiter_2010\modules\server\orbiter.exe

Even if you run Orbiter_ng as Administrator here, because of the location (Ivan's desktop), UAC is still going to protect it/prompt you because Administrator != Ivan. So it is probably wanting Administrator/Orbiter_ng.exe to authenticate the launch of \Orbiter_2010\modules\server\orbiter.exe , at which point Orbiter_ng is probably getting confused and, well...kablooey, as it were.
 
Last edited:
But why would you install Orbiter in other user's profile to use it by yourself? :shrug:

If you want it available to all users, you simply don't install it in your profile but in a place available for all users.

The prompt when you run it as Administrator is only to elevate the program's privileges, and not to use user's Desktop as a folder which will be mirrored in Administrator's profile "VirtualStore", because it was run by other user than the owner of the Desktop. If you run it as Administrator, the VirtualStore actually won't be used because Administrator has write access to the folder, even if you installed Orbiter in Program Files (unless installer has removed the write access in the folder's ACL for Administrators group, which is rare).

I still see no problems with "installing" and running Orbiter.exe or Orbiter_ng.exe along with D3D9Client in user specific folders.
 
But why would you install Orbiter in other user's profile to use it by yourself? :shrug:
You wouldn't. But when you simply launch the program by double-clicking, you're not launching it as 'orb' for example. You're launching it as a guest user with limited privileges.

I still see no problems with "installing" and running Orbiter.exe or Orbiter_ng.exe along with D3D9Client in user specific folders.

I'm thinking the issue lies in when Orbiter_ng then tries to launch the 'server' executable (\Orbiter_2010\modules\server\orbiter.exe). I can't say for sure, I'd need to see the event viewer on that machine, but my guess, and this is indeed a guess, is that UAC is expecting some sort of elevation for launching that executable as well, and this is confusing the client. I could be totally missing it here, but this is my interpretation of what may be happening.
 
I can't say for sure if the CTD is fixed since I didn't have the issue to begin with, but the other two issues are fixed. Thanks!
 
Back
Top