New Release Interplanetary Modular Spacecraft RC9

[BruceJohnJennerLawso]

The port gets deleted and recreated in the IMS vessel, as every unocupied port. I don't know what Orbiter will do, probably it will delete the assigned frequency along with the port. If not, weirdness may abound.
The frequency will not get reassigned to the new port, i.e. it won't be carried over in integration.

---------- Post added 07-15-13 at 12:13 PM ---------- Previous post was 07-14-13 at 02:12 PM ----------

ou-kay. Looks like I have D3D9 compatibility for this beasty. No definitive confirmation before some more extreme tests, but so far it seems to work.

vchamp used the trick of zooming out the camera and zooming it back in to destroy the visual and force its recreation with the new mesh. I assume this was because AddMesh back in Orbiter 2006 did add a new mesh only when the whole visual was recreated. Or vchamp just never figured out that this workaround wasn't necessary at all, but I highly doubt that. Might also have been coupled to some VC issues, since IMS back in the days had virtual cockpit, something I am very glad I abandoned first thing.

Anyways, that little hack didn't work in D3D9 client. The solution was not to use it at all... Just add the new mesh, don't wait for the destruction of the visual, which never came. So far, everything seems fine...

EDIT:

*sigh* more bugs... now that the graphic side works as intended (well, I seem to have an inverted angle somewhere, but that's easy prey), other bugs rear their head. I start to wonder if it was a good Idea to even touch this code another time. I hope I see the end of this snake soon, or I might just go crazy...

:thumbup: good to hear! Graphics client support is going to be a big step forward for IMS.

A couple of things Ive been wanting to bring up:
-What the heck does the first item under clbkConsumeBufferedKey do in IMS? (some combination of L and another key) I accidentally pressed it while flying the altair and my ships meshes went all colorful.

-I finally got around to isolating that large part-number, time-specific crash that I was having. In this scenario file, the vessel known as Orbital_Yards causes a crash at the same time in every simulation, and removing it fixes the problem. I suspect that it may be the same one that I mentioned earlier

View attachment 11919

 

[jedidia]

Oh, for crying out loud! AddMesh starts to produce major memory weirdness in D3D9 client. Everything works perfectly nice in inline, but in D3D9 I get perfectly reproducable crashes at certain calls to AddMesh. I'm starting to think this isn't worth it...

 

[BruceJohnJennerLawso]

Oh, for crying out loud! AddMesh starts to produce major memory weirdness in D3D9 client. Everything works perfectly nice in inline, but in D3D9 I get perfectly reproducable crashes at certain calls to AddMesh. I'm starting to think this isn't worth it...

what seems to be causing the reproducable ones?

 

[jedidia]

Memory access violations. I consider it improbable that D3D9client is responsible, UCGO would have the same problem if that was the case. I think the case is rather that D3D9 client reacts a bit more sensitive to IMS various atrocities which it undoubtedly commits somewhere behind my back than inline graphics.

I.e., this is a rabitt hole. If I go deeper, there's no telling where it'll lead. I'm currently considering getting the hell out and start digging over the lawn instead.

---------- Post added at 11:24 AM ---------- Previous post was at 07:42 AM ----------

Hmmm... after further tests, it seems very possible that D3D9 client is a lot more sensitive to orbiters problems it obviously has with deleting docking ports (the good old problem). I'm not 100% positive yet, but I think that that behavior just produces an access violation more often in D3D9client than in the inline client.

If that holds true, then that would mean that building in D3D9 client will be two hells of unstable no matter what I do. The only thing I could do against it is ripping out the docking ports and only using the attachment points, but that would already be a rewrite of a good chunk of code. I won't make this rewrite in parts. It'll only require another one when I'm done.

EDIT: No, scratch that. Was running inline client without noticing. The bahavior in D3D9 client is way too precise to be any kind of undefined. Might be possible I'm somehow destroying the mesh template, since it always crashes after integrating the same mesh the third time. Without fail. No regard for integration order, no regard for whether stuff is docked or attached or whatever. I integrate the same mesh a third time, my code takes a wrong turn and finds itself in an unrelated function (i.e. access violation that happens to hit somewhere in my own memory, so it doesn't get registered as one, it just gets majorly confused about where it's supposed to be...)

 

[Dantassii]

You may also want to look for memory leaks. Whenever I fire up Orbiter in 1 scenario and then go back to the start screen and try to start up a 2nd scenario (after ending the first) Orbiter ALWAYS crashes. This only happens with IMS scenarios and happened back when I was using the D3D9 client and continued when I downgraded to the build in D3D7 client. The error stack was VERY cryptic (Thank you Microsoft!) but from what I could distill, it looked like some array was getting memory allocated and not being reset after a scenario closed and when the new scenario was opened, it couldn't handle the array size that the last scenario had created.

On a different note, I'm up to mission 60 now on my station.

 

[goaowonk]

Whenever I fire up Orbiter in 1 scenario and then go back to the start screen and try to start up a 2nd scenario (after ending the first) Orbiter ALWAYS crashes. This only happens with IMS scenarios

+1

I tought it was me and my laziness for deleting broken addons.

 

[jedidia]

You may also want to look for memory leaks. Whenever I fire up Orbiter in 1 scenario and then go back to the start screen and try to start up a 2nd scenario (after ending the first) Orbiter ALWAYS crashes.

I'm aware of that. What I'm not aware of is when it crept in. I don't remember this behavior from RC2...

EDIT: Ran instrumentation, no memory leaks. But a crapload of first-chance exceptions in orbiter. I don't know if orbiter uses them for messaging though, so I have no Idea if they're caused by IMS. Otherwise, everything looks quite nice, except that a thread in D3D9 client doesn't exit properly.

I decided to leave it be. I'll be hunting bugs in this until kingdom come. I'm officially starting the rewrite. Sorry, no client compatibility for this version. I just can't foresee how deep this will lead, and I don't want to spend too much time on it. I accepted long ago that this code is hopelessly convoluted and well beyond its architecture. I need to start this over now, or I'll just get lost in this mess again.

 

[Dantassii]

It may also be just the FRIGGING HUGE IMS station I'm building that's causing it. I don't recall it ever happening early in my construction, but since I went over about 100 IMS modules it always has happened.

BTW, this isn't a complaint. This is just me trying to give you more ammo to shoot at the code to get it working the way you want it to work, which I'm all for.

 

[jedidia]

This code will never work the way I want, because it's essentially a C-structure. It's not modular at all, and everything is somehow involved with everything.

I gave it another shot and tried getting a fresh meshhandle everytime I need one instead of storing them and reusing them (just in case that some mesh templates change memory location for some very weird reason), but the problem is still the same. Orbiter has a heap overflow on calling addmesh after a few times. I don't see much chance of finding out what the problem is on my side without significant effort, which I'd rather invest in laying the foundations of the new architecture.

 

[Dantassii]

Sounds like a plan to me jedidia. At this point, I wouldn't worry about making the R2.* release D3D9 compatible. I agree with you that it just sounds like too much effort for an architecture that you currently plan on re-writing anyway. I've always found when coding something that I've never done before that my 2nd attempt (or 3rd attempt, or 7th attempt!) is usually a much cleaner, easier to use, and overall much better architecture than my first (or usually 2nd) attempt. I figure out how NOT to do it my first time, and learn from my mistakes. I'm really big on learning from my mistakes when I'm writing computer code. I may make a lot of mistakes early on, but I rarely make the same mistake twice, at least in the same language. I may make the same mistake twice when I change languages though.

On a side note, what compiler do you folks use for your C++ code for Orbiter? The only one I've ever used (Recently) is Visual Studio, but the cost of that is prohibitively expensive for the amount of C++ coding I want to do at home. The last C++ compiler I bought for my computer was Borland C++ for Windows 3.1.......

 

[jedidia]

I've always found when coding something that I've never done before that my 2nd attempt (or 3rd attempt, or 7th attempt!) is usually a much cleaner, easier to use, and overall much better architecture than my first

Trouble is, the current architecture isn't even mine, I inherited it from vchamp, and was written for Orbiter 2006. That's ok because without him this would never have taken flight anyways, but I recognised pretty early that this would get rather messy if too much features are added, but continued anyways...

On a side note, what compiler do you folks use for your C++ code for Orbiter? The only one I've ever used (Recently) is Visual Studio, but the cost of that is prohibitively expensive for the amount of C++ coding I want to do at home. The last C++ compiler I bought for my computer was Borland C++ for Windows 3.1.......

Practically everyone here uses an iteration of VisualStudio express, the free variant of visual studio.

 

[Dantassii]

Ok. When I get the urge to write code at home again, I'll see about downloading VS express. Hopefully it's not too different from the VS 2010 that I use at work.

'course if this whole thing was written in Java, I could use JDeveloper.. that's free...

 

[jedidia]

'course if this whole thing was written in Java, I could use JDeveloper..

'course if this whole thing was written in Java, it'd be awfully slow :lol:

Anyways, I'm using this for an official announcement: Coding on the current IMS version is terminated. There will be no client support, because it's way too unstable. I made it work enough to be sure that it'll work in the next version, but I won't touch the current code anymore. Official last version is RC 2.3. I won't hinder anyone who wants to extend it, the source code is posted in the IMS social group. But I won't have an active part in it.

IMS 2, a complete rewrite of the whole concept, has officially been started and the first few lines written. I don't know how long it's going to take, and I won't make any estimates. Anyone interested can keep track in the IMS social group, in the new thread I created. Everyone can go there to read, but only members can post. I am not planing on taking in more members at this point. As soon as I have something worthy of testing, I might.

There will be another release of this version, with revised config files and maybe even proper documentation, if PeterRoss and BruceJohnJennerLawsonHisNameIsWayTooLong are willing to finish it.

 

[Michael_Chr]

In the meantime....



Above pictures is my attempt to create an IMS ship. Its designed to haul stuff to a lunar base – hence the long struts between the habitation section in the front and the engineering end in the back where the solarpanels are. The Idea is that you can latch cargo/habitation modules in between the struts (using Kulchs Ucargo deck). It has several permanent dockingports to carry the necessary number of lunar landers (4-6) while also having two docking ports on each side for an XR5 to dock right above the Airdocks. Another design feature is an upper and lower keel that holds the radiators and at the same time allowing for a track for a RMS (Again Kulch whith the URMS). It has 5 HPE engine with 4 large fuel tanks giving it a very decent acc. rate of 3.4Gs and a Dv capability of 19Km/s. It might be overpowered but these figures also reflects an unloaded (no cargo) state. It can hold a complement of 42 persons according to (which I think it’s a bit overcrowded for the size). Strict adherence to balancing (its totally mirrored in X and Y) ensures that no pitch or yaw rate is induced while using the main thrusters. I have 12 RCS modules (4kN) (4 front and back and 4 in the middle with lager displacement for roll. Its quite slow but manageable in rotation and translation which gives it a nice lumbering feel (probably quite realistic). I might upgrade it with an additional pack of thrusters once I test it at full load condition. Lessons learned so far: If you adjust the orientation of docking ports in the config files make sure you also adjust the corresponding attachment port lest you will not be able to attach the module in the IMS menu. Also you can verify the CG position in the config file . X and Y axis has to be very close to zero (mine reads: MASSCENTER 0.000961 0.000000 -101.103508) – assuming your maindrives operate in the z-axis. I might not have enough cooling modules (currently I have 6) once I leave LEO so an upgrade here might also come into question. The indication is that I get a MCS overflow during solar radiation periods. It also holds 8 forward firing side mounted thrusters (connected to retro channel) making final docking preparation a bit easier – but again…these thrusters might need some config tweaking since the acc. is only a meager 0.098Gs. I’m also constantly getting “temp. critical” for these thrusters (Occurs after about 5 secs of burning) so I’m investigating into that also. Finally understanding what a permanent docking port does also proved to be vital – ensuring that you end up with the desired docking ports after finalization. I have really enjoyed working with IMS – and it almost seems that my system is getting “the hang of it” (quite few CTDs here at completion compared to a lot in the beginning).

One thing I havn’t figured our yet is the apparent displacement of the RCS firings (see above pic). I cant figure that one out – It only appears after finalization and only in a spawned instance (and under inline DX7 ver – off course). But I can live with that. I do hope that Jedidia can get a handle on the DX9 issue – but if not I will still use it under DX7 – hands down this is one of the most rewarding and enjoyable addons. It will give you some headscratches which makes the rewards much better 
Best regards
Michael
Ps. Next thing is to develop a customized space station – It will include two bays or docks for these units as well as Greg Burch Air/dry docks. LEO only capable off course :-D

 

[jedidia]

Nice design there, Micheal. Unfortunately I have to inform you that neither of Kulchs addons are compatible with IMS... they simply work in a way that makes interfaceing with them difficult in a vessel that constantly changes its attachment points.

One thing I havn’t figured our yet is the apparent displacement of the RCS firings (see above pic). I cant figure that one out – It only appears after finalization and only in a spawned instance

Another finalisation bug... sigh. I thought We had them all. I'll see if I can find the culprit.

 

[Interceptor]

@Michael Chr,That's a great looking IMS station,any plans to release your design for download?:thumbup:

 

[Michael_Chr]

Unfortunately I have to inform you that neither of Kulchs addons are compatible with IMS... they simply work in a way that makes interfaceing with them difficult in a vessel that constantly changes its attachment points.

I think I can figure a work-around out - at least I have an idea ...And I do understand the attachment point challenge.

Another finalisation bug... sigh. I thought We had them all. I'll see if I can find the culprit.

The funny thing was that it didnt happen on the first few finalizations I made. I can provide you the files if you are interested. But on the other hand. It is only a presentation problem. It doesnt affect controllability of the ship. So that can definatly be put way down the priority list

Finally...I concur with you statement of a total rewrite of the code. What works best for you in the long run works best for all off us.

I will definatly keep an eye out in the IMS social group on the progress on the next IMS version.

---------- Post added at 09:11 PM ---------- Previous post was at 07:29 PM ----------

@Michael Chr,That's a great looking IMS station,any plans to release your design for download?:thumbup:

I'm not sure I can put it up that easily. I have modified some of the config files for some of the modules and Im sot sure I have the rights to redistribute these. But if the team working with IMS are OK with that I can put together a package. The mods are mostly associated with reorienting docking and attachmentports as well of thrust modification (to thrusters of course...).

I the meantime I'm fiddling with the RCS to give it some more beef there and adding some more cooling modules at the expense of some other modules. Finally I really need to test the rig more rigorously - so I know it can deliver according to specs.

Best regards
Michael

 

[jedidia]

Im sot sure I have the rights to redistribute these.

Don't worry about it. We stole half the content of those files from Greg, the other half from the SSBB-XR5 payload configs, and wrote another half ourselves. Wait... something isn't right with my math here...

Anyways, config files are usually considered fair game to freely distribute and edit in the Orbiter community.

 

[NukeET]

Nice design there, Micheal. Unfortunately I have to inform you that neither of Kulchs addons are compatible with IMS... they simply work in a way that makes interfaceing with them difficult in a vessel that constantly changes its attachment points.



Another finalisation bug... sigh. I thought We had them all. I'll see if I can find the culprit.

I've completed a redesign of a lunar orbit station with 2 Universal RMS arms (by Kulch), and haven't seen any problems with them yet. ????

 

[jedidia]

As long as you don't attach it to the IMS vessel, no. If you attach it to the IMS vessel, it'll be floating freely after SQL.