PeterRoss
Our friendly neighborhood Putinist
Interesting. I'll have to check it out more thoroughly, maybe I was wrong with conclusions.
New Release Interplanetary Modular Spacecraft RC9
- Thread starter jedidia
- Start date
BruceJohnJennerLawso
Dread Lord of the Idiots
- Joined
- Apr 14, 2012
- Messages
- 2,585
- Reaction score
- 0
- Points
- 36
I'm not a hero, I'm just a warranty man, remember?
No, Im sorry you're my hero. You clearly have a secret identity and wear a cape :lol:
I should look up that show. Maybe its on youtube or something...
Yes, but integration and CG/Finalization are probably intertwined too as well. All I know is that RC2.3 hasnt given me a single issue yet, while 2.0 was misplacing parts all over the place.
Modules on the picture are little older than the version I uploaded so some of them should look different abit.
Perfect! Do the modules attach radially to a "Ghost framework", or do they attach linearly? (Ie building them one by one along the long axis of the shipyard)
What a strange bug, you would think that RCS wouldn't be doing this to us unless it was directly edited in some way. Maybe the changes you made to add the touchdown point feature could be a cause somewhere?
Anyways, Im gonna get those 2.3 sources that you posted in the group earlier, and get things set up. If I could bug you Jedidia, I would like to try and understand the core IMS framework at the most basic level. If I wanted to create a vessel that can integrate other vessels into itself, ignoring everything else. For example, how does IMS:
A-attach modules that are within the 1 meter distance
B-Integrate them. How does IMS get the vessel handle in order to order its deletion
Ive been hard at work on the IMS user guide, almost done, when I finish, Im gonna post it for inspection. I need some feedback on a few things, particularly boosters. I cant figure out how to use them.
Okay here it is
View attachment IMS User Guide v0.1.zip
Last edited:
jedidia
shoemaker without legs
Brute force: It iterates through all attachment points of all vessels in the scenario, looking for the closest compatible attachment point that is closer than one meter to one of the attachment points of the IMS vessel.
The list with attached modules keeps track of the occupied attachment points. When you select a module on the list and click integrate, IMS gets the handle of the vessel attached to this attachment point.
Thanks, I'll take a look at it.
---------- Post added at 07:44 AM ---------- Previous post was at 06:35 AM ----------
Page 1, second paragraph: spaces in the main vessel name will not cause IMS to crash. It will lead to issues when trying to transfer crew with UMMU.
Page 3, second paragraph: ...lose track of what you're doing
Also, IMFD can actually navigate backwards, but that's just a detail...
Page 3, last paragraph: "Once you've succesfully accomplished this..." There's been a lengthy explanation of construction vs. permanent docking ports in between, people will no longer know what exactly they were supposed to accomplish without looking up the beginning of the page. Change to something like "...once you succesfully docked your module".
Page 4, first paragraph: Actually, the module keeps its temperature because of the transport seal, for user convienience. Best to not explain things with batteries, People will come asking where on earth the batteries are...
Page 6, paragraph 1: Might lead to confusion, as dumb modules like trusses are not shown on the systems panel.
Page 8, Paragraph 2: Does not explain what the framed radiator icon actually means. It means that the module currently selected in the list is connected to this radiator.
Page 8, last paragraph: MCS actually means "main cooling system", so a) talking about an MCS system is a bit department of redundancy department-ish, and also, there can be only one of them. The whole paragraph talks about the MCS without actually explaining what it means. Also, its job is not to dispose heat through radiators. Its Job is to move heat around, plain and simple... preferably to radiators of course, but it is not the MCS' fault if they aren't there, or unable to finish the job.
Page 9, first paragraph: "Cooling modules" are actually life support modules with cooling capacity... though as I see, many of them are called cooling modules in the filename.
Also, "a few hundred kilowatts" is quite a large MCS. For quite a large vessel. I wouldn't put it so generally, write something like "the necessary capacity of your MCS depends on how many and which modules you build into your vessel."
Also, the paragraph doesn't explain where the capacity and load of the MCS is displayed.
Paragraph 2: Some modules have accumulated excess heat, for whatever reason. Also, the last sentence in the paragraph is so unconnected that it is difficult to understand what it refers to.
Paragraph 3: You might get away with it, not probably. Depending on your vessel, the heat tranfered from the outside to the inside can be negligible compared to what you're producing internally.
Paragraph four usually only applies to modules that don't consume power, or very little of it.
Paragraph five: You can pretty much always keep them plugged in. If they don't need it, they won't consume any power, and if they need it, they need it. The only reason to shut it down is power shortage, when you have to decide which are important and which not.
More later. I like the style so far, although the structuring is a bit awkward. Keeping topics more separate might be a good Idea... I know I haven't exactly been a prime example in that respect, but the user guide grew pretty much with the feature list.
PeterRoss
Our friendly neighborhood Putinist
You mean like this one?:lol:
One by one along any dimension you wish - each panel has four ports, sideward ones are sloped to the angle necessary to make the cylindrical construction.
jedidia
shoemaker without legs
Page 10, paragraph one: I tried to explain that problem in some detail because people usually reported it as a bug. These things should be in there:
a) solar panels are their own radiators, and are designed to work as good as possible at their equilibrium temperature - which of course depends on distance from the sun. This is partially in your text, but the formulation is misunderstandable: They will always radiate as much heat as they get, otherwise they'd heat up indefinitely. But the temparature at which this happens might not be desirable.
b) solar panels don't produce power in shadow, hence it is no problem if they go out of operation when they are not heated by the sun. They are very flimsy and will therefore accumulate or lose heat incredibly fast when the environment changes.
c) heating a solar panel in shadow basically means heating a radiator. It will quickly overload any power generator you carry on board if you try to keep them warm. Which is nonsense, because usualy you have solar panels as your primary means of power production.
Page 10 Paragraph two: "..can be selected from the four..." The four what, exactly?
Page 10 paragraph 3: CPO and CPC mean "current power output" and "current power consumption". If you describe accronyms it's usually a good Idea to write what exactly they mean, especially if they're made up accronyms that aren't previously familiar.
same paragraph: "generators ... will throttle their output", not consumption.
Page 12, first paragraph: Provided you got some thrusters, rcs and suitable propellant...
Page 13, first paragraph: Again with the accronyms... MFC is short for multi-function control. Also, you forget to mention the root menu.
Page 14, first paragraph: Mass flow rate is in kg/s, not km/s.
I'm also not sure if this is the right place of a lengthy description of what dV is, most people should be familiar enough with it to know what the display tells them, and the detailed explanation will be in the design guide.
Page 15 first paragraph: Who on earth told you this approximation? It's completely bogus. Two thrusters do not have more delta-V than one. You are assuming that every thruster carries different propellant, in which case it might just work, but if you have two thrusters with different ISP running of the same tank, calculating the dV becomes hell on earth, which is exactly why IMS doesn't do it. But adding the dV of the thrusters together will result in something completely wrong, because to reach that dV would mean to burn your propellant twice.
Page 15 paragraph two: If your engines overheat from sun influx, you're aboard the Ikarus. Your crew will be long dead before this happens.
scratch the remark about APU. APU means "auxilary power unit", and it's not how a rocket warms up. A rocket warms up by burning small amounts of propellant while bypassing its cooling loop, pretty simple. If you'd ever turn up the thrust without passing the heat of the engine on to the inflowing propellant, it would be slack in seconds, so it's really not difficult to warm it up just a bit that way.
Also, a blinking H indicates that the engines are being heated, if I remember correctly. A glowing H would mean they're too hot, but I notice I'm not sure anymore...
Page 15 last paragraph: redundant, ah? :lol: LH and AH are stock orbiter autopilots just as the rest, and mean Level Horizon and Altitude Hold. They're present in every DG and XR vessel, really.
Page 16, last paragraph: It must not be another IMS vessel. It can be an IMS module with storage, or even a completely other vessel if it has the right lines in its config file. Oh, I see you mention that later on. Never mind then, but you should add that you can just take a full IMS storage module up to refill a vessel.
Page 17, first paragraph: The string will look odd if there's no crew aboard (some division by zero I guess, I never fixed that, did I?), regenerative capabilities have nothing to do with it as this display only considers what's currently in store.
a) solar panels are their own radiators, and are designed to work as good as possible at their equilibrium temperature - which of course depends on distance from the sun. This is partially in your text, but the formulation is misunderstandable: They will always radiate as much heat as they get, otherwise they'd heat up indefinitely. But the temparature at which this happens might not be desirable.
b) solar panels don't produce power in shadow, hence it is no problem if they go out of operation when they are not heated by the sun. They are very flimsy and will therefore accumulate or lose heat incredibly fast when the environment changes.
c) heating a solar panel in shadow basically means heating a radiator. It will quickly overload any power generator you carry on board if you try to keep them warm. Which is nonsense, because usualy you have solar panels as your primary means of power production.
Page 10 Paragraph two: "..can be selected from the four..." The four what, exactly?
Page 10 paragraph 3: CPO and CPC mean "current power output" and "current power consumption". If you describe accronyms it's usually a good Idea to write what exactly they mean, especially if they're made up accronyms that aren't previously familiar.
same paragraph: "generators ... will throttle their output", not consumption.
Page 12, first paragraph: Provided you got some thrusters, rcs and suitable propellant...
Page 13, first paragraph: Again with the accronyms... MFC is short for multi-function control. Also, you forget to mention the root menu.
Page 14, first paragraph: Mass flow rate is in kg/s, not km/s.
I'm also not sure if this is the right place of a lengthy description of what dV is, most people should be familiar enough with it to know what the display tells them, and the detailed explanation will be in the design guide.
Page 15 first paragraph: Who on earth told you this approximation? It's completely bogus. Two thrusters do not have more delta-V than one. You are assuming that every thruster carries different propellant, in which case it might just work, but if you have two thrusters with different ISP running of the same tank, calculating the dV becomes hell on earth, which is exactly why IMS doesn't do it. But adding the dV of the thrusters together will result in something completely wrong, because to reach that dV would mean to burn your propellant twice.
Page 15 paragraph two: If your engines overheat from sun influx, you're aboard the Ikarus. Your crew will be long dead before this happens.
scratch the remark about APU. APU means "auxilary power unit", and it's not how a rocket warms up. A rocket warms up by burning small amounts of propellant while bypassing its cooling loop, pretty simple. If you'd ever turn up the thrust without passing the heat of the engine on to the inflowing propellant, it would be slack in seconds, so it's really not difficult to warm it up just a bit that way.
Also, a blinking H indicates that the engines are being heated, if I remember correctly. A glowing H would mean they're too hot, but I notice I'm not sure anymore...
Page 15 last paragraph: redundant, ah? :lol: LH and AH are stock orbiter autopilots just as the rest, and mean Level Horizon and Altitude Hold. They're present in every DG and XR vessel, really.
Page 16, last paragraph: It must not be another IMS vessel. It can be an IMS module with storage, or even a completely other vessel if it has the right lines in its config file. Oh, I see you mention that later on. Never mind then, but you should add that you can just take a full IMS storage module up to refill a vessel.
Page 17, first paragraph: The string will look odd if there's no crew aboard (some division by zero I guess, I never fixed that, did I?), regenerative capabilities have nothing to do with it as this display only considers what's currently in store.
Last edited:
BruceJohnJennerLawso
Dread Lord of the Idiots
- Joined
- Apr 14, 2012
- Messages
- 2,585
- Reaction score
- 0
- Points
- 36
Okay... and how does that iteration happen? How does the vessel scan for attachment points? Im also not sure how it differentiates the points in terms of exact distance.
Dumb question, but what happens if theres a tie?
And that would probably be done through something like, getattachmenthandle by index right? I also need to find the exact method for deleting a vessel, although Ive probably seen it before.
The reason Im doing this is so that we can isolate how to create a modular vessel, and release the source for future use. IMS is never going to be the one shot solution for every Orbiter vessel, so having the basic method of creating modular vessels available in a clear format would be really useful for development. Just think of modular rocket construction, space station construction, rover construction...
Thanks, I'll take a look at it.
Page 1, second paragraph: spaces in the main vessel name will not cause IMS to crash. It will lead to issues when trying to transfer crew with UMMU.
Page 3, second paragraph: ...lose track of what you're doing
Also, IMFD can actually navigate backwards, but that's just a detail...
Ah, true, Ill list that as a low priority fix. Its really not that important anyways, as it would be better to get users into the habit of using underscores in vessel names all the time, but thats just me.
Thanks for the grammar fix, I'm not a great typer, so high speed writing produces a lot of mistakes. will fix.
Wow, theres thorough, and then there's that. I use TransX anyways though...
You lost me there. I think the description of what to do is mostly on the next page. Page 3 is mostly just the description of the transport seal, and what it does.
Actually, I think you're wrong there. I just happened to notice that when I unsealed the CM for the first time, the heating automatically pops on for a split second, as you can see in the screenshot. Is it possible that the command module starts at somewhere below 298 K each time it gets unsealed?
If you dont believe me, just try running a similar scenario, and watch the panel closely right after you unseal. I never even noticed it until I did it for the demo.
:lol: I didnt know we measured parts based on their intelligence. Ill try to figure out how to rephrase that. Of course, those parts could have small consumable reserves or batteries stuffed into them so they did...
Yep, got ahead of myself there.
Well yes...
Ill have to double check how that part came off then. Maybe a better way to phrase it would be that the MCS ensures that heat moves to the radiators as quickly as possible? Its like holding a bucket of water with a leak in it. If the leak has a bunch of debris clogging it up, it wont drain water as quickly.
So the difference is...
I assume that cooling modules are technically different from vanilla life support because they don't provide any specific use in keeping people alive. An unmanned vessel would need cooling too. :shrug:
Well, I still kinda like the comparative example for MCS capacities. I think the couple hundred kilowatts example would be a reasonable estimate for a typical users first IMS ship. Nobody goes small and efficient the first time
Thanks. will fix that.
Welll, I really just based that on what you said in the original copy of the documentation. If I had to make a guess, I think that spacecraft thermodynamics would probably be easiest to manage at around the asteroid belt or Jupiter. In Mars orbit, the Audacity barely needed any of the normal cooling capacity that the Earth orbit environment required.
Hmmm, I wish I had the example where the module cooled down to 40K or so. I think it was shut down at the time though, so youre probably right.
yes, but if you're flying a mission deep into the inner solar system, heating your shadow side modules is stupid when you can just rely on the heat convection from those on the sun side. Plugging heating in in that case would simply waste power in order to place a further burden on the MCS system.
Can you comment on the visual design, writing tone, specifically? If you have a spare moment, maybe we can add that final logo design as the cover picture for the IMS usergroup.
Ah yes, my bad, I garbled the part about heat in/heat out for solar panels.
The one thing I was thinking about though...
Can solar panels be used as radiators in cold environments? Solar panels might freeze in Jovian orbit, making them useless on a spacecraft, but if you wanted to hypothetically leave behind a small space station, couldnt it use its own solar panels for radiators and power generation? That might make more sense for the space station, since nuclear reactors do require a resource that cant be renewed, not easily at any rate. The prospects for finding radioactive fuel elsewhere in the solar system seems quite bleak from everything Ive heard.
The four display modes, like I showed in the screenshot. I know, I hate how vague it is too, maybe Ill include specific pictures of each mode selected as I explain them.
Thankyou
:facepalm:, yes what was I thinking with reactors consuming?
Page 12, first paragraph: Provided you got some thrusters, rcs and suitable propellant...
Page 13, first paragraph: Again with the accronyms... MFC is short for multi-function control. Also, you forget to mention the root menu.
Bah, small technicalities :lol:
I wanted to capture the feel of the thing more than the specifics. If they don't understand why RCS is needed, I think we have bigger problems on our hands as well
Thanks for the acronym check
Thanks, will change that.
Maybe it is better placed in design for dummies?
I know the documentation can get bloated way out of proportion if we're not careful, but I would like to keep that section in there. Many IMS users may not be quite as familiar with important concepts, so I would like to hang on to things like that.
Yeah, I was trying to figure out something and it didnt work at all. Ill just cut that part out, unless there is a way to approximate it that we can include?
So in reality there should be a very small thrust from the engine as it warms up? I would assume that coldfiring a chemical engine would probably shatter the thing since it would be so brittle at low temperatures.
Ill try to work that blinking part in. Im just not sure what needs to be included, and what we can just leave to users intuition to find out. Describing every last detail about the interface would take forever.
Thanks, I didnt recognize them right away. I tested them on the audacity, which was useless when it doesnt have any engines in the hover group.
The autopilots really are redundant once you know how to read the hud though. On an IMS ship, its often just easier to reorient the ship manually since the APs always swing back and forth over the right direction, wasting RCS fuel.
So non integrated modules can still transfer too? Will fix
Thanks
What the...
So they just leave the green one in the alarm clock? :lol:
So much for gratitude.
Athena
Smitty Werbenjagermanjensen
Wondering, is there any plans in the future to make some sort of gyroscopic modules that use electricity for orientation instead of fuel?
BruceJohnJennerLawso
Dread Lord of the Idiots
- Joined
- Apr 14, 2012
- Messages
- 2,585
- Reaction score
- 0
- Points
- 36
Control Moment Gyroscopes? That was suggested before, somewhere. We can add that to our list depending on how hard the implementation actually ends up being. We already have some bugs to clean up after 2.3, so features are second place priorities for the moment.
Scav
Mostly Harmless
- Joined
- May 8, 2010
- Messages
- 1,002
- Reaction score
- 38
- Points
- 48
PeterRoss
Our friendly neighborhood Putinist
There can't be a tie in an array. There's always a first value being compared with a second one, and if the second is the same as the first one, I guess the first one will be chosen.
Don't you think it's IMS 2.0 matter?
He's not to be seen by a human. Or maybe he's living there, who knows?
These plans existed from the very beginning of the IMS project. There was always something more importat to do first though...
You? Wrong?
:lol:
Just kidding.
Tell this to my wife:lol:
---------- Post added at 07:43 ---------- Previous post was at 07:26 ----------
A question to Jedidia:
I was designing this particularly complex animation for my Lunar Lander's solar array, and when I tested it in a simulation all the axes and directions appeared inverted! It was like a blast with solar panels flying around like shreds. I rechecked everything several times - it apeears absolutely correct in 3Dmax, but it goes opposite in Orbiter. So, question is: how does IMS handle animation elements' coordinates? Can it be that it's connected somehow with module's orientation within a vessel?
Just for a laugh:
P.S. It is screwed in the same way in RC2.0 too.
Last edited:
MaverickSawyer
Acolyte of the Probe
Did you remember that it's a left hand rule for vectors in Orbiter? I can't count the number of times that gave me grief... Still does, actually. :compbash2:
jedidia
shoemaker without legs
that's very basic OrbiterAPI stuff. You can iterate through vessels, and from there you can iterate through attachment points. The points know where they are, and getting the distance between two vectors is a very basic operation (i.e. substracting them, and getting the length of the new vector).
considering that we're working with double types and do some operations with them, that's as good as impossible (double operations tend to be inprecise somewhere behind the 10th digit or so). If the incredible should happen, first in wins.
These are standard oapi functions. You can look them up as well as I can (the one in question is oapiDeleteVessel, if you must know). Deleting a vessel is one single line of code.
Don't. Just... don't. You have no Idea how interconnected the code currently is. Something like this might be possible after a core rewrite, but currently it would be an overwhelming effort, and a wasted one. You would be a lot faster just writing a bare-bones implementation of the basic concepts from scratch than extracting it all from IMS.
Yes, it would be. And someone is going to try a space in the name, sees that IMS doesn't crash, think the info is outdated and the issue got fixed, and later report trouble with UMMU transfer.
Sorry, that would be page 2. I was going with PDF reader's page numbering in this case, which also counts the title page...
Hey, I wrote the darn thing! :lol:
I have no Idea where the flash of the heating comes from, but I do know that the transport seal flag bypasses all thermodynamics calculations.
Solar panels don't usually have plumbing, so no.
Yes, the question was rethorical. I know what you're refering to, I was pointing out that the sentence is lacking the object.
I don't think so. Even then, using approximations for DV calculation is playing russian roulette.
Completely negligible, but yes.
The difference is that there is no module type "cooling module". Any life support module can or cannot have thermal control equipment. But you are right, this is best left for the modders guide, since the modules are called cooling modules in the filename.
I can't remember ever having built a vessel that needed a couple hundred kilowatts. 150 was about the largest, I think. Not everyone's a megalomaniac like Nexiss... :lol:
Plus I think first attempts will potentially be small vessels, to learn the kinks.
PeterRoss
Our friendly neighborhood Putinist
:uhh: Vectors, schmectors... So that's what they meant talking about left hand rule for vectors! :facepalm:You tend not to notice such things when creating mostly symmetrical un-animated modules.
So, here it is fixed, assembled and working:
MaverickSawyer
Acolyte of the Probe
:rofl: Glad to see you got that fixed. Love the new arrays. Can you release those soon?
Athena
Smitty Werbenjagermanjensen
asdf
I don't know why this happens but, there's some sort of...random...stick kind of thing that's sticking out of the station....and i have no idea how to remove it, i tried reinstalling IMS and Orbiter, still doesn't disappear :compbash2:
I don't know why this happens but, there's some sort of...random...stick kind of thing that's sticking out of the station....and i have no idea how to remove it, i tried reinstalling IMS and Orbiter, still doesn't disappear :compbash2:
BruceJohnJennerLawso
Dread Lord of the Idiots
- Joined
- Apr 14, 2012
- Messages
- 2,585
- Reaction score
- 0
- Points
- 36
asdf
I don't know why this happens but, there's some sort of...random...stick kind of thing that's sticking out of the station....and i have no idea how to remove it, i tried reinstalling IMS and Orbiter, still doesn't disappear :compbash2:
Always a surprise in store :lol:
My best guess is that you have a corrupted mesh in your install, although it still seems unlikely. Try redownloading SSBB 4.1B and installing to see if the problem is in there.
Are any of your modules animated?
PeterRoss
Our friendly neighborhood Putinist
:rofl: Glad to see you got that fixed. Love the new arrays. Can you release those soon?
I don't think so, really. There is hell of a work to make Lander playable, another problem is that most of Lunar Lander modules don't have universal docking ports like SBB41 modules have and you will not be able to assemble anything with it except of Lunar Lander.
Wow... :blink: Post your scenario please.
Athena
Smitty Werbenjagermanjensen
I deleted the scenario...because the station design was utterly wrong, was building it upside down. :facepalm:, it seems that the some mesh files are a bit corrupted, the stick thing is gone from BM201 (the control module with large docking ports) but now it's appearing on the BN200 node...:blink:
I'll try to reproduce this when i get the opportunity to...it seems that reloading it fixes it but sometime the stick comes back. :hmm:
I'll try to reproduce this when i get the opportunity to...it seems that reloading it fixes it but sometime the stick comes back. :hmm:
PeterRoss
Our friendly neighborhood Putinist
What IMS version you're using? If it's RC2.3 try to reproduce it with RC2 too please.
---------- Post added at 23:02 ---------- Previous post was at 18:39 ----------
Furet's issue just disappeared when I've commented out symmetry check in SetCenterOfGravity(), just as I thought. I'm not sure how it's connected with module being rotated or not though, nevertheless it works.
Jedidia, how do you think, should we just clip the symmetry check block out of the code, or maybe it's better to tweak its inaccuracy coeffitients? Or maybe it's better to make a general check if the shift is small enough to be neglected after NewCOG is being calculated?
---------- Post added at 23:02 ---------- Previous post was at 18:39 ----------
Furet's issue just disappeared when I've commented out symmetry check in SetCenterOfGravity(), just as I thought. I'm not sure how it's connected with module being rotated or not though, nevertheless it works.
Jedidia, how do you think, should we just clip the symmetry check block out of the code, or maybe it's better to tweak its inaccuracy coeffitients? Or maybe it's better to make a general check if the shift is small enough to be neglected after NewCOG is being calculated?
Last edited:
jedidia
shoemaker without legs
I suspected something like this...
One of the problems is that the symmetry code isn't any use if the command module isn't aligned with X/Y zero, that would require some intelligence to detect an axis of symmetry completely dynamicaly.
The special case we have here is that not only is the CM not alligned with the Z-axis, but the whole vessel is effectively rotated around the CM from the get go. I'm not sure how that confuses the symmetry, but I expected the culprit to lie somewhere there as soon as I read Furet's comment that it only happens if he rotates the CM. Because in that case, you're not actually rotating the CM. You're rotating everything else, and completely out of symmetry too.
I can't tell you how to fix it from here, this would require some thought. However, kicking out the symmetry completely will lead to trouble with large vessels, because we'll run full throttle into double imprecision with the CoG calculation (the reason why IMS checks for symmetry in the first place). Better to find out why exactly the given circumstances break the calculation.
A quick and dirty fix would be to change the attachment points in the CM so that they are all parallel with the Z-axis, which would make the circumstances under which this can occur somewhat rarer, but that doesn't get rid of the problem. Also interesting to know might be, what happens if you rotate the CM by 180 degrees instead of 90?
Similar threads
