New Release Interplanetary Modular Spacecraft RC9

[Michael_Chr]

One more thing...
Thinking about the path/filename issue...it might be that the D3D9 client is particular path and name sensitive. To an extent where it might not give it self enough time to load meshes etc.
Jedidia...
regarding the D3D9 animation problem... Have you tested the offending modules with animation with a shorter/different paths/filenames?
The iteresting part here is that the Vanilla orbiter exhibits no behavior like this at all.

 

[jedidia]

So have you taken a wander around the SSTV yet Jedidia? What sort of FPS are you getting?

Absolutely unplayable on my laptop, somewhat sticky on my better machine...

By the way...Pursuit MFD is one the the "trickier" MFDs when it comes to CTD so I dont think that IMS perhaps is entirely to blame. But just to let you know...especially with the RCS take on it.

It is highly unlikely that IMS is the problem here... I have no idea how pursuit manages RCS, and it is well possible that it has problems with IMS' dynamic nature of RCS allocation. But I can't change that...

The goos news is that there is a work around...apparently changing to shorter
paths and file names does have an effect on the D3D9 client.

So D3D9 client might have problems with too long filenames... *sigh*. Will see if I can found something more definitive about it, but if your suspicions are correct, there's not really much I can do about it from my end...

ps. the reason why this came along is that I have scenarios with +600 docked modules that run OK in D3D9 so it might not be the number of files but more name and/or path related

Does the CTD occur on IMS loadup (while IMS files are being processed) or at orbiter initialisation (when everything is loaded and the sim should appear on the screen)?

Jededia..Did you kill the TD feature? I mean the one that causes the RCS to jump around (as mentioned previously in this thread).

I didn't kill the feature, I fixed the resulting problem. Even now the problem was not really that drastic: The RCS were moved when you freshly create a finalised vessel from a config file, if you save and reload they will be in their right places again.

The problem was really only that PeterRoss changed the place of initial CoG shift, to be in loadstate, and forgott that if there was no loadstate executed (i.e. the vessel was created on simtime rather than loaded from scenario), the CoG wouldn't be initialised. It took only one more check in the first frame to initialise the CoG if LoadState wasn't called.

Are you talking about IMS 1 or 2?

IMS1 of course. First this thread isn't about IMS2, second I haven't yet developed it any further than what you can see in the IMS user group. I had to brush up the old girl first...

Can we simply "replug'n'play" the relevant thermodynamics, CG Shifting, etc. from IMS RC 2.3

No chance in hell. If I say it's going to be a rewrite, it's going to be a rewrite. The old, overly complicated way of doing things in IMS will (thankfully) be utterly incompatible with IMS2. The only thing I'll be able to reuse are the equations.

Have you tested the offending modules with animation with a shorter/different paths/filenames?

I don't believe the problems are related. Mostly because those scenarios reload perfectly fine after a crash.

 

[Face]

So D3D9 client might have problems with too long filenames... *sigh*. Will see if I can found something more definitive about it, but if your suspicions are correct, there's not really much I can do about it from my end...

After looking at the code of D3D9, I'm not really surprised about this:

https://bitbucket.org/face/ovp/anno...rsdk/D3D9Client/Mesh.cpp?at=D3D9Client#cl-439

https://bitbucket.org/face/ovp/src/...tersdk/D3D9Client/Mesh.h?at=D3D9Client#cl-244

You could try to recompile D3D9 with this limits set to e.g 4k, or perhaps refactor it to use dynamic memory allocation instead (whether direct or via STL shouldn't matter much).

 

[jedidia]

128 characters? ohhhh hell.

Wait... that's only the meshname, though. They shouldn't actually be that long... in fact, they aren't longer than GregBurches default names and paths, since they are the same. Which means that if there is a problem with them in IMS, there should be a problem with the same meshes in standard SSBB use... I'll have to check them names and see if any happen to be too long...

 

[Face]

128 characters? ohhhh hell.

Wait... that's only the meshname, though. They shouldn't actually be that long... in fact, they aren't longer than GregBurches default names and paths, since they are the same. Which means that if there is a problem with them in IMS, there should be a problem with the same meshes in standard SSBB use... I'll have to check them names and see if any happen to be too long...

Well, it is what Orbiter gives the OVP client in clbkStoreMeshPersistent() (API_Reference.pdf p. 254). It also includes all path components from the mesh folder root. If you have a deep enough folder structure and a long name, it could quite be that the limitation is reached.

 

[Michael_Chr]

Not that I can add anything significant to discussion above
Well...other than perhaps point out that (at least from my findings) that it was a change of the *.cfg filename that did the trick (no CTD).
The contents of the said *.cfg file was not altered in any way. Which lead me to the assumption that the path and filename of the mesh is not involved (since they were the same in both "No CTD" as well as "CTD" cases).
But maybe I'm not correct
Also...I am under the impression that module that causes the problem is a "IMS Native module" and not one of Gregs Burchs (i.e. the mesh folder is not the burchismo but the IMS)

 

[jedidia]

That is true for the case you stated, yes... but the IMS mesh folder is shorter than the burchismo mesh folder. The complete pathname passed to the client for that module would be:

Meshes\IMS\SSBBLargeTrussToSmallTrussShort.msh

46 characters. Not nearly enough to cause a problem with the buffer.

The config file path, however, which is also the classname, would be like this:

Vessels\IMS\SBB41BRev2\Connection_Parts\BT302_LargeTrussToSmallTruss_Short

73 characters, 80 if the root gets incorporated, 84 with the extension... still doesn't seem too extravagant. Does anybody know if that string gets passed to D3D9 client at some point?

 

[orb]

(no, that isn't a space in "Large". I don't know why it looks like that in the browser, but there is none in the editor and none in the actual filename)

For line wrapping (to prevent the post box being extended sideways by long strings). You can get the string without spaces being automatically inserted in the [code] box.

 

[jedidia]

For line wrapping (to prevent the post box being extended sideways by long strings).

There's no line wrap necessary in my browser, it just about reaches halfway. But anyways, that's not really the main concern here, and code tags would certainly have been more appropriate

 

[Face]

73 characters, 80 if the root gets incorporated, 84 with the extension... still doesn't seem too extravagant. Does anybody know if that string gets passed to D3D9 client at some point?

Yes. It seems like the object's class name is stored in the vVessel local variable "classname" during some skin-loading callback:

https://bitbucket.org/face/ovp/src/...k/D3D9Client/VVessel.cpp?at=D3D9Client#cl-226

It is restricted to 64 characters there, but it doesn't seems like it is a real problem (on first glance). Also the material manager stores the classname with 256 characters max. here:

https://bitbucket.org/face/ovp/src/...D9Client/MaterialMgr.cpp?at=D3D9Client#cl-236

https://bitbucket.org/face/ovp/src/...D9Client/MaterialMgr.cpp?at=D3D9Client#cl-399

 

[jedidia]

I can see some potential problems of mistaken identity when comparing string cut to 64 characters with one of 256, but looking at the Scenario posted this isn't the case here.

However, the moment of the crash would match the function: After initialisation, but before the sim actually starts running.

One thing isn't quite clear to me, though: if you sprintf to a buffer, as far as I know the 0 terminator gets appended... what happens if you sprintf a string of more than 64 characters into a 64 character buffer? does sprintf realise by itself that it has to put the terminator in before copying all 64 characters, or does it append it after the 64th character was written, in which case we'd have an out-of-bounds situation?

 

[orb]

does sprintf realise by itself that it has to put the terminator in before copying all 64 characters, or does it append it after the 64th character was written, in which case we'd have an out-of-bounds situation?

sprintf_s or strcpy_s with size set to 64 prints/copies at most 63 characters and adds a NULL character at the end.


http://msdn.microsoft.com/library/ce3zzk1k.aspx:

The other main difference between sprintf_s and sprintf is that sprintf_s takes a length parameter specifying the size of the output buffer in characters. If the buffer is too small for the text being printed then the buffer is set to an empty string and the invalid parameter handler is invoked. Unlike snprintf, sprintf_s guarantees that the buffer will be null-terminated (unless the buffer size is zero).

 

[Face]

One thing isn't quite clear to me, though: if you sprintf to a buffer, as far as I know the 0 terminator gets appended... what happens if you sprintf a string of more than 64 characters into a 64 character buffer? does sprintf realise by itself that it has to put the terminator in before copying all 64 characters, or does it append it after the 64th character was written, in which case we'd have an out-of-bounds situation?

I think you mean sprintf_s here. sprintf doesn't give a dime about buffer limits. It will happily write into the blue AFAIK.

sprintf_s will behave like this (from MSDN):

The other main difference between sprintf_s and sprintf is that sprintf_s takes a length parameter specifying the size of the output buffer in characters. If the buffer is too small for the text being printed then the buffer is set to an empty string and the invalid parameter handler is invoked. Unlike snprintf, sprintf_s guarantees that the buffer will be null-terminated (unless the buffer size is zero).

 

[jedidia]

mkay, I'm kind of wondering if this bit of code has any relevance at all to my problem... as far as I can see it is only really relevant if there is a skin configuration file which is not the case. Hrmph. Will probably have to get the whole source code and plug it into the debugger...

 

[Michael_Chr]

I feel with you...Jededia :thumbup:

In the meantime I was able to get the "baddest" IMS scenario I have (544 modules incl a CMD module) up and running in D3D9 by renaming the filenames of modules with long filenames to modules shorter ones.

As I see it this a prerequisite to at all get to the point where you can start integration with the D3D9 client.

I will later see if I can get already finished IMS vessels to start up in D3D9 by modifying the Scenariofiles with all the code of the finished vessels (it will save me the hassle of reinegrating them if and when we ever get IMS to run in D3D9 client). O used to be able to that (prior to release of SBB41B rev2) (it did not look right at all..goes without saying )

All this is off course a D3D9 problem and not an IMS ditto. If the D3D9 client is not updated to rectify this I think we need to look at the filename/path structure of the IMS modules, in order for people to have a more troublefree IMS experience. ..Peter Ross??? (I'l lend a hand if you want to)

 

[jedidia]

If the D3D9 client is not updated to rectify this I think we need to look at the filename/path structure of the IMS modules

Or rectify it ourselves... I have only now really grasped that the source code is so openly available. I'll give it a shot and see if I can solve the two problems we currently still have... As soon as I get my head around how to check out the code.

 

[Face]

Or rectify it ourselves... I have only now really grasped that the source code is so openly available. I'll give it a shot and see if I can solve the two problems we currently still have... As soon as I get my head around how to check out the code.

Since OVP-derived stuff has to be GPL'ed, it is clear that the code can't be locked away somewhere. Just keep in mind that the place I've quoted the code from is my personal mirror of Jarmonik's "official" Codeplex repository here: https://d3d9client.codeplex.com/SourceControl/latest

You can use an SVN client to checkout the trunk HEAD from here: https://d3d9client.svn.codeplex.com/svn

If you want to use Hg, my mirror is just as good, of course.

If you just want to get a ZIP with it, try this: https://bitbucket.org/face/ovp/get/Jarmonik/master.zip

---------- Post added at 16:35 ---------- Previous post was at 16:32 ----------

In the meantime I was able to get the "baddest" IMS scenario I have (544 modules incl a CMD module) up and running in D3D9 by renaming the filenames of modules with long filenames to modules shorter ones.

Could you perhaps try to reproduce the exact length that is the culprit here? If so, we would have a hint where the CTD comes from by searching for the appropriate hard-coded value in the code base.

 

[jedidia]

If you want to use Hg, my mirror is just as good, of course.

I tried, but I can't quite get the hang of it yet... I'm a GUI person, I'm afraid. The only command prompt I can work with is good old DOS

So thanks for the zip, that'll help me to at least see if I can do anything about it.

Now it's only a matter of downloading DXSDK... which is half a gig in size?? WTF? Microsoft, does a bunch of header and library files and a bit of docu really need that much space??

I'll be back in some 10 hours, when my lousy bosnian connection managed to get the whole thing :facepalm:

 

[Face]

I tried, but I can't quite get the hang of it yet... I'm an IDE person, I'm afraid. The only command prompt I can work with is good old DOS

Hg is not Git. There is an excellent GUI there that you can use: TortoiseHg. Don't get misguided by the Tortoise name, though: it is totally different to what you might know from other GUIs of the same name.

Not only does it do the Explorer integration, it also comes with a (much preferred) stand-alone "workbench", that really is closer to an IDE than any VCS-Client I have seen before. And of course you don't have to install more components to get it work, the MSI is all you need. In contrast to e.g. TortoiseSVN, you also get the command-line installation, should you ever need it.

If you prefer a Visual Studio integration, VisualHg is what you can use, but honestly TortoiseHg is so well done that you won't bother with your IDE integration, anyway.

 

[Michael_Chr]

Could you perhaps try to reproduce the exact length that is the culprit here? If so, we would have a hint where the CTD comes from by searching for the appropriate hard-coded value in the code base.

OK..These are my findings:
Using this base path
C:\Program Files (x86)\Orbiter-base_dir\Orbit-e2\Config\Vessels\IMS\SBB41BRev2\Connection_Parts

I find that the filename:
123456789012345678901234567890 (30 chars) > No CTD
1234567890123456789012345678901 (31 chars) > CTD

In the path one level higher (...\Vessels\IMS\SBB41BRev2\)

the filename
Connection_Parts1234567890123456789012345678901 > No CTD
Connection_Parts12345678901234567890123456789012> CTD

Which makes sence in that respect that the pathname (and backslash) is included in the count.

I hope that you guys can make some sense of it. I included my total path from the root so you best can decide from where the count starts.

And so cool that you look into the coding of the D3D9 :thumbup:

Everything runs so much smoother in D3D9 enviroment when the ships increase in size. Granted you have to have some decent HW...But you are nontheless rewarded for good HW. Not the case under the vanilla Client