New Release Interplanetary Modular Spacecraft RC9

[BruceJohnJennerLawso]

Uh hu... didn't think of that. Will have to think this through a bit.



Ok, now I see what you did there... I think putting that shift directly in this function wouldn't be quite the right place. very confusing. But I'll have to think this whole think through to see why the discreppancy happens in the first place...

Ok... so...

I havent been following any of the code discussion so far, as I wasnt sure whether having another developer & another set of source flying around would be the best idea. I can start setting up my copy of IMS source if you want me to, but my feeling is that it would be best to let you two hash things out while I work on other stuff.

Im currently working on the IMS documentation, almost done editing my paper copy of the quickstart guide, design for dummies, & config guide are next. I might be done before the end of today, but transferring it to a PDF format might take a while longer.

I noticed that you seem to contradict yourself in the IMS quickstart guide, you first say that the thrust MFC is the only one in, then you describe more in the next post. Ill make sure to fix that for the first rough copy.

Whats really stumping me is the matter of coming up with a logo for IMS. I think it should reflect the building & engineering side of IMS strongly, but its hard to create something representative of that when every single IMS ship is different.

I think Ill message Loru to see what he thinks, but if all else fails we must

 

[jedidia]

I noticed that you seem to contradict yourself in the IMS quickstart guide, you first say that the thrust MFC is the only one in

Yeah, there's bound to be lots of outdated information in the quickstart guide... :shifty:

 

[PeterRoss]

The catapulting (vertical velocity = 17m/s) happens because of the touchdown shift before the first frame. I have SetTouchdownPoints in clbkLoadStateEx and another one in SetCenterOfGravity when it's being called from PreStep of the first frame. Commenting out the latter (or tdXXX -= NewCOG strings instead) saves us from catapulting (0.02 m/s). Commenting out the one from LoadState results in initial vertical speed increasing drastically (112m/s).

Touchdown points' shift happens in SetCenterOfGravity every frame, but only the first one catapult us. It's a start at least.

---------- Post added at 09:26 ---------- Previous post was at 09:11 ----------

By the way, I've translated the rocket part of Spacecraft Design For Dummies into Russian. Now you can tell anyone that you have your works translated into foreign languages :lol: Not to mention the guide itself was originally written in English at the first place...

---------- Post added at 13:46 ---------- Previous post was at 09:26 ----------

To think of it, touchdown points are being shifted just a bit per every frame, but at the very first frame the shift is of a size of CG shift - here's the source of the problem. I think it can be solved by saving dynamic value of touchdown points (that's what you advised to do) instead of default values.

 

[jedidia]

that's what you advised to do

Actually I advised against it, because it gets difficult to keep track of their absolute positions, which can lead to touchdown points ending up anywhere, but if it helps solve the problem...

One thing crossed my mind: Is our current main problem actually really related to touchdown points? What happens when you park (not dock) a vessel close to, say, the ISS and then do an SQL? does its position change too? if yes, our problem is not the touchdown points. I even remember having it, and I'm not sure if I really fixed it :shifty:

 

[PeterRoss]

Actually I advised against it...

Oh, indeed you did
Anyway, I made saved TPs dynamic, some other fixes too, it looked great at first but then I found that if you change your vessel's CG when landed (by changing fuel amount via ScenEd, for example) and SQL - its TPs ends up screwed. Dynamic stuff is do dynamic. I guess I'll fix it too, but the touchdown points' part of the code becomes more and more complicated. Much more complicated than I expected before getting my hands dirty.

One thing crossed my mind: Is our current main problem actually really related to touchdown points? What happens when you park (not dock) a vessel close to, say, the ISS and then do an SQL? does its position change too? if yes, our problem is not the touchdown points. I even remember having it, and I'm not sure if I really fixed it :shifty:

:dry: You fixed it alright. But now it contradicts with my ShiftCG/ShiftMesh invention which works against your solution and actually shift my vessel when orbiting against a reference vessel. What the...?

One more question - there is MASSCENTER string in scenario file which always saves three zeroes because massCenter is being nullified right before saving. MassCenter is being used in CreateRCSGroups only, if I get it right. Why nullify it? I could use it if it's not nullified.

 

[jedidia]

One more question - there is MASSCENTER string in scenario file which always saves three zeroes because massCenter is being nullified right before saving. MassCenter is being used in CreateRCSGroups only, if I get it right. Why nullify it? I could use it if it's not nullified.

That is actually a remnant from where the IMS CoG was semi-dynamic. the center of gravity was saved to scenario. Now IMS is able to calculate the CG position from scratch, so I don't think the center of gravity string does anything before CoG initialisation anymore. I'm not sure of what it still does at all, really.

Now, what I still don't see clearly is what actually happens. Does the global position of the vessel change? because then shifting the meshes around is somewhat of a questionable solution... the CoG would still be in the wrong place, and the meshes dissasociate with the actual position of the CG. Thinking about it, shifting the meshes really shouldn't be used as a solution, unless the touchdown points lead to shifted meshes.
For example, have you ever tried firing the thrusters after shifting only the meshes? technically, they should light up in all the wrong places.

What we need to find out is what the change in position is actually related to. Is it caused by shifting touchdown points around? or is it caused by shifting the CoG when in landed state? As an experiment, you could disable all your touchdown point shifting (or just take the RC2 dll) and see what happens there if you save a scenario in landed state.

but the touchdown points' part of the code becomes more and more complicated. Much more complicated than I expected before getting my hands dirty.

Yes, things have that tendency. Complexity in coding is not a linear thing, it squares. That means that the more complex the code is, the more complex it will be to add any new feature... especially with the core architecture of IMS, which has already been outgrown in some ways.

 

[PeterRoss]

Let me explain the logic behind ShiftMeshes/ShiftCG thing.

When spawned, vessel use coordinates taken from scenario file to place its CM, then it has COG shift calculated, but instead of shifting CG it actually shifts meshes AND all the docking ports and attachment points and thrusters too in the direction opposite to calculated CG shift. All of this happens just one time before the first frame only. Its CG remains intact. It results in a vessel being spawned in a way its CG appears in the same coordinates it was situated when the scenario was saved. It even removes that funny camera pass from CM to new vessel's CG at simulation start. Every other time CG is being calculated it goes in standard way. No problem with any docking ports or thrusters never been detected with ShiftMeshes/ShiftCG method. Never checked attacment points yet, but I have reasons to believe they're fine too. Have to check it to be sure of course.

Now what we have:
1) RC2 works fine in space - when undocking and SQL your vessel appears right where it should be. There are some small shifts, but it can be wrong camera angle as well - any way they're too small to worry about. It behaves bad when landed - I'm getting a big shift relative to reference object, and with every SQL it becomes worse.
2) My build works almost as well as it should when landed: no shifts, dynamic touchdown points, no catapults. It has at least one bug described before, but I believe it's nothing I can't solve. But it's being shifted relative to reference object when in space after SQL. And I'm going to find why.

 

[jedidia]

I'm getting a big shift relative to reference object, and with every SQL it becomes worse.

Is that a shift of the CG relative to adjacent objects, or is it only the visual position of the meshes? (I.E. CG is in the same place globaly, but not in the same place in the vessel?)

instead of shifting CG it actually shifts meshes AND all the docking ports and attachment points and thrusters too in the direction opposite to calculated CG shift.

What I don't get about this, this should happen already... unless ShiftCG produces some very unorthodox side effects when used in landed state. Oh, well. Can't wrap my head around it currently. As long as the CG after loading is in the same spot as before saving, and the vessel appears in the right position, and all thrusters and points are where they should be, it's all well.

You fixed it alright. But now it contradicts with my ShiftCG/ShiftMesh invention which works against your solution and actually shift my vessel when orbiting against a reference vessel. What the...?

Only do it when the vessel is landed, then? It really seems that our major problem here is weird behaviour of ShiftCG when in landed state, although I can't quite put a finger on what's wrong. From where I'm sitting, it almost seems as if ShiftCG doesn't call ShiftMeshes when the vessel is in landed state. Would need some bare-bones code reproduction to confirm, though.

 

[PeterRoss]

I came to the same conclusion that something's wrong with ShiftCG when landed. You actually dropping CG to SM coordinates at the very beginning of SetCenterOfGravity() with this string:

	ShiftCG(centerOfGravity * -1);

Somehow it's not working as intended when landed, and my method was aimed at solving landed state problems. Maybe I should just limit my method to landed state... Or maybe I should try to find what the hell is going wrong with ShiftCG when landed.

 

[jedidia]

Might be an Orbiter bug (heaven knows I stumbled over quite a few of these during development. IMS needs to do all the crazy stuff with the API that no other add-on ever used, and the context of application was completely untested). Best thing in those cases, grab the shuttle PB source code and reproduce the problem with it. In this case, shift CG, see what happens, analyse a bit and file a report...

 

[BruceJohnJennerLawso]

Might be an Orbiter bug (heaven knows I stumbled over quite a few of these during development. IMS needs to do all the crazy stuff with the API that no other add-on ever used, and the context of application was completely untested). Best thing in those cases, grab the shuttle PB source code and reproduce the problem with it. In this case, shift CG, see what happens, analyse a bit and file a report...

Yeah, the API seems awfully big when you first dive into it. A few add-ons later you start thinking of it as more confined.

I finally came up with my first try at an IMS logo today.



Whadya think?

 

[PeterRoss]

The idea is not bad, but it's inconvenient in terms of scaling. I would advise less small details. The good logo's details should be distinguishable even when it's scaled down. For example, your logo makes no sense when scaled down as it appears in your post (without opening it in another window).

 

[jedidia]

I finally came up with my first try at an IMS logo today.

looks nice, but way too detailes for a logo. You'd have to stylize that somewhat more.

 

[PeterRoss]

Not good, not good. I have mutilated SetCenterOfGravity() function to the point where it does ALMOST what I wanted it to: i.e. no camera pass at startup, no any shifts in space or at landed state at startup, touchdown points are adequate to CG, thrusters and AP/docks are stable in the most of situations.
I was almost there. And then I discovered that the vessel's position is screwed up if SQL when docked :facepalm:
I'm not going to post my current SetCenterOfGravity() here. I'm actually ashamed of what it has become. I think I'll try it another way.

 

[jedidia]

I'm actually ashamed of what it has become.

Ah yes, we all know the feeling when after expanding and expanding a function you start thinking "what am I actually doing? no, really, what AM I doing? I have no Idea anymore..."

 

[BruceJohnJennerLawso]

looks nice, but way too detailes for a logo. You'd have to stylize that somewhat more.

Not a problem, but I need to know what direction I should take it.

Recently working on a few new IMS configs, got Andy44s fuel tanks working, recovered & fixed the config for Cupola V2 that somebody posted, & I also got the Command module from MIPTS working. The MIPTS CM is perfect for our purposes, & this way we dont have to see the creepy man in the interior either :lol:

Will post those with some other work Ive done in a little bit. Im thinking about ripping apart the Arrow freighter too...

 

[jedidia]

Not a problem, but I need to know what direction I should take it.

Basic Guideline for Logo-design: Every detail should be recognisable in monochrome. Colors are important, but the basic structure of the Logo has to be simple enough that two will convey the Logo if needs be. When adding color, using more than four can be considered excessive.

To go of your suggestion, something like two docked modules (stylized) floating above a radius might work, but I don't see where you'll fit in any letters. Then again, lots of logos don't have letters.

 

[BruceJohnJennerLawso]

Basic Guideline for Logo-design: Every detail should be recognisable in monochrome. Colors are important, but the basic structure of the Logo has to be simple enough that two will convey the Logo if needs be. When adding color, using more than four can be considered excessive.

To go of your suggestion, something like two docked modules (stylized) floating above a radius might work, but I don't see where you'll fit in any letters. Then again, lots of logos don't have letters.

Hmmm, Im gonna have to think on that, just not sure what direction to take in order to do that. :hmm:

I wanted to touch base on an idea Ive had for a while that would be good to test. If an add-on developer wanted to allow his/her spacecraft to fly itself to the construction location, then become an IMS part, would that be possible?

What Im suggesting would be:

Shuttle-D (for example) flies to shipyard with IMS parts, rendezvouses, maybe docks with the rest. Then the user presses a special button that deletes the Shuttle-D vessel, & spawns the CM, engine, fuel tanks, & truss as IMS parts. User focus is then shifted to the new CM part, which proceeds to assemble a new IMS ship.

Would that work, or is there an issue with doing that in Orbiter?

 

[jedidia]

If an add-on developer wanted to allow his/her spacecraft to fly itself to the construction location, then become an IMS part, would that be possible?

any vessel can be a module if it's got the right lines in the config. IMS doesn't care what a vessel was before, it simply looks into the config, takes the properties from there and rips out the meshes. No problem at all.

However, this unfortunately does not apply to CMs!

A CM isn't a module. a CM is the vessel, and you cannot run a vessel on two dlls.

What you suggest is however easy to implement in the basics, since you have the source code for said vessel: The special button that spawns the modules and deletes the original shuttle-D (in that order, the other way around doesn't work because you can't execute code of an already deleted vessel) has to be part of the Shuttle-D dll and can be completely independant from IMS.
For the Shuttle-D to rebuild itself automatically from the modules, you'd need to put public calls into IMS that allow external code to trigger integration, of course, similar to what IMS does to initiate transfers among its vessels. Not too difficult, really.

 

[PeterRoss]

Here's the latest IMS with touchdown points support:

http://ge.tt/1UYh6Jc/v/1?c

This version is incompatible with any vessels made under previous versions of IMS including IMS RC2!!!

How to use it:
You have to create an IMS vessel of any configuration you want. You can add these landing legs if you want it to look nice:

http://ge.tt/6Cih5Jc/v/0?c

Then you have to save your scenario and manually edit this string which will be right after MODULES strings:

  TDPOINT 0,0,0 0,0,0 0,0,0

I strongly NOT recommend you to leave it this way. Just change it into something like this:

  TDPOINT 0,[COLOR="Red"]-2.95[/COLOR],10 -3,[COLOR="Red"]-2.95[/COLOR],-5 3,[COLOR="Red"]-2.95[/COLOR],-5

These are touchdown points' vectors for airplane-like vessel which has the distance between its empty COG and land equal to 2.95 m (marked by red). Feel free to modify these vectors to fit to your vessel.

Then test it.

It should behave like any other vessel when landed and when in space: no shifts during simulation or right after starting a scenario, no stray docking ports or thrusters, no catapults. There should be no camera pass from vessel's command module to its COG at the simulation startup which was IMS distinctive feature in previous versions - I'm sorry if you liked it :lol:
I made some tests and found no bugs - but I believe you guys can find some.