# ProjectICOVD Windmill Class Interplanetary Ramjet Development Thread

#### tblaxland

Webmaster
I'm not sure I really understand the difference between 3. & 4. except that 4. looks like less work. Either way, I'm glad you understood what the issue was because you really had me scratching my head with Attitude MFD.

#### Navee

##### New member
I had my eye on this project back when M6 was still up and running, glad it hasn't died.

After testing out the latest version, I must say I am impressed. Once everything is completed this will certainly be my interplanetary vessel of choice. I didn't really notice any outstanding bugs; however it might be nice if the colors of the various ARM buttons were a bit easier to distinguish armed from disarmed. Before I got used to how everything worked I ended up getting confused quite a few times as to whether something was armed or not.

Besides that I'm not quite sure what to say. Everything seemed to work properly and anything that I could recommend is already planned. Therefore, good work and good luck with this project.

#### Ursus

##### Rocket Tinker
I added an extra set of thrusters (logical) in back, for the bank thruster groups. Once I got everything straightened out, it seems to work nicely.

Almost makes me think we're now going to need rotational velocity and acceleration gauges so I know when it's safe to turn off the AP and go into high time-compression for a while (or maybe a little indicator indicating whether the AP has actually commanded any thruster firings within the last second or so). As I mentioned before, though, I've usually turned off the rear RCS reactors by then, so I'll still be able to use the acceleration gauge for such purposes.

The rotational velocity gauge will likely come eventually (probably around the same time as other crew comfort related displays), but unless the demand from others is too great, I don't think I'll make it a high priority.

I'm not sure I really understand the difference between 3. & 4. except that 4. looks like less work. Either way, I'm glad you understood what the issue was because you really had me scratching my head with Attitude MFD.

Theoretically, two (logical) thrusters per rotation group and one per translation group would make a (teeny-tiny) bit less work for the Orbiter core. Really, though, the performance gains probably aren't enough to justify the added coding headaches.

I didn't really notice any outstanding bugs; however it might be nice if the colors of the various ARM buttons were a bit easier to distinguish armed from disarmed. Before I got used to how everything worked I ended up getting confused quite a few times as to whether something was armed or not.

I think I noticed that too, at one time, then got used to the buttons and sort of forgot about it. I might try darkening the yellow cross-hatch a bit when the buttons are in the disarmed state. Hmm... actually, it looks like I might have done that a bit.

Maybe something like this... (Left is current arm button in various states, right is a possible change.)

#### Attachments

• NoSlew.jpg
64.9 KB · Views: 188
• Armbuttons.png
4.5 KB · Views: 186

#### Navee

##### New member
Hmm, I don't think that changing the cross-hatch is the answer.
Perhaps something like this?

To be honest, I'm not quite happy with the bottom one myself, but the enabled one second from the bottom I think came out pretty well. Really, it isn't that big of a deal. Now that I am used to them the current buttons work fine. I only got confused a few times on my first run, but I don't see anyone mistaking these for off.

#### Attachments

• Armbuttons2.png
9.1 KB · Views: 191

#### tblaxland

Webmaster
Almost makes me think we're now going to need rotational velocity and acceleration gauges so I know when it's safe to turn off the AP and go into high time-compression for a while (or maybe a little indicator indicating whether the AP has actually commanded any thruster firings within the last second or so). As I mentioned before, though, I've usually turned off the rear RCS reactors by then, so I'll still be able to use the acceleration gauge for such purposes.

The rotational velocity gauge will likely come eventually (probably around the same time as other crew comfort related displays), but unless the demand from others is too great, I don't think I'll make it a high priority.
One future idea I had for Attitude MFD was to make an attitude ball type display for it. It would have linear gauges to show angular velocity and acceleration, a bit like an Apollo FDAI. That is some way off though, because I don't even know how to code such a feature at the moment.

Your issue also made me think of another feature that may be useful for vessels that introduce linear acceleration when firing rotational thrusters: nulling of individual axes errors sequentially. At the moment, Attitude MFD aims to null the pitch and yaw axes simultaneously, followed by nulling the roll axis once those errors are low enough. For rotational thrusters that introduce linear acceleration this could be replaced by nulling pitch then yaw then roll. It would not be as fuel efficient but it would be workable.

#### Ursus

##### Rocket Tinker
0.3a patch 090509 now online

Patch niner-five-niner is now up, with the powers-of-1000 engineering notation on the engineering panel. One of these days, I've got to put in the numbers for how low each readout will go before it doesn't even register. I think I already added such an option to the function that generates the readout string.

I've also tacked a little control for the habitat rotation into the corner of the engineering panel. (Speaking of habitat rotation... is everyone around here familiar with SpinCalc? I can't recall having seen it mentioned around here.)

The way I've got it now, the habitat wil spin up or down at a rate that produces about half a g in tangential acceleration. I'm not sure I like that number. Maybe it should spin up a bit faster (maybe producing 1g of tangential acceleration) at up to about 1.75rpm, then a bit slower afterwards, perhaps producing about a quarter in tangential acceleration of what it's producing in centripetal acceleration.

Well... that'll probably wait until I get around to the more sophisticated habitat controls and displays on the systems panel.

Speaking of centripetal acceleration... I dread to think of the g-forces involved during major attitude changes, especially with the habitat being so far from the center of mass. One of these days, I'll actually calculate it out.

Then there are the gyroscopic effects that probably won't be simulated for quite a while. (Just pretend they are and spin-down the hab before making any major attitude changes.)

I think it's about time to get to that long-dreaded code re-structure.

#### Attachments

• HabRotControl.png
5.5 KB · Views: 413

#### Ursus

##### Rocket Tinker
My desktop machine has given up the ghost. It looks like my restructure and subsequent development towards this project are on indefinite hold until I can scrape together enough pennies for a new MB assembly (Mobo/CPU/probably RAM, and I think I'll need a new WingDoze license... Aagh! Why does Orbiter have to be so tied down to MacroSquash?!).

I guess another option might be to find a halfway decent pre-owned machine, with its own copy of the MS OS, that I can get for a pittance or less.

Any way... until I can work something out, my Orbiter development is pretty much dead in orbit.

#### Imagineer

##### Fracking toaster
It's necrotime!

Something like this shouldn't be taking a dirt-nap anyway XD

The latest dll found at http://sourceforge.net/projects/icovd/files/ICOVD1 Windmill/ICOVD1 Windmill 0.3a/ works in orbiter 2010p1, but always crashes within a minute or so. I've recompiled from source and it's much more stable, however I had to mangle the following:

Code:
--- ICOVD1_Autopilot.cpp.old    2011-01-08 09:13:07.900875000 -0600
+++ ICOVD1_Autopilot.cpp        2011-01-08 08:32:43.025875000 -0600
@@ -3,13 +3,13 @@

const VECTOR3 Forward = _V(0.0, 0.0, 1.0);

-inline VECTOR3 unit(VECTOR3 v)
+/*inline VECTOR3 unit(VECTOR3 v)
{
double l=length(v);
v.x/=l; v.y/=l; v.z/=l;
return(v);
}
-
+*/

inline double angle(VECTOR3 v,VECTOR3 h)
{

Will development resume at some point? If things are still in hiatus, and people want it, I can attach the fixed .dll.

#### Mister Kite

##### &#%[email protected]?!
Donator
I had the same problem and I love that ship, so: Yeah, please do.
Also hope for a resurrection.

#### Ursus

##### Rocket Tinker
Thanks, atomicdryad. Unfortunately, I've been so broke that I can't afford to install Windows on my "new" computer. That means I haven't even been able to run Orbiter (I haven't managed to get it working under WINE), let alone develop for it. (Maybe I'll manage to swing it with my tax refund this year. I do have another unrelated project or two that I'd like to test under Windows.)

In the meantime, perhaps I ought to merge the above files and put 'em up on SF. I'd get a little nervous putting up something I can't test myself, but... Hmm... I might think about that one, but it'd probably be all right if I can get assurances from the right people.

##### Fracking toaster
I built this in vcpp2008, which I'm unfamiliar with and also required configuring the project from scratch, so I hope there isn't some lurking dependancy in the dll. I checked with strings, however, and found none in that fashion, but it would be nice to know that it tested fine on another machine before making it official, yeah.

Sorry to hear of your windows and financial woes, I hope that this year becomes a better one!

#### Linguofreak

##### Well-known member
(I haven't managed to get it working under WINE)

Have you been using OGLAClient in trying to get things running? What distro are you using, and what's your video card?

I've got Orbiter running with OGLAClient almost perfectly under Wine (with the exception that my joystick throttle and rudder don't work, and a bug I've found with the camera dialog, plus perhaps a few other minor issues that I'm not thinking of or that are addon specific).

EDIT: I just got the throttle working. Rudder is still trouble. It took me a long time to figure out that the joystick wasn't working perfectly, since when I first got Orbiter running under Wine I didn't have a joystick available.

EDITed EDIT: Some fiddling around with other programs suggests a Wine problem with joystick handling is suppressing the rudder axis.

Last edited:

#### Ursus

##### Rocket Tinker
Hmm... Had to do a little tweaking to get the panel buttons to redraw consistently in Orbiter(D7?), and the Integrated Situation Display "bugs" to draw correctly in Orbiter_NG/D3D9. Should have access to a computer with Vista even after W8RP expires in January, so I might do a bit of work on this thing.

Lessee... Probably ought to compile anything I publish in VC2008, as folks are more likely to have the runtimes, if necessary, than the ones for VC2010.

#### Ursus

##### Rocket Tinker
Now that I've got a Wingdoze computer capable of compiling AND testing, I uploaded a minor update to Sourceforge ( http://sourceforge.net/projects/icovd/ ). I haven't done a whole lot of testing of it under Windows, but it seems to work. When I was testing it under WINE (where the MFD's didn't s display last time I remember), I kept coming across an elusive CTD bug right around the time my fuel reserves reached minimum.

Shift-3 controls the floods for the truss, IIRC. I'm still not up to speed since I got tired of compiling on a Windows netbook and testing under WINE (and working on the Vista machine was a pain when the owner kept wanting to jump in and use it).

Last edited:

#### Ursus

##### Rocket Tinker
Oop... Good thing nobody seems to care about this project anymore. It turns out the main engines won't activate on the latest version I posted. I kept meating to upload a fixed version, but kept putting it off. Now the new computer is being a brick. She's still under warranty, so hopefully I'll be back up and running soon.

Replies
180
Views
4K
Replies
39
Views
2K
Replies
16
Views
678
Replies
8
Views
751
Replies
11
Views
627