New Orbiter SVN commit (r.71, Oct 14 2017)

kuddel

Donator
Donator
The "Orbiter 2016.zip" contains them (Textures\Callisto\Archive\Surf.tree and Textures\Ganymede\Archive\Surf.tree), the SVN repo doesn't.
I used to work on the SVN repository only and add the HiRes Textures on top.

But now when I read the last note on betainstall.html it clearly states:
[...]
Note that the texture maps for most of the planetary bodies are not included in the SVN repository. You need to install those separately. The easiest way is to re-use the texture directory from an existing Orbiter 2016 installation
[...]

Thanks for the hint!
So it's "svn checkout" + "2016 Textures" + "HiRes textures" now :thumbup:

You never stop learning :tiphat:

Summary: There is no bug! Thanks again Martin.

Last edited:

Ripley

Tutorial translator
Donator
Another Titan problem: Planetarium mode shows Saturn's rings (and more) in foreground.

Orbiter2016 - HiRes tex - D3D9 R3.2 - Cloud layer ON

kuddel

Donator
Donator
Strange! Although these lines look more like something else than Saturns rings...
To reproduce the issue easier, could you provide a scenario of that view, please?

Ripley

Tutorial translator
Donator
It's the standard Solar System -> Titan scenario

kuddel

Donator
Donator
Hmm I can't reproduce the issue.
Are you sure you haven't any orbit-drawing add-on enabled?
It looks more like that.

But let me double-check what exact version of D3D9Client I've used...

...no, it's R3.2 (rev. 1012 however, that might behave slightly different)
I'll try the "posted" R3.2 ....

...no, even with the R3.2 (rev. 995) version Jarmo posted here I can't reproduce the issue.

So my theory is: any orbit-drawing add-on enabled?

Last edited:

Donator

GLS

Well-known member
Orbiter Contributor
No issues so far in r85...

martins

Orbiter Founder
Orbiter Founder
No issues so far in r85...

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.

Donamy

Donator
Beta Tester
Does that have anything to do, with the rotation attachment problem ?

jarmonik

Well-known member
Orbiter Contributor
Beta Tester
Does that have anything to do, with the rotation attachment problem ?
What problem ? If the problem is reproducable in D3D9 then, very likely no. We haven't used the mul() and all the math is done in the client side as far as I remember. But if you could describe the problem better with a screen shot, and if there is a code available that produces the problem that would be really helpfull. Does it occur with stock Atlantis ?

DaveS

Space Shuttle Ultra Project co-developer
Donator
Beta Tester
What problem ? If the problem is reproducable in D3D9 then, very likely no. We haven't used the mul() and all the math is done in the client side as far as I remember. But if you could describe the problem better with a screen shot, and if there is a code available that produces the problem that would be really helpfull. Does it occur with stock Atlantis ?

GLS

Well-known member
Orbiter Contributor
(not sure if these showed up on r85 or were present before)
I was just checking that the 3D terrain in Hyperion and Mercury worked (the .cfg files were changed), when I found a "pillar" in the terrain near the North Pole of Hyperion, similar to the ones I found in Madeira Island in a previous post. Checked the South Pole and it has a hole...

On to Mercury, and there is a tile elevation offset in the North Pole, similar to what happens on Earth's equator as reported in a previous post. Nothing obvious on the South Pole (can't tell much anyway :shrug.
WARNING: memory usage goes thru the roof near the poles.

DaveS

Space Shuttle Ultra Project co-developer
Donator
Beta Tester
(not sure if these showed up on r85 or were present before)
I was just checking that the 3D terrain in Hyperion and Mercury worked (the .cfg files were changed), when I found a "pillar" in the terrain near the North Pole of Hyperion, similar to the ones I found in Madeira Island in a previous post. Checked the South Pole and it has a hole...

On to Mercury, and there is a tile elevation offset in the North Pole, similar to what happens on Earth's equator as reported in a previous post. Nothing obvious on the South Pole (can't tell much anyway :shrug.
WARNING: memory usage goes thru the roof near the poles.
I wonder if all these terrain issues are related as with SSU with have this: https://www.orbiter-forum.com/showthread.php?p=587506&postcount=5

jarmonik

Well-known member
Orbiter Contributor
Beta Tester

I tried the scenario but I couldn't reproduce the issue. So, it's a slow constant drift and not a sudden jump ?

The problem could exists in the method used for the animations. Currently animation state is converted to a velocity (i.e. step over current frame) and then it's applied separately to visible animations and grapple points. That could cause the two, (three to be exact), parallel systems to drift overtime due to small errors. It's very hard to paint a "big picture" about all the systems that could contribute to these errors.

I looked at the code to see if it could be converted to use absolute position instead of velocity but quickly discovered a potintial showstopper with this code.

PHP:
if (trans->mesh == LOCALVERTEXLIST) { // transform a list of individual vertices
VECTOR3 *vtx = (VECTOR3*)trans->grp;
for (i = 0; i < trans->ngrp; i++) TransformPoint(vtx[i], T);
}

There is no info about original vertices just the previous frame.

Of course, one that might work on D3D9 is to use gcGetMatrix() call to get a matrix for a graple-point transformations. It should be possible to add the functionality also to DX7.
.

Donamy

Donator
Beta Tester
It is desperately needed, in order to fly a ISS Assembly mission.

kuddel

Donator
Donator
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 )

Last edited:

martins

Orbiter Founder
Orbiter Founder
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.

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?
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

Donator
Donator
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 :thumbup:
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

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

Attachments

• 0025.jpg
132.1 KB · Views: 62

Replies
3
Views
188
Replies
46
Views
1K
Replies
16
Views
695
Replies
1
Views
352
Replies
10
Views
724