New Release Interplanetary Modular Spacecraft RC9

No relativistic flights....

Just for the heck of it, would relativistic effects start to affect this at all?

Well, I'm not sure, since the mission takes 100 days to get to Pluto and light speed takes less than a day. So I'd say no. ;)

The speed of light is 300,000 km/sec and my delta V is 288 km/sec to get out of earth orbit and 350 km/sec to get into Pluto orbit. That's much less than 0.1% the speed of light.

To quote Carl Sagan, "Weird things start to happen when you approach the speed of light." And I'm sure others would agree that the SSTV is a "Weird Thing", so that would explain it. The SSTV "Happens" when you approach the speed of light. ;)

(Or is that just my sense of humor happening?)

Dantassii
HUMONGOUS IMS shipbuilder
 
Well, I'm not sure, since the mission takes 100 days to get to Pluto and light speed takes less than a day. So I'd say no. ;)

The speed of light is 300,000 km/sec and my delta V is 288 km/sec to get out of earth orbit and 350 km/sec to get into Pluto orbit. That's much less than 0.1% the speed of light.

To quote Carl Sagan, "Weird things start to happen when you approach the speed of light." And I'm sure others would agree that the SSTV is a "Weird Thing", so that would explain it. The SSTV "Happens" when you approach the speed of light. ;)

(Or is that just my sense of humor happening?)

Dantassii
HUMONGOUS IMS shipbuilder

:lol:

Better phrased: crazy things will start to happen when Dantassi ever gets into space. We will have an Engineer GONE WILD!!!

All the same though, I suspect you probably would see a small effect from relativity. Maybe 10-15 second difference between GET & spacecraft clock?
 
Relativistic thoughts

:lol:

Better phrased: crazy things will start to happen when Dantassii ever gets into space. We will have an Engineer GONE WILD!!!

All the same though, I suspect you probably would see a small effect from relativity. Maybe 10-15 second difference between GET & spacecraft clock?

Actually, since the mission is so short, its probably going to be fractions of a second. The inaccuracies of on-board clocks will probably add more deviation than you'll see due to relativity.

If I remember the numbers from the TV show Cosmos, you have to get up around 50% the speed of light before you start seeing enough relativity effects that you can easily measure them.

According to the tech specs for the interstellar spacecraft used in Avatar to go from Earth to Pandora and back, they get going up to 70% light speed and their 4 year (ship time) trip to Pandora takes 17 years of real time.

I've been making spaceships since I was 8 years old. I built a Saturn V with all working stages, a LM, and a CSM using only standard size/shaped Lego blocks. It was nearly 6' tall. Considering I was only around 4' tall at the time, you could say I've been building HUMONGOUS spacecraft for 40 years now. ;)

Glad to see someone enjoying my spacecraft though, even if their reaction is :blink:, their hands are :facepalm:, and the only thought going through their minds is :OMG:.

Dantassii
HUMONGOUS IMS shipbuilder
 
I found a critical bug in RC3 and what confuses me is that noone else seems to found it yet, so it maybe is something on my side. Please try to reproduce it guys and report your results.

1) Spawn a CM;
2) Spawn anything else of IMS modules (Node, for example) and dock it with CM (do not integrate!);
3) Save/Quit/Load.
4) Tell me what you've got.

For me it looks like an IMS vessel appears in parallel universe where polar coordinates are negative (can be clearly seen from a scenario, like that:

Code:
OMS_Orbitalis:IMS\SBB41BRev2\Command_Modules\BM201_CONTROL_MODULE
  STATUS Orbiting Earth
  RPOS -6731889.01 506325.60 -1163847.41
  RVEL 1419.029 3091.439 -6834.493
  AROT -49.83 36.03 164.90

) and no meshes visible. All other vessels in the scenario are fine.

I also find the automatic attachment quite inconvenient when assembling a vessel in natural way (i.e. tugging modules with another vessel), maybe it's a good idea to make this feature switchable.

---------- Post added at 22:44 ---------- Previous post was at 16:47 ----------

Additional info on the bug:

It's D3D9-realted problem, it's not happening under inline client. I'm using the IMS-patch of D3D9 client.
There's nothing wrong with coordinates from the scenario, it's how they're being processed at the startup, because loading the same scenario under inline client goes just fine.

I'm having a CTD too when trying to dock and integrate truss (or anything else) to main vessel in the same session under D3D9-client (Dock#6 of Orbitalis to Dock#5 of the truss):

Code:
BEGIN_DESC

END_DESC

BEGIN_ENVIRONMENT
  System Sol
  Date MJD 56560.4609842001
END_ENVIRONMENT

BEGIN_FOCUS
  Ship OMS_Orbitalis
END_FOCUS

BEGIN_CAMERA
  TARGET OMS_Orbitalis
  MODE Extern
  POS 5.08 -110.06 -29.97
  TRACKMODE TargetRelative
  FOV 60.00
END_CAMERA

BEGIN_HUD
  TYPE Orbit
  REF AUTO
END_HUD

BEGIN_PANEL
END_PANEL

BEGIN_SHIPS
OMS_Orbitalis:IMS\SBB41BRev2\Command_Modules\BM201_CONTROL_MODULE
  STATUS Orbiting Earth
  RPOS -3325216.41 -2476634.92 5459939.79
  RVEL -6669.920 1506.095 -3381.962
  AROT -39.53 68.62 -86.81
  AFCMODE 7
  PRPLEVEL 0:0.000001 1:0.000000 2:0.000001
  NAVFREQ 0 0
  COMMAND 0 1
  MODULE SBB41BRev2\Connection_Parts\BN200_Big_Node 0,0,7.276 0,-1,0 1,0,0 0
  MODULE SBB41BRev2\Docking_Ports\DAAPAS_Docking_Adapter 0,0,9.476 0,0,1 0,1,0 0
  MODULE SBB41BRev2\Pressurized\BM212_Briefing_Room 0,0,-10.1521 0,0,1 0,1,0 0
  MODULE SBB41BRev2\Connection_Parts\BN200_Big_Node 0,0,-17.4285 0,1,0 1,0,0 0
  TDPOINT 0,0,0 0,0,0 0,0,0
  DELETEPOINT 2
  DELETEPOINT 1
  ATTPOINT IM 2.2,0,7.276 1,0,0 0,0,-1
  ATTPOINT IM -2.2,0,7.276 -1,0,0 0,0,-1
  ATTPOINT IM 0,-2.2,7.276 0,-1,0 0,0,-1
  ATTPOINT IM 0,2.2,7.276 0,1,0 0,0,-1
  ATTPOINT IM 0,0,-19.6288 0,0,-1 1,0,0
  ATTPOINT IM 2.2,0,-17.4288 1,0,0 0,0,1
  ATTPOINT IM -2.2,0,-17.4288 -1,0,0 0,0,1
  ATTPOINT IM 0,2.2,-17.4288 0,1,0 0,0,1
  ATTPOINT IM 0,-2.2,-17.4288 0,-1,0 0,0,1
  DELETEPORT 1
  DELETEPORT 0
  CONSTRUCTIONPORT 2.2,0,7.276 1,0,0 0,0,-1
  CONSTRUCTIONPORT -2.2,0,7.276 -1,0,0 0,0,-1
  CONSTRUCTIONPORT 0,-2.2,7.276 0,-1,0 0,0,-1
  CONSTRUCTIONPORT 0,2.2,7.276 0,1,0 0,0,-1
  DOCKPORT 0,0,9.8262 0,0,1 0,1,0
  CONSTRUCTIONPORT 0,0,-19.6288 0,0,-1 1,0,0
  CONSTRUCTIONPORT 2.2,0,-17.4288 1,0,0 0,0,1
  CONSTRUCTIONPORT -2.2,0,-17.4288 -1,0,0 0,0,1
  CONSTRUCTIONPORT 0,2.2,-17.4288 0,1,0 0,0,1
  CONSTRUCTIONPORT 0,-2.2,-17.4288 0,-1,0 0,0,1
  EMPTYMASS 25250.000000
  MASSCENTER 0.000000 0.000000 -4.932010
  PMI 10.554157 10.615938 4.206416
  CONSUMABLES 136 0.0001 0 520 0.0001 0 100 0.0001 0
  TEMPERATURES -1:298.00:0.04 2:298.00:0.05
  HEATING -1
  THGROUPLEVELS 0 0 0 0 
  CREW 2 0
  ENERGY 594000000.000000
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
  MFC 0 0 0 -1 -1 -1 -1
END
truss1:IMS\SBB41BRev2\Connection_Parts\BT101_Truss
  STATUS Orbiting Earth
  RPOS -3325196.01 -2476629.84 5459933.63
  RVEL -6669.734 1506.141 -3382.018
  AROT -39.53 68.62 -86.81
  AFCMODE 7
  NAVFREQ 0 0
END
END_SHIPS

It works fine under inline client too.

---------- Post added 27-09-13 at 01:16 ---------- Previous post was 26-09-13 at 22:44 ----------

Now, it seems I was plainly wrong before. D3D9 client is inocent, at least in the case of CTD. I managed to reproduce the CTD under inline client by turning on all the modules which were active under D3D9 in my Orbiter installation. It was stable before because all the modules except of ScenEd and OrbiSound was off for inline client.

And here's the problem: seems like we have another memory leak or something, because I can't find some exact module guilty of causing troubles: sometimes all of them active and nothing bad happens, sometimes just some random modules are on and here it is again crashing. I wouldn't be surprised if noone could reproduce this bug. Damn. It reminds me of the times of earlier IMS betas - such things were common then.

---------- Post added at 01:34 ---------- Previous post was at 01:16 ----------

I managed to reproduce the CTD under RC2.3, so I guess it's just my Orbiter being swarmed by partly incompatible addons.

BUT! The first bug mentioned is real - the 'parallel universe' bug. I reproduced it with all modules except of SceEd and OrbiSound off under D3D9 client in RC3 and it was no bug effect neither under inline client nor under RC 2.3.

By the way, now when you've fixed D3D9, will RC 2.3 be compatible with it?
 
By the way, now when you've fixed D3D9, will RC 2.3 be compatible with it?

No. the main issue was never client side, it was due to IMS using functions for mesh transformation that do not work with graphics clients. The bugs I found in D3D9 client were only a nuisance that croped up once IMS should actually have worked with it.

Well, something is fishy with that ups and file... I do get a crash when the epp file is loaded (not when it's not loaded, mind you, I just had an unmatching cap in the name so it never got actually loaded so far). There's either something fishy in the file or in the parser, but since Sol loads without problems it seems that the file is more suspect.

---------- Post added at 04:03 PM ---------- Previous post was at 03:24 PM ----------

1) Spawn a CM;
2) Spawn anything else of IMS modules (Node, for example) and dock it with CM (do not integrate!);
3) Save/Quit/Load.
4) Tell me what you've got.

For me it looks like an IMS vessel appears in parallel universe where polar coordinates are negative (can be clearly seen from a scenario, like that:

No repro, works without trouble here... Is there maybe anything specific about how the attached module has to be aligned to get the bug?
 
Last edited:
No repro, works without trouble here... Is there maybe anything specific about how the attached module has to be aligned to get the bug?

Jedidia, we seem to be having a lot of issues with unreproducible errors. Would you mind doing a compile & updating the RC3 link with it? I just want to be sure that we arent working from different versions by accident.
 
But you get it consistently under D3D9?

Would you mind doing a compile & updating the RC3 link with it? I just want to be sure that we arent working from different versions by accident.

That already wouldn't be the same version anymore, and I have a couple of surefire bugs I want to fix first before uploading RC4.

---------- Post added at 12:26 PM ---------- Previous post was at 11:47 AM ----------

Right. Several bugs in the Ups And configuration file.

Planet 2 moon 5 notes 4 gases, but declares only three. first value in the line has to be changed to 3.

Planet 3 moon 4 declares two gases, but is missing a value. Add a 0 at the end of the line.

Planet 3 moon 5, same thing

In Orbiter Galaxy these things go unnoticed, but I made the epp parser more sane in the meantime, so now they cause a crash...

There's also a problem with deallocation of animations with that scenario, which I haven't seen so far. Did you manually alter something in the scenario, Bruce?
 
But you get it consistently under D3D9?



That already wouldn't be the same version anymore, and I have a couple of surefire bugs I want to fix first before uploading RC4.

---------- Post added at 12:26 PM ---------- Previous post was at 11:47 AM ----------

Right. Several bugs in the Ups And configuration file.

Planet 2 moon 5 notes 4 gases, but declares only three. first value in the line has to be changed to 3.

Planet 3 moon 4 declares two gases, but is missing a value. Add a 0 at the end of the line.

Planet 3 moon 5, same thing

In Orbiter Galaxy these things go unnoticed, but I made the epp parser more sane in the meantime, so now they cause a crash...

Errkhey, fixed the config errors like you said, heres the file if anyone wants it:

View attachment 12153

There's also a problem with deallocation of animations with that scenario, which I haven't seen so far. Did you manually alter something in the scenario, Bruce?

Ummm, no changes manually in this one. There are solar panels and radiators in this scenario though, so that would need a dynamically allocated animation (I'm pretty sure IMS needs to allocate just about everything dynamically).

Would you mind uploading the current RC3 source code in the IMS group so I could take a look at it? I wouldnt mind being able to finally help with that a bit.
 
There are solar panels and radiators in this scenario though, so that would need a dynamically allocated animation (I'm pretty sure IMS needs to allocate just about everything dynamically).

Since it doesn't have any idea what it's supposed to be capable of, everything's dynamic, yes. The odd thing is that this seems to be the only scenario I'm having this particular problem... I'd expect something like this to rather parvasive.

Would you mind uploading the current RC3 source code in the IMS group so I could take a look at it? I wouldnt mind being able to finally help with that a bit.

It's a nice offer, thanks, but I'm afraid if I don't make a repository, two pairs of hands in the code is somewhat impractical at this stage.
 
It's a nice offer, thanks, but I'm afraid if I don't make a repository, two pairs of hands in the code is somewhat impractical at this stage.

Its okay, I would just like to look at it if that's okay with you. :thumbup:
 
Already got the deallocation problem down, something I changed when trying to fix the animation problem with D3D9 client and didn't change back. Not quite clear why it produced only a crash in this particular scenario, but that's memory managment for you...

I seem to have quite a number of leaks in there, too, as VLD tells me. Now if only I could find them...
 
Memory leaks, UGH!

I seem to have quite a number of leaks in there, too, as VLD tells me. Now if only I could find them...

Memory leaks are the most insidious 'feature' of any C/C++ based program. They are nearly impossible to find unless you instrument your code extensively to keep track of each and every time memory is allocated/de-allocated dynamically and toss a warning when the numbers don't reach ZERO during a run.

Dantassii
HUMONGOUS IMS shipbuilder
 
Memory leaks are the most insidious 'feature' of any C/C++ based program. They are nearly impossible to find unless you instrument your code extensively to keep track of each and every time memory is allocated/de-allocated dynamically and toss a warning when the numbers don't reach ZERO during a run.

Good instrumentation doesn't come cheap... VLD gives me a few pointers, and I know the code enough by know to usually find stuff. In this case, I found something I had completely overlooked... Common data of modules is stored in a static global map. That includes arrays with animation groups, and they don't get deallocated. The problem still dates back to vchamp.
Anyways, I have another weird problem, which is that when I want to deallocate the map in ExitModule, the map is empty... Allthough I can't find a clear anywhere in the code. No idea yet what happens to it, but without the map I can't get the pointers to free them.
 
This looks amazingly brilliant :)

One problem though:

Can anybody confirm Bruce's observations? anybody else having trouble with reloading a scenario? There is a possibility of a corrupted file in the download, after all...

Yes I can confirm that.

This is what my log looks like after CTD:

Code:
**** Orbiter.log
Build Aug 30 2010 [v.100830]
Timer precision: 3.1328e-010 sec
Found 0 joystick(s)
Devices enumerated: 3
Devices accepted: 3
==> RGB Emulation
==> Direct3D HAL
==> Direct3D T&L HAL
Module AtlantisConfig.dll .... [Build 100830, API 100830]
Module AtmConfig.dll ......... [Build 100830, API 100830]
Module DGConfigurator.dll .... [Build 100830, API 100830]

**** Creating simulation session
DirectDraw interface OK
Direct3D interface OK
Graphics: Viewport: Window 1594 x 875 x 32
Graphics: Hardware T&L capability: Yes
Graphics: Z-buffer depth: 32 bit
Graphics: Stencil buffer depth: 8 bit
Graphics: Active lights supported: 8
Loading 15382 records from star database
Module Sun.dll ............... [Build 100830, API 100830]
VSOP87(E) Sun: Precision 1e-006, Terms 554/6634
Module Mercury.dll ........... [Build 100830, API 100830]
VSOP87(B) Mercury: Precision 1e-005, Terms 167/7123
Module Venus.dll ............. [Build 100830, API 100830]
Module VenusAtm2006.dll ...... [Build 100830, API 100830]
VSOP87(B) Venus: Precision 1e-005, Terms 79/1710
Module Earth.dll ............. [Build 100830, API 100830]
Module EarthAtmJ71G.dll ...... [Build 100830, API 100830]
VSOP87(B) Earth: Precision 1e-008, Terms 2564/2564
Module Moon.dll .............. [Build 100830, API 100830]
ELP82: Precision 1e-005, Terms 116/829
Module Mars.dll .............. [Build 100830, API 100830]
Module MarsAtm2006.dll ....... [Build 100830, API 100830]
VSOP87(B) Mars: Precision 1e-005, Terms 405/6400
Module Phobos.dll ............ [Build ******, API 060425]
Module Deimos.dll ............ [Build ******, API 060425]
Module Galsat.dll ............ [Build 100217, API 100215]
Module Jupiter.dll ........... [Build 100830, API 100830]
VSOP87(B) Jupiter: Precision 1e-006, Terms 1624/3625
Module Io.dll ................ [Build 100217, API 100215]
Module Europa.dll ............ [Build 100217, API 100215]
Module Ganymede.dll .......... [Build 100217, API 100215]
Module Callisto.dll .......... [Build 100217, API 100215]
Module Satsat.dll ............ [Build 100215, API 100212]
Module Saturn.dll ............ [Build 100830, API 100830]
VSOP87(B) Saturn: Precision 1e-006, Terms 2904/6365
Module Mimas.dll ............. [Build 100215, API 100212]
SATSAT Mimas: Terms 113
Module Enceladus.dll ......... [Build 100215, API 100212]
SATSAT Enceladus: Terms 33
Module Tethys.dll ............ [Build 100215, API 100212]
SATSAT Tethys: Terms 101
Module Dione.dll ............. [Build 100215, API 100212]
SATSAT Dione: Terms 59
Module Rhea.dll .............. [Build 100215, API 100212]
SATSAT Rhea: Terms 68
Module Titan.dll ............. [Build 100215, API 100212]
SATSAT Titan: Terms 100
Module Iapetus.dll ........... [Build 100215, API 100212]
SATSAT Iapetus: Terms 605
Module Uranus.dll ............ [Build 100830, API 100830]
VSOP87(B) Uranus: Precision 1e-006, Terms 1827/5269
Module Miranda.dll ........... [Build ******, API 060425]
Module Ariel.dll ............. [Build ******, API 060425]
Module Umbriel.dll ........... [Build ******, API 060425]
Module Titania.dll ........... [Build ******, API 060425]
Module Oberon.dll ............ [Build ******, API 060425]
Module Neptune.dll ........... [Build 100830, API 100830]
VSOP87(B) Neptune: Precision 1e-006, Terms 391/2024
Finished initialising world
Module DeltaGlider.dll ....... [Build 100830, API 100830]
Module LuaInline.dll ......... [Build 100830, API 100830]
Module ShuttleA.dll .......... [Build 100830, API 100830]
Finished initialising status
Finished initialising camera
Finished initialising panels
Finished setting up render state
**** Closing simulation session

**** Creating simulation session
DirectDraw interface OK
Direct3D interface OK
Graphics: Viewport: Window 1594 x 875 x 32
Graphics: Hardware T&L capability: Yes
Graphics: Z-buffer depth: 32 bit
Graphics: Stencil buffer depth: 8 bit
Graphics: Active lights supported: 8
Loading 15382 records from star database
Module Sun.dll ............... [Build 100830, API 100830]
VSOP87(E) Sun: Precision 1e-006, Terms 554/6634
Module Mercury.dll ........... [Build 100830, API 100830]
VSOP87(B) Mercury: Precision 1e-005, Terms 167/7123
Module Venus.dll ............. [Build 100830, API 100830]
Module VenusAtm2006.dll ...... [Build 100830, API 100830]
VSOP87(B) Venus: Precision 1e-005, Terms 79/1710
Module Earth.dll ............. [Build 100830, API 100830]
Module EarthAtmJ71G.dll ...... [Build 100830, API 100830]
VSOP87(B) Earth: Precision 1e-008, Terms 2564/2564
Module Moon.dll .............. [Build 100830, API 100830]
ELP82: Precision 1e-005, Terms 116/829
Module Mars.dll .............. [Build 100830, API 100830]
Module MarsAtm2006.dll ....... [Build 100830, API 100830]
VSOP87(B) Mars: Precision 1e-005, Terms 405/6400
Module Phobos.dll ............ [Build ******, API 060425]
Module Deimos.dll ............ [Build ******, API 060425]
Module Galsat.dll ............ [Build 100217, API 100215]
Module Jupiter.dll ........... [Build 100830, API 100830]
VSOP87(B) Jupiter: Precision 1e-006, Terms 1624/3625
Module Io.dll ................ [Build 100217, API 100215]
Module Europa.dll ............ [Build 100217, API 100215]
Module Ganymede.dll .......... [Build 100217, API 100215]
Module Callisto.dll .......... [Build 100217, API 100215]
Module Satsat.dll ............ [Build 100215, API 100212]
Module Saturn.dll ............ [Build 100830, API 100830]
VSOP87(B) Saturn: Precision 1e-006, Terms 2904/6365
Module Mimas.dll ............. [Build 100215, API 100212]
SATSAT Mimas: Terms 113
Module Enceladus.dll ......... [Build 100215, API 100212]
SATSAT Enceladus: Terms 33
Module Tethys.dll ............ [Build 100215, API 100212]
SATSAT Tethys: Terms 101
Module Dione.dll ............. [Build 100215, API 100212]
SATSAT Dione: Terms 59
Module Rhea.dll .............. [Build 100215, API 100212]
SATSAT Rhea: Terms 68
Module Titan.dll ............. [Build 100215, API 100212]
SATSAT Titan: Terms 100
Module Iapetus.dll ........... [Build 100215, API 100212]
SATSAT Iapetus: Terms 605
Module Uranus.dll ............ [Build 100830, API 100830]
VSOP87(B) Uranus: Precision 1e-006, Terms 1827/5269
Module Miranda.dll ........... [Build ******, API 060425]
Module Ariel.dll ............. [Build ******, API 060425]
Module Umbriel.dll ........... [Build ******, API 060425]
Module Titania.dll ........... [Build ******, API 060425]
Module Oberon.dll ............ [Build ******, API 060425]
Module Neptune.dll ........... [Build 100830, API 100830]
VSOP87(B) Neptune: Precision 1e-006, Terms 391/2024
Finished initialising world
Module DeltaGlider.dll ....... [Build 100830, API 100830]
Module ShuttleA.dll .......... [Build 100830, API 100830]
Finished initialising status
Finished initialising camera
Finished initialising panels
Finished setting up render state
**** Closing simulation session

**** Creating simulation session
DirectDraw interface OK
Direct3D interface OK
Graphics: Viewport: Window 1594 x 875 x 32
Graphics: Hardware T&L capability: Yes
Graphics: Z-buffer depth: 32 bit
Graphics: Stencil buffer depth: 8 bit
Graphics: Active lights supported: 8
Loading 15382 records from star database
Module Sun.dll ............... [Build 100830, API 100830]
VSOP87(E) Sun: Precision 1e-006, Terms 554/6634
Module Mercury.dll ........... [Build 100830, API 100830]
VSOP87(B) Mercury: Precision 1e-005, Terms 167/7123
Module Venus.dll ............. [Build 100830, API 100830]
Module VenusAtm2006.dll ...... [Build 100830, API 100830]
VSOP87(B) Venus: Precision 1e-005, Terms 79/1710
Module Earth.dll ............. [Build 100830, API 100830]
Module EarthAtmJ71G.dll ...... [Build 100830, API 100830]
VSOP87(B) Earth: Precision 1e-008, Terms 2564/2564
Module Moon.dll .............. [Build 100830, API 100830]
ELP82: Precision 1e-005, Terms 116/829
Module Mars.dll .............. [Build 100830, API 100830]
Module MarsAtm2006.dll ....... [Build 100830, API 100830]
VSOP87(B) Mars: Precision 1e-005, Terms 405/6400
Module Phobos.dll ............ [Build ******, API 060425]
Module Deimos.dll ............ [Build ******, API 060425]
Module Galsat.dll ............ [Build 100217, API 100215]
Module Jupiter.dll ........... [Build 100830, API 100830]
VSOP87(B) Jupiter: Precision 1e-006, Terms 1624/3625
Module Io.dll ................ [Build 100217, API 100215]
Module Europa.dll ............ [Build 100217, API 100215]
Module Ganymede.dll .......... [Build 100217, API 100215]
Module Callisto.dll .......... [Build 100217, API 100215]
Module Satsat.dll ............ [Build 100215, API 100212]
Module Saturn.dll ............ [Build 100830, API 100830]
VSOP87(B) Saturn: Precision 1e-006, Terms 2904/6365
Module Mimas.dll ............. [Build 100215, API 100212]
SATSAT Mimas: Terms 113
Module Enceladus.dll ......... [Build 100215, API 100212]
SATSAT Enceladus: Terms 33
Module Tethys.dll ............ [Build 100215, API 100212]
SATSAT Tethys: Terms 101
Module Dione.dll ............. [Build 100215, API 100212]
SATSAT Dione: Terms 59
Module Rhea.dll .............. [Build 100215, API 100212]
SATSAT Rhea: Terms 68
Module Titan.dll ............. [Build 100215, API 100212]
SATSAT Titan: Terms 100
Module Iapetus.dll ........... [Build 100215, API 100212]
SATSAT Iapetus: Terms 605
Module Uranus.dll ............ [Build 100830, API 100830]
VSOP87(B) Uranus: Precision 1e-006, Terms 1827/5269
Module Miranda.dll ........... [Build ******, API 060425]
Module Ariel.dll ............. [Build ******, API 060425]
Module Umbriel.dll ........... [Build ******, API 060425]
Module Titania.dll ........... [Build ******, API 060425]
Module Oberon.dll ............ [Build ******, API 060425]
Module Neptune.dll ........... [Build 100830, API 100830]
VSOP87(B) Neptune: Precision 1e-006, Terms 391/2024
Finished initialising world
Module DeltaGlider.dll ....... [Build 100830, API 100830]
Module ShuttleA.dll .......... [Build 100830, API 100830]
Module IMS.dll ............... [Build 130923, API 100830]

Which leads me to think that it is a problem with the IMS.dll.

This is the IMS.dll I'm using, because I read you were having trouble with reproduction, so you might be able to reproduce it from this.

View attachment IMS.zip
 
Good instrumentation doesn't come cheap... VLD gives me a few pointers, and I know the code enough by know to usually find stuff. In this case, I found something I had completely overlooked... Common data of modules is stored in a static global map. That includes arrays with animation groups, and they don't get deallocated. The problem still dates back to vchamp.
Anyways, I have another weird problem, which is that when I want to deallocate the map in ExitModule, the map is empty... Allthough I can't find a clear anywhere in the code. No idea yet what happens to it, but without the map I can't get the pointers to free them.

What map is this?
 
I just flew Lunar Station Construction Mission 104...

Using RC3 and the IMS compliant D3D9 add on, I was able to keep the FPS well over 25 the entire mission, especially when outside doing the assembly. When I was inside the cockpit of the XR5 looking at the Lunar Station out the window, I had 60 FPS the whole time.

In RC2.3 + D3D7 I rarely got more than 10 FPS outside and 15-20 FPS when inside the XR5 looking at the Lunar Station.

I think my hardware really likes D3D9. :)

The only downsides are the URMS does not flash the closest modules red/green in D3D9 like it does in D3D7 and there are occasions when the screen flashes a white-out condition. I guess I can live with those.

On a side note, when I fired up the scenario with the unintegrated SSTV in it, then went outside for a look, instead of the 6-8 FPS I got with RC2.3 + D3D7, I was seeing 15-25 FPS with RC3 + D3D9. When I turned on F9 to see the module names, that had ZERO impact on the FPS. When I did that under RC2.3 + D3D7 my FPS would go to < 1....

Dantassii
HUMONGOUS IMS shipbuilder
 
When I turned on F9 to see the module names, that had ZERO impact on the FPS. When I did that under RC2.3 + D3D7 my FPS would go to < 1....

Thats interesting...

I wonder why D3D9 would handle that particular process so much more efficiently than D3D7 did. All it is is basically overlaying yellow boxes onto the screen...

Jedidia, is there anything that you can reccomend for my issues with D3D9? I would also like to get it running with my IMS vessels.
 
Thats interesting...

I wonder why D3D9 would handle that particular process so much more efficiently than D3D7 did. All it is is basically overlaying yellow boxes onto the screen...

Well, in D3D9 the module names are very different in size (different/smaller font I think) and you can actually READ them from a distance away on things like the SSTV and Lunar Station that have hundreds of modules on top of each other. With that in mind, I suspect that D3D9 handles the F9 labels in a different manner than D3D7 does.

Dantassii
HUMONGOUS IMS shipbuilder
 
Back
Top