Project ICOVD Windmill Class Interplanetary Ramjet Development Thread

Ursus

Rocket Tinker
Addon Developer
Joined
Oct 20, 2007
Messages
176
Reaction score
2
Points
18
Location
46N 123W
More details then...

On my machine at least it's 100% reproducible (none of that funny "it only happens when you're not looking" business). Here are the exact conditions under which it happens (as far as I can tell):

- It never happens if at least one of the reactors is at least at the "Compressing Fuel" stage.

- It always happens immediately if all the reactors are off.

- It always happens immediately if 4 reactors are off, and one is at the "Ionizing Fuel" stage, and its top green bar is all the way full.

- When one reactor is at the "Ionizing Fuel" stage, but its top green bar is not full, and all the other reactors are off, it will not crash until the top green bar is full, at which point it always crashes.

- I don't know about the "Fuel Flow started" stage, because I can't start a reactor, and then shut down another by the time it's already at "Ionizing Fuel"

That's the dialog box I get ("orbiter.exe has encountered a problem and needs to close..."). When I ask to see what the error report contains, it tells me this:

EventType: BEX
P1: orbiter.exe
P2: 0.0.0.0
P3: 451d1ff5
P4: ICOVD1.dll
P5: 0.0.0.0
P6: 498d378a
P7: 0000c157
P8: c0000409

I'm no windows guru, so I'll leave it to others to interpret that. Unfortunately I can't tell what BEX means, so it's hard to say whether it was a seg fault, a divide by zero, or what. Also, if you want the mdmp file or the appcompat.txt file, I can upload them for you.

After the error occurs, Orbiter.log shows nothing unusual.

And by the way, I'm curious about one particular stage in the reactor start up. What does "Injecting Pixie Dust" mean :rofl:!?

I guess I really ought to label those bars. From top to bottom, they're:

* Core Mass
* Electrical Drain/Generation Capacity
* Fuel Flow
* Core Temperature
* CT Detail (lower range)
* Turbulence/Instability (Which I'm thinking of dropping because when I went to extend the instability code into points in the cycle in which it might actually be relevant, I found that I couldn't get the instability to... stabilize... oh, just a sec... maybe... and because the algorithm is probably totally unrealistic anyway.)

In all the crash situations none of the reactors is drawing fuel from the fuel system... (Either the reactor is turned off, or it has gotten its initial fuel load but the fuel hasn't gotten hot enough to start fusing.)

I'm guessing that if you turn off the cross-feed (just click on the button that's lit), while reactors 3 and/or 4 are the only reactors running, you'll get the same crash.

Hmmm... I wonder if trying to typecast a MAX_FLT into an int would cause a buffer overflow (which is what Event type: BEX supposedly is) on some processors (like newer ones than mine, which have hardware checks for buffer overflows)... Come to think of it, it probably would, since MAX_FLT > MAX_INT. There's a lesson to be learned; don't use MAX_ANYTHING for a return code. :blush:

Try sticking the contents of the attached zip file in the modules directory of your test installation and see if it works better.
 

Attachments

  • ICOVD1FixTest090222.zip
    199.4 KB · Views: 12

Scarecrow

New member
Joined
Feb 10, 2008
Messages
272
Reaction score
1
Points
0
Location
USA
Try sticking the contents of the attached zip file in the modules directory of your test installation and see if it works better.

Works like a charm!:) Thanks very much.
 

Drake

Addon Developer
Addon Developer
Joined
Feb 11, 2009
Messages
28
Reaction score
0
Points
0
Drake, you're from CO? Whereabouts? I grew up in north Denver (Thornton-ish, specifically).

I went to high school in Littleton, went to college in Golden, took my Master's in Boulder and live in Longmont!:)
 

Peskie

New member
Joined
Oct 7, 2008
Messages
41
Reaction score
0
Points
0
Location
Southern Ontario
Is anyone else able to reproduce the bug?

[FYI since no one else has mentioned repeating this bug]
Although I wasn't specifically trying to reproduce it, I can confirm my Orbiter installation did crash when shutting down the last reactor. Because I wasn't trying to reproduce this I was running in a far-from-clean Orbiter installation and has been running for some time so it could have been due to some other MFD or something.
 

Ursus

Rocket Tinker
Addon Developer
Joined
Oct 20, 2007
Messages
176
Reaction score
2
Points
18
Location
46N 123W
I put together a new distro package and put it up on SF and deleted the older versions. Buffer overruns give me the heebie jeebies-- and it's not Scarecrow's or Peskie's computers I'm not worried about, but computers that don't catch them, so all those little bits go running around loose in the computer.

If you have the older version, you just need the patch (...patch090223). If you download the current version (...beta090223), you don't need the patch.

https://sourceforge.net/project/showfiles.php?group_id=199743&package_id=237101&release_id=655590

The only difference between the dll in the distro and the dll in the zip I attached above is that I've commented out anything having to do with that dang reactor "instability" code (including the debug message, of course), and I've added labels to the reactor gauges.
 

Ursus

Rocket Tinker
Addon Developer
Joined
Oct 20, 2007
Messages
176
Reaction score
2
Points
18
Location
46N 123W
Purple Exhaust - the work of 5 minutes just to see if it will work.View attachment 2130

Modified from Exhaust.dds in the core release...

Hmm... the texture isn't quite right...

Actually, the default texture in McWgog's [ame="http://www.orbithangar.com/searchid.php?ID=1494"]replacement exhaust textures[/ame] is nice and purple. Those must be the ones about which I was thinking. Come to think of it, it looks like Orbiter 2009 (or 2012 or whatever) is going to come with those textures (the 2008 public beta has nice purple exhaust).

Edit: Pay no attention to the file name of the pic on the right... I misread the description on OH.
 

Attachments

  • purpexhaustnoalpha.png
    purpexhaustnoalpha.png
    187.3 KB · Views: 27
  • kulchexhaust.png
    kulchexhaust.png
    31.5 KB · Views: 27

Drake

Addon Developer
Addon Developer
Joined
Feb 11, 2009
Messages
28
Reaction score
0
Points
0
Hmm... the texture isn't quite right...

Actually, the default texture in McWgog's replacement exhaust textures is nice and purple. Those must be the ones about which I was thinking. Come to think of it, it looks like Orbiter 2009 (or 2012 or whatever) is going to come with those textures (the 2008 public beta has nice purple exhaust).

Edit: Pay no attention to the file name of the pic on the right... I misread the description on OH.

Oh, so THAT's what that part of the texture did! :rofl:I just color-shifted everything and had a big purple block on the side. Oh well...

No, the other one is quite preferable I think.

So you are a bad (good) influence on me. I started from scratch to re-design a ramjet today. This one is a big one - maybe it is a testbed for the trip to Alpha Centauri?

ramjet01_concept.jpg

The little pink eraser thing is the size of a Shuttle-A parked on the landing pad. The rings are 200 m in diameter and counter-rotate once every 30 seconds for 1g pseudo gravity. At the moment it is 1km long, though I might trim it.

I am still messing with concepts for the powerplant and the exhaust bell, and I have to figure out if I need to add something in front of the docking area.

Anyway, you guys have inspired me. Maybe once you get the code like you like it, I could borrow it for modification to make this one fly?

Either way, it is fun to think about these ships! What a time we live in that we can think such thoughts...
 

Peskie

New member
Joined
Oct 7, 2008
Messages
41
Reaction score
0
Points
0
Location
Southern Ontario
Random thoughts on the Windmill

So I've played around with this a bit now (the 090206 version mostly) after having just recently been introduced to the Vespucci D. I really like it. Here are some random thoughts I had:


  • Fonts/Panels: I think these look really nice! I also like how CTRL-up/down/left/right wrap around and switch panels from any other panel instead of how some other ships do it with specific panel 'locations'.

  • Textures: I think the docking ports need to be more visible; perhaps some docking lights that can be turned on/off from the docking panel. In general the whole front of the ship seems to be too dark. I tried turning up Orbiter's ambient lighting and doing docking ops in LEO on the day side but I still had trouble seeing much of anything.

  • Aux Reactors 1-4: I assume the purpose of having 4 of these will be described in the to-be-written documentation... but it appears as if they're (randomly) hooked up to different RCS thrusters and if not all four are started some thrusters just won't fire. This means that firing rotational thrusters sometimes gives a linear thrust and sometimes linear thrusters give a rotation and that killrot only sometimes works. This seems unhelpful/useless (i.e. if I want to do anything I need to start all four reactors and if I care about reactor usage I need to shut them all down after). If you want to have multiple reactors driving the RCS controls it would seem much more useful if they were all tied into a main bus or somesuch so that if not all four are running the effect is just limited RCS thrust as opposed to a completely messed up and useless RCS. Just my opinion.

  • Custom RCS: I mostly like the custom auto-pilots but it seems to interfere with some MFD's control. IMFD can still turn the ship for auto-burns (except that it can't end/abort with a KillRot like normal) but AttitudeMFD can't turn the ship at all. AttitudeMFD can still use the linear thrusters for nulling relative velocities tho. Assuming that the failure of AttitudeMFD to control this ship isn't it's fault but is related to this ships custom RCS system then I think it should be re-thought. Alternatively adding a new "hold this attitude relative to my oribital velocity vector" autopilot might be a good idea.

  • The CLCT autopilot: This appears to just point towards the sun whereas the little blue marks on the twin orientation displays seems to point to the actual particle stream direction and sometimes this does not point at the sun and turning the ship to point at the blue marks increases the collection fuel flow. I.e. the CLCT autopilot doesn't always point in the right direction. Also, since there is a collection scoop on the rear; if I'm pointed mostly that way when I turn on CLCT I'd hope for it to realize this and point me butt end first. Either that or have a separate CLCT+ and CLCT- buttons like NRM+ and NRM-; or make enabling the fore/aft collectors a switch and have CLCT turn whichever one is the active one into the stream.

  • Control at 100x and above: From trying the supplied Titania->Triton scenario it seems like this ship needs to operate with continuous burns for long periods of time. I really like max/ram/acc/comp autothrottle modes (the lack of these on the Vespucci was really annoying) which eases a lot of this but I found it really hard to keep the ship lined up for my burn at above ~75x. (The off-center mass of the docked XR5 didn't help any). AttitudeMFD can handle holding attitude at 100x and 1000x but doesn't work with this ship. The custom-RCS autopilot works reasonably well if you happen to want to point in direction it supports but it still gave me periodic RCS thrust storms (where the RCS goes crazy for a few seconds burning all over the place; although my attitude didn't change too much during these it used a lot of fuel). This happened for me as low as at 80x (which with various CPU hog MFDs open like IMFD map and orbitMFD gave me FPS of ~50 and a timestep of around 1.6 seconds). For this ship I'd even go so far as to cheat and have a killrot at 100x just cheat and every timestep force the ship back to reference attitude with zero rotation; RCS fuel usage with a ram scoop is pretty irrelevent whereas maintaining attitude for a multi-day burn is very relevent (IMHO).

As for features I'd like to see (some of these are already on your to-do list):

  • Center of gravity: adjusting for off-center mass due to docked vessels. E.g. with a single heavy XR5 docked on port 3 perhaps have an extendable truss stick out where port 4 is with a smaller mass farther out to counter it.
  • Plasma generation and venting: I notice you have a PV button on the main panel
  • Habitat rotation controls: including a display of rotation rate and generated 'gravity' with a setting for the later (within the limits of the hab ring) and have it take time to spin up/down (like the [ame="http://www.orbithangar.com/searchid.php?ID=2944"]Exploreur[/ame] but unlike the Vespucci's instant on/off).
  • Reactor temperature and cooling (sort of like Vespucci but better). Ideally you'd even track the fuel tank temperatures and heat radiation perhaps requiring auto/manual operation of fuel pumps for cooling like the old FuelSystemMFD (on avsim, link unknown).
  • Damage/repair like the [ame="http://www.orbithangar.com/searchid.php?ID=2944"]Exploreur[/ame]. This would give a reason to shut-down the various reactors as running them too long/hot could cause failures, etc.
  • If the fusion engines shouldn't be used close to planet/moons (like the docs for the Vespucci claim) then showing the nearest planet/moon on the twin orientation displays (or whatever those cool circles with the small yellow triangle and blue marker is called) color coded for safety based on range and position (green is okay; yellow use caution; red is danger). Possiblly have an alternative way of thrusting when within these regions or just recommend using long bursts of linear thrusters to raise/break orbit.
Thanks for the really cool vessel! :cheers:
 

Imagineer

New member
Joined
Feb 11, 2008
Messages
47
Reaction score
0
Points
0
Location
N42 2.9 W 91 35.4
Autopilot limits

  • Custom RCS: I mostly like the custom auto-pilots but it seems to interfere with some MFD's control. IMFD can still turn the ship for auto-burns (except that it can't end/abort with a KillRot like normal) but AttitudeMFD can't turn the ship at all. AttitudeMFD can still use the linear thrusters for nulling relative velocities tho. Assuming that the failure of AttitudeMFD to control this ship isn't it's fault but is related to this ships custom RCS system then I think it should be re-thought. Alternatively adding a new "hold this attitude relative to my oribital velocity vector" autopilot might be a good idea.
I set it up with standard RCS groups so I am uncertain why AttitudeMFD is having problems. I do not normally use AttitudeMFD so I had not noticed. The "hold this attitude relative to my oribital velocity vector" mode is an interesting idea.
  • The CLCT autopilot: This appears to just point towards the sun whereas the little blue marks on the twin orientation displays seems to point to the actual particle stream direction and sometimes this does not point at the sun and turning the ship to point at the blue marks increases the collection fuel flow. I.e. the CLCT autopilot doesn't always point in the right direction. Also, since there is a collection scoop on the rear; if I'm pointed mostly that way when I turn on CLCT I'd hope for it to realize this and point me butt end first. Either that or have a separate CLCT+ and CLCT- buttons like NRM+ and NRM-; or make enabling the fore/aft collectors a switch and have CLCT turn whichever one is the active one into the stream.
This is a known bug. The autopilot is not coupled to the collection system yet. We'll get there.
  • Control at 100x and above: From trying the supplied Titania->Triton scenario it seems like this ship needs to operate with continuous burns for long periods of time. I really like max/ram/acc/comp autothrottle modes (the lack of these on the Vespucci was really annoying) which eases a lot of this but I found it really hard to keep the ship lined up for my burn at above ~75x. (The off-center mass of the docked XR5 didn't help any). AttitudeMFD can handle holding attitude at 100x and 1000x but doesn't work with this ship. The custom-RCS autopilot works reasonably well if you happen to want to point in direction it supports but it still gave me periodic RCS thrust storms (where the RCS goes crazy for a few seconds burning all over the place; although my attitude didn't change too much during these it used a lot of fuel). This happened for me as low as at 80x (which with various CPU hog MFDs open like IMFD map and orbitMFD gave me FPS of ~50 and a timestep of around 1.6 seconds). For this ship I'd even go so far as to cheat and have a killrot at 100x just cheat and every timestep force the ship back to reference attitude with zero rotation; RCS fuel usage with a ram scoop is pretty irrelevent whereas maintaining attitude for a multi-day burn is very relevent (IMHO).
This is a known limitation. The autopilot does not take dt into account yet. It is currently tuned for a bandwidth of 0.00065 Hz, so if the simulation dt exceeds 770 seconds then stability cannot be garanteed.
As for features I'd like to see (some of these are already on your to-do list):

  • Center of gravity: adjusting for off-center mass due to docked vessels. E.g. with a single heavy XR5 docked on port 3 perhaps have an extendable truss stick out where port 4 is with a smaller mass farther out to counter it.
All craft have limits on where the center of mass can be. Someday we will provide center of mass information on the docking panel and a caution light on the helm and engineering panels, which will light when the center of mass is outside the box. From an engineering perspective, gimballing the exhaust (with a compensating adjustment to the attitude reference) is a more likely way of dealing with it.

There is a fair amount of work left which I will get to in my copious spare time. :)
 

tblaxland

O-F Administrator
Administrator
Addon Developer
Webmaster
Joined
Jan 1, 2008
Messages
7,318
Reaction score
20
Points
113
Location
Sydney, Australia
I set it up with standard RCS groups so I am uncertain why AttitudeMFD is having problems. I do not normally use AttitudeMFD so I had not noticed. The "hold this attitude relative to my oribital velocity vector" mode is an interesting idea.
Is there a significant difference in torque between the yaw and roll thruster groups? If so, I believe this is caused by a bug in AttitudeMFD.

In one of the enum definitions, the yaw and roll identifiers are transposed so AttitudeMFD calculates the required thruster level based on the incorrect thruster group. You should still get some rotation though. Attached is a rebuilt module with the enum corrected, see if that works for you.

To think that little bug has been lying in there undiscovered for so many years (since at least Chris Knestrick's version 2 in 2003, as best as I can tell).

@Peskie, does AttitudeMFD display the attitude errors correctly? That is, if you pitch up 10° from the velocity vector, does it show +10° pitch? Similarly for yaw and roll?
 

Attachments

  • AttitudeMFD.zip
    99.4 KB · Views: 8

Ursus

Rocket Tinker
Addon Developer
Joined
Oct 20, 2007
Messages
176
Reaction score
2
Points
18
Location
46N 123W
  • Textures: I think the docking ports need to be more visible; perhaps some docking lights that can be turned on/off from the docking panel. In general the whole front of the ship seems to be too dark. I tried turning up Orbiter's ambient lighting and doing docking ops in LEO on the day side but I still had trouble seeing much of anything.

Lights of various types are definitely on the to-do list.

  • Aux Reactors 1-4: I assume the purpose of having 4 of these will be described in the to-be-written documentation... but it appears as if they're (randomly) hooked up to different RCS thrusters and if not all four are started some thrusters just won't fire. This means that firing rotational thrusters sometimes gives a linear thrust and sometimes linear thrusters give a rotation and that killrot only sometimes works. This seems unhelpful/useless (i.e. if I want to do anything I need to start all four reactors and if I care about reactor usage I need to shut them all down after). If you want to have multiple reactors driving the RCS controls it would seem much more useful if they were all tied into a main bus or somesuch so that if not all four are running the effect is just limited RCS thrust as opposed to a completely messed up and useless RCS. Just my opinion.

I hate the idea of trying to duct hot plasma too far along the ship. Containment failures would get awfully nasty. A tie-in switch might be a good idea, though.

I personally like to use just the two front reactors (3 & 4) for course corrections while burning. The tiny bit of lateral translation doesn't really hurt any thing.

  • Custom RCS: I mostly like the custom auto-pilots but it seems to interfere with some MFD's control. IMFD can still turn the ship for auto-burns (except that it can't end/abort with a KillRot like normal) but AttitudeMFD can't turn the ship at all. AttitudeMFD can still use the linear thrusters for nulling relative velocities tho. Assuming that the failure of AttitudeMFD to control this ship isn't it's fault but is related to this ships custom RCS system then I think it should be re-thought. Alternatively adding a new "hold this attitude relative to my oribital velocity vector" autopilot might be a good idea.
I believe the fact that the front and rear thrusters aren't equidistant from the center of mass is what messes up the AttitudeMFD (one of these days, maybe I'll verify that by deciphering the AttitudeMFD source). It frustrates me, too, since AttitudeMFD is otherwise a really good tool to use with this vessel.

(Oh... as I write, I see that btaxland has put in a comment. No, we don't seem to get any attitude thrust at all with the old AttMFD.)

Unfortunately, the main reactor needs to be in back, and it's heavy. Putting the front RCS thrusters as far forward as possible helps them generate more torque... so...


I might consider the powers-of-1000 engineering notation. It'll take a bit of work, though.

Center of gravity: adjusting for off-center mass due to docked vessels. E.g. with a single heavy XR5 docked on port 3 perhaps have an extendable truss stick out where port 4 is with a smaller mass farther out to counter it.

Eventually, we'll get to implementing transport cradles on the truss. Since the cradles will be attached, rather than docked, it'll allow a bit of "cheating" as far as center of mass calculations go (so that thrust vectoring and whatnot don't interfere with navigation MFD autopilots), though the code will keep track of the center of mass and, as Imagineer mentioned, warn the crew and maybe even refuse to arm thrusters if the center of mass is too far out of whack for thrust vectoring, RCS scaling and fuel shifting to reasonably be expected to compensate.

The currently existing docks are really more for shuttle vessels, or for transferring many crew members to or from a vessel that is carried on the truss cradles.

Habitat rotation controls: including a display of rotation rate and generated 'gravity' with a setting for the later (within the limits of the hab ring) and have it take time to spin up/down (like the Exploreur but unlike the Vespucci's instant on/off).

Definitely on the to-do list.

If the fusion engines shouldn't be used close to planet/moons (like the docs for the Vespucci claim) then showing the nearest planet/moon on the twin orientation displays (or whatever those cool circles with the small yellow triangle and blue marker is called) color coded for safety based on range and position (green is okay; yellow use caution; red is danger). Possiblly have an alternative way of thrusting when within these regions or just recommend using long bursts of linear thrusters to raise/break orbit.

Actually, the original purpose of the situation displays was to show nearby vessels and planets. I just haven't gotten to the point of actually coding that functionality in.

One problem with nearby planets is that they're so big. I (or some other ambitious contributor) am going to have to figure out how to draw an arc on the display representing the surface of the planet without using up too much processor time. (Though I can put those displays on a timer if I haven't already, so they don't have to refresh at every single time step.)
 

tblaxland

O-F Administrator
Administrator
Addon Developer
Webmaster
Joined
Jan 1, 2008
Messages
7,318
Reaction score
20
Points
113
Location
Sydney, Australia
(Oh... as I write, I see that btaxland has put in a comment. No, we don't seem to get any attitude thrust at all with the old AttMFD.)
No thrust at all? Very odd. Try the new one attached to my previous post. Also, what do the thruster brushes (at the bottom of AttitudeMFD) show when HOLD mode is activated?
 

Ursus

Rocket Tinker
Addon Developer
Joined
Oct 20, 2007
Messages
176
Reaction score
2
Points
18
Location
46N 123W
The little pink eraser thing is the size of a Shuttle-A parked on the landing pad.

Hmmm... there's a name for a vessel... "The Pink Pearl"

Anyway, you guys have inspired me. Maybe once you get the code like you like it, I could borrow it for modification to make this one fly?

Shouldn't be a problem... http://icovd.sourceforge.net/license/

(Ooh... I really need to update that site, including the above page... so many projects and sub-projects...)
 

Ursus

Rocket Tinker
Addon Developer
Joined
Oct 20, 2007
Messages
176
Reaction score
2
Points
18
Location
46N 123W
The brushes don't do anything when Hold is turned on.

They've always seemed to work fine when rotation thrust is applied manually or with the vessel's autopilots.
 

Attachments

  • AttMFD.png
    AttMFD.png
    46 KB · Views: 30

tblaxland

O-F Administrator
Administrator
Addon Developer
Webmaster
Joined
Jan 1, 2008
Messages
7,318
Reaction score
20
Points
113
Location
Sydney, Australia
The brushes don't do anything when Hold is turned on.

They've always seemed to work fine when rotation thrust is applied manually or with the vessel's autopilots.
Most bizarre. It obviously wasn't the bug I was thinking of. Unless this is a big problem for you guys I'm not going to spend a lot of time hunting this bug down. I've started re-writing AttitudeMFD to support some new features and the attitude autopilot needs to be re-written as part of that anyway. Hopefully this bug will disappear when I do that. I'm not going to commit to a release date at this stage.
 

trokkes

New member
Joined
Mar 24, 2008
Messages
28
Reaction score
0
Points
0
Preview

SIZE MATTERS!! :)

The Windmill, the ISS, XR5 and DG4

icovd26.JPG


icovd27.JPG

PS. Last textures send
 
Last edited:

Drake

Addon Developer
Addon Developer
Joined
Feb 11, 2009
Messages
28
Reaction score
0
Points
0
Hmmm... there's a name for a vessel... "The Pink Pearl"

Hee hee, sounds like a ship for Capt. Jack Sparrow...

Shouldn't be a problem... http://icovd.sourceforge.net/license/

(Ooh... I really need to update that site, including the above page... so many projects and sub-projects...)

Thanks! Even though the license allowed it, I thought it would be rude to presume, so thank you very much! I'll start a thread about it.
 

Peskie

New member
Joined
Oct 7, 2008
Messages
41
Reaction score
0
Points
0
Location
Southern Ontario
You should still get some rotation though. Attached is a rebuilt module with the enum corrected, see if that works for you.

I'm getting zero rotation and zero RCS activity. I had incorrectly assumed that they did something funny with the RCS since they had custom prograde/retrograde/etc auto-pilots; silly me.

I'll try the AttitudeMFD you provided (thanks!) and let you know but I'm guessing it won't change anything.

@Peskie, does AttitudeMFD display the attitude errors correctly? That is, if you pitch up 10° from the velocity vector, does it show +10° pitch? Similarly for yaw and roll?

Yes it does. It shows the error and the current rates; in fact I was using this display to manually attempt to keep the correct attitude but it gets hard at 100x :)


-----Post Added-----


I set it up with standard RCS groups so I am uncertain why AttitudeMFD is having problems. I do not normally use AttitudeMFD so I had not noticed.

Okay, good to know. Sorry about my incorrect assumtions.

The "hold this attitude relative to my oribital velocity vector" mode is an interesting idea.

If I can get AttitudeMFD to work it wouldn't be required unless yours works better under time compression. The nice thing with AttitudeMFD is that it does work well at 100-1000x and I have the source code so I could always add a "cheat" mode if I wanted :).

This is a known bug. The autopilot is not coupled to the collection system yet. We'll get there.

Oh yeah, I appreciate this is only beta. I didn't see this limitation listed in the testing notes so I figured I'd mention in case it slipped in or I was misunderstanding it.

This is a known limitation. The autopilot does not take dt into account yet. It is currently tuned for a bandwidth of 0.00065 Hz, so if the simulation dt exceeds 770 seconds then stability cannot be garanteed.

Do you mean a time step of 0.770 seconds? That's good to know the number, when I try to push the time warp I often have the Orbiter performance monitor running so I can monitor the time step and having a target to stay near is good. FYI, I've flown it quite a bit at ~1.3-1.5 second time steps with only minor issues.

There is a fair amount of work left which I will get to in my copious spare time. :)

Well it's coming along quite nicely, thanks for all the hard work! :cheers:
 

Ursus

Rocket Tinker
Addon Developer
Joined
Oct 20, 2007
Messages
176
Reaction score
2
Points
18
Location
46N 123W
Ok... the new textures have been put up and a new package created.

https://sourceforge.net/project/showfiles.php?group_id=199743&package_id=237101

I'm still kind of working out the release scheme. I'm thinking of alternating between "unstable" and "stable" release numbers... so 0.3 is "unstable". Right now, it's almost identical to the last update of 0.2 (which was actually unstable too), except for the updated mesh and textures, but patches are expected to follow. 0.4 would be "stable". It would be virtually identical to final update of 0.3 (maybe even exactly identical) and would stay that way. 0.5 would start out being not-too-different from 0.4, and may or may not just be a patch that goes on top of 0.4...
 
Top