New Orbiter SVN commit (r.71, Oct 14 2017) - Page 39 - Orbiter-Forum

**kuddel** · 02-21-2019, 10:26 PM

Quote:

Originally Posted by martins

Good to know, given that I have rearranged my entire build setup underneath it. I didn't advertise this commit since it doesn't have much front-end changes (except the fix for the embarrassing matrix-vector bug

Let me know if anything comes up.

I am trying to adopt D3D9Client, but I am not sure what .props-file I should use instead of the former orbiter.props.
The most luck I have when I use "VS2015\PropertyPages\orbiter_plugin.props",
but still at link-time a giant mess comes up

...still working on that.

Could you explain the new structure of you property sheets?
a) was it reasonable to switch from "resources\Orbiter.props" to "VS2015\PropertyPages\orbiter_plugin.props" ?
b) Should we only take the .props-files from the PropertyPages directory?

---------- Post added at 19:43 ---------- Previous post was at 19:22 ----------

Update:
Debug-Build: Works with just changing to "VS2015\PropertyPages\orbiter_plugin.props"
Release-Build: Still fails linking (I think a standard library is missing...)
...hold the line...

---------- Post added at 19:51 ---------- Previous post was at 19:43 ----------

2nd update:
The inherited value of %(IgnoreSpecificDefaultLibraries) made the release-build fail.
So when the build configuration doesn't inherit Link->IgnoreSpecificDefaultLibraries (rendering it's value empty on RELEASE) it works.

Ah... and by the way: it seems that all the macros like $(SDKLibDir) have been split into two versions: $(SrcSdkLibDir) and $(BuildSdkLibDir), right?
From a quick look at them they are all the same for us (non-orbiter-core-)developers, right? So it's up to us whether we choose one or the other?

---------- Post added at 22:26 ---------- Previous post was at 19:51 ----------

Here's my old-to-new migration table. I think I didn't miss any.

Old (< r85)	New (>= r85)	alternative[*]
$(OrbiterDir)	$(SrcDir)
$(DeployDir)	$(SrcDir)	$(BuildDir)
$(BuildDir)	$(BuildDir)
$(ModuleDir)	$(BuildModuleDir)
$(MeshDir)	$(BuildMeshDir)
$(ConfigDir)	$(SrcConfigDir)	$(BuildConfigDir)
$(ScenarioDir)	$(BuildScenarioDir)
$(SDKDir)	$(SrcSdkDir)	$(BuildSdkDir)
$(SDKIncludeDir)	$(SrcSdkIncludeDir)	$(BuildSdkIncludeDir)
$(SDKLibDir)	$(SrcSdkLibDir)
$(SDKSampleDir)	$(SrcSdkSampleDir)

[*] using $(Src...) for input operations and $(Build...) for output operations.

And I think we should never use $(RootDir) as it would not work if one decided to give orbiter development a complete drive (".." from "D:\" will not get me anywhere

)

**martins** · 02-21-2019, 10:40 PM

Quote:

Originally Posted by kuddel

I am trying to adopt D3D9Client, but I am not sure what .props-file I should use instead of the former orbiter.props.
The most luck I have when I use "VS2015\PropertyPages\orbiter_plugin.props",
but still at link-time a giant mess comes up

...still working on that.

Could you explain the new structure of you property sheets?
a) was it reasonable to switch from "resources\Orbiter.props" to "VS2015\PropertyPages\orbiter_plugin.props" ?
b) Should we only take the .props-files from the PropertyPages directory?

To be honest, the main reason for the change was to make my life easier by unifying the build systems for the Orbiter core and Orbiter SDK samples. So essentially all I did was to copy the property pages from the core build system into Orbitersdk and checking that the samples still compile. Hence also the distinction between the "Src" and "Build" directories. For the SDK samples, those will nornally be the same as you say, although technically, you should be able to move the entire Orbitersdk subdirectory to an arbitrary place and still be able to compile everything to their proper target locations by modifying the SrcDir and BuildDir locations in orbiter.props accordingly. So in summary:

a) the build setup is now a bit easier for me (although in hindsight, restructuring the build system may have been more hassle than it was worth), but it could have added a bit of inconvenience to users who had already incorporated the previous structure into their own build mechanism - sorry for that!

b) yes.

Quote:

Update:
Debug-Build: Works with just changing to "VS2015\PropertyPages\orbiter_plugin.props"
Release-Build: Still fails linking (I think a standard library is missing...)
...hold the line...

2nd update:
The inherited value of %(IgnoreSpecificDefaultLibraries) made the release-build fail.
So when the build configuration doesn't inherit Link->IgnoreSpecificDefaultLibraries (rendering it's value empty on RELEASE) it works.

Interesting. I don't even know where the %(IgnoreSpecificDefaultLibraries) is populated from. Is this an environment variable? What value does it have in your case? So just to confirm: removing %(IgnoreSpecificDefaultLibraries) from the <IgnoreSpecificDefaultLibraries> entry in orbiter_module.props (but leaving LIBCMT in) makes it work?

Quote:

Ah... and by the way: it seems that all the macros like $(SDKLibDir) have been split into two versions: $(SrcSdkLibDir) and $(BuildSdkLibDir), right?
From a quick look at them they are all the same for us (non-orbiter-core-)developers, right? So it's up to us whether we choose one or the other?

Yes, see above.

**kuddel** · 02-21-2019, 11:00 PM

Quote:

Originally Posted by martins

So just to confirm: removing %(IgnoreSpecificDefaultLibraries) from the <IgnoreSpecificDefaultLibraries> entry in orbiter_module.props (but leaving LIBCMT in) makes it work?

No, don't change orbiter_module.props! I would never have touched any of the files from the orbiter package

That sheet works fine for debug-builds (where LIBCMT should be omitted)
but fails to link during release-builds.
I just changed the setting in our project file (kind of override).

Why our release-build needs LIBCMT and our debug-build doesn't is a -to be honest- an phenomenon I have not (yet) understood.

**Nikogori** · 02-24-2019, 08:13 AM

I don't know if anyone has already mentioned this, but... where is the PWR button on VC?

**martins** · 02-24-2019, 07:28 PM

Quote:

Originally Posted by Nikogori

I don't know if anyone has already mentioned this, but... where is the PWR button on VC?

Ah yes, this is a bit of a design flaw. We have already complained a few times to the British manufacturer, but they are citing Brexit uncertainties for glitches in their manufacturing process. I quote: "No deal, no more power buttons" ...

**Nikogori** · 02-25-2019, 09:59 AM

Quote:

Originally Posted by martins

Ah yes, this is a bit of a design flaw.

I thought it was called "design feature".

**kuddel** · 03-05-2019, 06:43 PM

I've noticed an issue with r86 (and r87 as well). The body-force-vectors (torque in particular) is/are displayed oddly...
I've checked r86 and r87, but it could have been in there before...

GLS · 03-05-2019, 07:02 PM

Quote:

Originally Posted by kuddel

I've noticed an issue with r86 (and r87 ass well). The body-force-vectors (torque in particular) is/are displayed oddly...
I've checked r86 and r87, but it could have been in there before...

I see the same with r85.

**Ripley** · 09-15-2019, 04:41 PM

Rev. 90 crashes upon start with this log (both d3d9 and d3d7):

Code:

**** Orbiter.log
000000.000: Build Sep 14 2019 [v.190914]
000000.000: Timer precision: 1e-07 sec
000000.000: Found 0 joystick(s)
000000.000: [ ] RGB Emulation (SW)
000000.000: [ ] Direct3D HAL (HW)
000000.000: [x] Direct3D T&L HAL (HW)
000000.000: [ ] Direct3D HAL (NVIDIA GeForce GTX 970) (HW)
000000.000: [x] Direct3D T&L HAL (NVIDIA GeForce GTX 970) (HW)
000000.000: Module AtlantisConfig.dll .... [Build 190914, API 190914]
000000.000: Module AtmConfig.dll ......... [Build 190914, API 190914]
000000.000: Module DGConfigurator.dll .... [Build 190914, API 190914]
000000.000: Module ScnEditor.dll ......... [Build 190914, API 190914]
000000.000: Module ExtMFD.dll ............ [Build 190914, API 190914]
000000.000: 
000000.000: **** Creating simulation session
000000.000: DirectDraw interface OK
000000.000: Direct3D interface OK
000000.000: Graphics: Viewport: Fullscreen 1920 x 1080 x 32
000000.000: Graphics: Hardware T&L capability: Yes
000000.000: Graphics: Z-buffer depth: 32 bit
000000.000: Graphics: Active lights supported: 8
000000.000: Loading 15382 records from star database
000000.000: Module Sun.dll ............... [Build 190914, API 190914]
000000.000: VSOP87(E) Sun: Precision 1.0e-06, Terms 554/6634
000000.000: Module Mercury.dll ........... [Build 190914, API 190914]
000000.000: VSOP87(B) Mercury: Precision 1.0e-05, Terms 167/7123
000000.000: Module Venus.dll ............. [Build 190914, API 190914]
000000.000: Module VenusAtm2006.dll ...... [Build 190914, API 190914]
000000.000: VSOP87(B) Venus: Precision 1.0e-05, Terms 79/1710
000000.000: Module Earth.dll ............. [Build 190914, API 190914]
000000.000: Module EarthAtmJ71G.dll ...... [Build 190914, API 190914]
000000.000: VSOP87(B) Earth: Precision 1.0e-08, Terms 2564/2564
000000.000: Module Moon.dll .............. [Build 190914, API 190914]
000000.000: ELP82: Precision 1.0e-05, Terms 116/829
000000.000: Module Mars.dll .............. [Build 190914, API 190914]
000000.000: Module MarsAtm2006.dll ....... [Build 190914, API 190914]
000000.000: VSOP87(B) Mars: Precision 1.0e-05, Terms 405/6400
000000.000: Module Phobos.dll ............ [Build ******, API 060425]
000000.000: Module Deimos.dll ............ [Build ******, API 060425]
000000.000: Module Galsat.dll ............ [Build 190914, API 190914]
000000.000: Module Jupiter.dll ........... [Build 190914, API 190914]
000000.000: VSOP87(B) Jupiter: Precision 1.0e-06, Terms 1624/3625
000000.000: Module Io.dll ................ [Build 190914, API 190914]
000000.000: Module Europa.dll ............ [Build 190914, API 190914]
000000.000: Module Ganymede.dll .......... [Build 190914, API 190914]
000000.000: Module Callisto.dll .......... [Build 190914, API 190914]
000000.000: Module Satsat.dll ............ [Build 190914, API 190914]
000000.000: Module Saturn.dll ............ [Build 190914, API 190914]
000000.000: VSOP87(B) Saturn: Precision 1.0e-06, Terms 2904/6365
000000.000: Module Mimas.dll ............. [Build 190914, API 190914]
000000.000: SATSAT Mimas: Terms 113
000000.000: Module Enceladus.dll ......... [Build 190914, API 190914]
000000.000: SATSAT Enceladus: Terms 33
000000.000: Module Tethys.dll ............ [Build 190914, API 190914]
000000.000: SATSAT Tethys: Terms 101
000000.000: Module Dione.dll ............. [Build 190914, API 190914]
000000.000: SATSAT Dione: Terms 59
000000.000: Module Rhea.dll .............. [Build 190914, API 190914]
000000.000: SATSAT Rhea: Terms 68
000000.000: Module Titan.dll ............. [Build 190914, API 190914]
000000.000: SATSAT Titan: Terms 100
000000.000: Module Iapetus.dll ........... [Build 190914, API 190914]
000000.000: SATSAT Iapetus: Terms 605
000000.000: Module Uranus.dll ............ [Build 190914, API 190914]
000000.000: VSOP87(B) Uranus: Precision 1.0e-06, Terms 1827/5269
000000.000: Module Miranda.dll ........... [Build ******, API 060425]
000000.000: Module Ariel.dll ............. [Build ******, API 060425]
000000.000: Module Umbriel.dll ........... [Build ******, API 060425]
000000.000: Module Titania.dll ........... [Build ******, API 060425]
000000.000: Module Oberon.dll ............ [Build ******, API 060425]
000000.000: Module Neptune.dll ........... [Build 190914, API 190914]
000000.000: VSOP87(B) Neptune: Precision 1.0e-06, Terms 391/2024
000000.000: Finished initialising world
000000.000: Module DeltaGlider.dll ....... [Build 190914, API 190914]
000000.000: Module LuaInline.dll ......... [Build 190914, API 190914]
000000.000: Module ShuttleA.dll .......... [Build 190914, API 190914]
000000.000: >>> ERROR: No vessel class configuration file found for:
000000.000: ============================ ERROR: ===========================
000000.000: <<<<<<< .mine
000000.000: [Vessel::OpenConfigFile | ..\Vessel.cpp | 243]
000000.000: ===============================================================
000000.000: >>> TERMINATING <<<

**kuddel** · 09-15-2019, 08:57 PM

Quote:

Originally Posted by Ripley

Rev. 90 crashes upon start with this log (both d3d9 and d3d7):

Code:

...
000000.000: >>> ERROR: No vessel class configuration file found for:
000000.000: ============================ ERROR: ===========================
000000.000: <<<<<<< .mine
000000.000: [Vessel::OpenConfigFile | ..\Vessel.cpp | 243]
000000.000: ===============================================================
000000.000: >>> TERMINATING <<<

Is ".mine" yours? I mean you might have to try a stock scenario first. And possibly re-compile the ship (.mine) against the r90 libraries/headers.
The r90 works fine here, so it's not a general issue as far as I can say.

**Ripley** · 09-16-2019, 05:10 AM

I'm no developer, so "mine" means Martin's, I guess.
It was a stock scenario, IIRC "Dg at brighton beach".

**martins** · 09-16-2019, 10:23 AM

I'm pretty sure that

<<<<<<< .mine

isn't a vessel class name, but an SVN conflict flag

Did you get any conflict warnings during the SVN update? Look at the scenario you are trying to run. There will be one or several patterns like this:

<<<<<<< .mine
[some stuff]
========
[some other version of the same stuff]
>>>>>>> .SVN head revision

You will have to merge the two conflicting sections by hand and remove the conflict indicators. Some SVN-aware editors such as winmerge can make the task easier. Or if you simply want to discard your own modifications, you can delete the file and check it out again.

Edit: the other possibility is that I messed up my own local source repository, and submitted a corrupted file to the public repository. I'll check that out. Which scenario file is that?

Edit2:

Quote:

It was a stock scenario, IIRC "Dg at brighton beach".

Sorry, missed that before. If it was Delta-glider\Brighton Beach.scn, then this looks ok here. It seems to run ok, so the conflict is probably on your side.

**Ripley** · 09-16-2019, 11:13 AM

Ok.
In fact I did have an SVN conflict, but only on current_scenario.scn...
I'm at work now, I'll be able to check later in the evening.

---------- Post added at 11:13 ---------- Previous post was at 11:10 ----------

Quote:

Originally Posted by martins

...Or if you simply want to discard your own modifications...

I didn't make any.

**martins** · 09-16-2019, 11:17 AM

Let me know what you find. If the problem arose in the [Current scenario] then that isn't unexpected. If it happened in the stock Delta-glider\Brighton Beach scenario, that would be a bit more worrying. To my knowledge, I haven't changed that file in a long time, so checking it out shouldn't cause a conflict, even if you modified it locally - it should just keep your local version. A conflict might indicate that something went wrong with the time stamps in the repository.

**Ripley** · 09-16-2019, 08:57 PM

Well now I'm home. Don't ask me how, but I've just rerun all the scenarios in stock Delta-glider\ folder (both inline and D3D9), and nothing crashed.
To add to that, I remembered that after the SVN conflict (but before the crashes), I've run "TortoiseSVN" -> "Clean up..."

Anyway, no crashes now, so...

02-24-2019, 08:13 AM	#574
Nikogori Donator	I don't know if anyone has already mentioned this, but... where is the PWR button on VC? Attached Thumbnails

03-05-2019, 06:43 PM	#577
kuddel Donator	Issue with BETA r87 I've noticed an issue with r86 (and r87 as well). The body-force-vectors (torque in particular) is/are displayed oddly... I've checked r86 and r87, but it could have been in there before... Attached Thumbnails Last edited by kuddel; 03-05-2019 at 07:28 PM. Reason: typo

09-15-2019, 08:57 PM	#580
kuddel Donator	Quote: Originally Posted by Ripley Rev. 90 crashes upon start with this log (both d3d9 and d3d7): Code: ... 000000.000: >>> ERROR: No vessel class configuration file found for: 000000.000: ============================ ERROR: =========================== 000000.000: <<<<<<< .mine 000000.000: [Vessel::OpenConfigFile \| ..\Vessel.cpp \| 243] 000000.000: =============================================================== 000000.000: >>> TERMINATING <<< Is ".mine" yours? I mean you might have to try a stock scenario first. And possibly re-compile the ship (.mine) against the r90 libraries/headers. The r90 works fine here, so it's not a general issue as far as I can say.

Quick Links	Need Help?
About Us Register to Participate Orbiter Website Orbiter Download Projects Recommended Addons Orbit Hangar Mods Photo Gallery Social Groups External Links	Did you forget your password? Rules & Guidelines Frequently Asked Questions Orbiter F.A.Q. Orbiter Tutorials Orbiter IRC Chat Search Forum Site Map Contact Us Mark Forums Read

02-21-2019, 10:40 PM	#572
martins Orbiter Founder	Quote: Originally Posted by kuddel I am trying to adopt D3D9Client, but I am not sure what .props-file I should use instead of the former orbiter.props. The most luck I have when I use "VS2015\PropertyPages\orbiter_plugin.props", but still at link-time a giant mess comes up ...still working on that. Could you explain the new structure of you property sheets? a) was it reasonable to switch from "resources\Orbiter.props" to "VS2015\PropertyPages\orbiter_plugin.props" ? b) Should we only take the .props-files from the PropertyPages directory? To be honest, the main reason for the change was to make my life easier by unifying the build systems for the Orbiter core and Orbiter SDK samples. So essentially all I did was to copy the property pages from the core build system into Orbitersdk and checking that the samples still compile. Hence also the distinction between the "Src" and "Build" directories. For the SDK samples, those will nornally be the same as you say, although technically, you should be able to move the entire Orbitersdk subdirectory to an arbitrary place and still be able to compile everything to their proper target locations by modifying the SrcDir and BuildDir locations in orbiter.props accordingly. So in summary: a) the build setup is now a bit easier for me (although in hindsight, restructuring the build system may have been more hassle than it was worth), but it could have added a bit of inconvenience to users who had already incorporated the previous structure into their own build mechanism - sorry for that! b) yes. Quote: Update: Debug-Build: Works with just changing to "VS2015\PropertyPages\orbiter_plugin.props" Release-Build: Still fails linking (I think a standard library is missing...) ...hold the line... 2nd update: The inherited value of %(IgnoreSpecificDefaultLibraries) made the release-build fail. So when the build configuration doesn't inherit Link->IgnoreSpecificDefaultLibraries (rendering it's value empty on RELEASE) it works. Interesting. I don't even know where the %(IgnoreSpecificDefaultLibraries) is populated from. Is this an environment variable? What value does it have in your case? So just to confirm: removing %(IgnoreSpecificDefaultLibraries) from the <IgnoreSpecificDefaultLibraries> entry in orbiter_module.props (but leaving LIBCMT in) makes it work? Quote: Ah... and by the way: it seems that all the macros like $(SDKLibDir) have been split into two versions: $(SrcSdkLibDir) and $(BuildSdkLibDir), right? From a quick look at them they are all the same for us (non-orbiter-core-)developers, right? So it's up to us whether we choose one or the other? Yes, see above.

02-21-2019, 11:00 PM	#573
kuddel Donator	Quote: Originally Posted by martins So just to confirm: removing %(IgnoreSpecificDefaultLibraries) from the <IgnoreSpecificDefaultLibraries> entry in orbiter_module.props (but leaving LIBCMT in) makes it work? No, don't change orbiter_module.props! I would never have touched any of the files from the orbiter package That sheet works fine for debug-builds (where LIBCMT should be omitted) but fails to link during release-builds. I just changed the setting in our project file (kind of override). Why our release-build needs LIBCMT and our debug-build doesn't is a -to be honest- an phenomenon I have not (yet) understood.

02-24-2019, 07:28 PM	#575
martins Orbiter Founder	Quote: Originally Posted by Nikogori I don't know if anyone has already mentioned this, but... where is the PWR button on VC? Ah yes, this is a bit of a design flaw. We have already complained a few times to the British manufacturer, but they are citing Brexit uncertainties for glitches in their manufacturing process. I quote: "No deal, no more power buttons" ...

02-25-2019, 09:59 AM	#576
Nikogori Donator	Quote: Originally Posted by martins Ah yes, this is a bit of a design flaw. I thought it was called "design feature".

03-05-2019, 07:02 PM	#578
GLS Addon Developer	Quote: Originally Posted by kuddel I've noticed an issue with r86 (and r87 ass well). The body-force-vectors (torque in particular) is/are displayed oddly... I've checked r86 and r87, but it could have been in there before... I see the same with r85.

09-16-2019, 05:10 AM	#581
Ripley Tutorial translator	I'm no developer, so "mine" means Martin's, I guess. It was a stock scenario, IIRC "Dg at brighton beach".

09-16-2019, 10:23 AM	#582
martins Orbiter Founder	I'm pretty sure that <<<<<<< .mine isn't a vessel class name, but an SVN conflict flag Did you get any conflict warnings during the SVN update? Look at the scenario you are trying to run. There will be one or several patterns like this: <<<<<<< .mine [some stuff] ======== [some other version of the same stuff] >>>>>>> .SVN head revision You will have to merge the two conflicting sections by hand and remove the conflict indicators. Some SVN-aware editors such as winmerge can make the task easier. Or if you simply want to discard your own modifications, you can delete the file and check it out again. Edit: the other possibility is that I messed up my own local source repository, and submitted a corrupted file to the public repository. I'll check that out. Which scenario file is that? Edit2: Quote: It was a stock scenario, IIRC "Dg at brighton beach". Sorry, missed that before. If it was Delta-glider\Brighton Beach.scn, then this looks ok here. It seems to run ok, so the conflict is probably on your side.

09-16-2019, 11:13 AM	#583
Ripley Tutorial translator	Ok. In fact I did have an SVN conflict, but only on current_scenario.scn... I'm at work now, I'll be able to check later in the evening. ---------- Post added at 11:13 ---------- Previous post was at 11:10 ---------- Quote: Originally Posted by martins ...Or if you simply want to discard your own modifications... I didn't make any.

09-16-2019, 11:17 AM	#584
martins Orbiter Founder	Let me know what you find. If the problem arose in the [Current scenario] then that isn't unexpected. If it happened in the stock Delta-glider\Brighton Beach scenario, that would be a bit more worrying. To my knowledge, I haven't changed that file in a long time, so checking it out shouldn't cause a conflict, even if you modified it locally - it should just keep your local version. A conflict might indicate that something went wrong with the time stamps in the repository.

09-16-2019, 08:57 PM	#585
Ripley Tutorial translator	Well now I'm home. Don't ask me how, but I've just rerun all the scenarios in stock Delta-glider\ folder (both inline and D3D9), and nothing crashed. To add to that, I remembered that after the SVN conflict (but before the crashes), I've run "TortoiseSVN" -> "Clean up..." Anyway, no crashes now, so...