Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Addons > Addon Development
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Addon Development Developers post news, updates, & discussions here about your projects in development.

Reply
 
Thread Tools
Old 02-23-2009, 02:49 AM   #61
Ursus
Rocket Tinker
 
Ursus's Avatar
Default

Quote:
Originally Posted by Scarecrow View Post
 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 !?
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.

Try sticking the contents of the attached zip file in the modules directory of your test installation and see if it works better.
Attached Files
File Type: zip ICOVD1FixTest090222.zip (199.4 KB, 12 views)
Ursus is offline   Reply With Quote
Old 02-23-2009, 03:03 AM   #62
Scarecrow
Orbinaut
 
Scarecrow's Avatar
Default

Quote:
Originally Posted by Ursus View Post
 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.
Scarecrow is offline   Reply With Quote
Old 02-23-2009, 04:30 AM   #63
Drake
Addon Developer
Default

Quote:
Originally Posted by Linguofreak View Post
 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!
Drake is offline   Reply With Quote
Old 02-23-2009, 07:54 AM   #64
Drake
Addon Developer
Default

Purple Exhaust - the work of 5 minutes just to see if it will work.Exhaus_purp.zip

Modified from Exhaust.dds in the core release...
Drake is offline   Reply With Quote
Old 02-23-2009, 01:46 PM   #65
Peskie
Orbinaut
Default

Quote:
Originally Posted by Ursus View Post
 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.
Peskie is offline   Reply With Quote
Old 02-24-2009, 02:49 AM   #66
Ursus
Rocket Tinker
 
Ursus's Avatar
Default

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/show...ease_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 is offline   Reply With Quote
Old 02-24-2009, 04:49 AM   #67
Ursus
Rocket Tinker
 
Ursus's Avatar
Default

Quote:
Originally Posted by Drake View Post
 Purple Exhaust - the work of 5 minutes just to see if it will work.Attachment 2130

Modified from Exhaust.dds in the core release...
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.
Attached Thumbnails
purpexhaustnoalpha.png   kulchexhaust.png  
Ursus is offline   Reply With Quote
Old 02-24-2009, 09:16 AM   #68
Drake
Addon Developer
Default

Quote:
Originally Posted by Ursus View Post
 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! 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?

Click image for larger version

Name:	ramjet01_concept.jpg
Views:	93
Size:	183.6 KB
ID:	2141

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...
Drake is offline   Reply With Quote
Old 02-24-2009, 10:34 PM   #69
Peskie
Orbinaut
Default 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
    Exploreur
    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
    Exploreur
    . 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!
Peskie is offline   Reply With Quote
Old 02-25-2009, 04:00 AM   #70
Imagineer
Orbinaut
 
Imagineer's Avatar
Exclamation Autopilot limits

Quote:
Originally Posted by Peskie View Post
 
  • 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.
Quote:
Originally Posted by Peskie View Post
 
  • 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.
Quote:
Originally Posted by Peskie View Post
 
  • 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.
Quote:
Originally Posted by Peskie View Post
  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.
Imagineer is offline   Reply With Quote
Old 02-25-2009, 04:30 AM   #71
tblaxland
Webmaster
 
tblaxland's Avatar


Default

Quote:
Originally Posted by Imagineer View Post
 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?
Attached Files
File Type: zip AttitudeMFD.zip (99.4 KB, 8 views)
tblaxland is offline   Reply With Quote
Old 02-25-2009, 06:21 AM   #72
Ursus
Rocket Tinker
 
Ursus's Avatar
Default

Quote:
Originally Posted by Peskie View Post
 
  • 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.

Quote:
  • 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.

Quote:
  • 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...

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

Quote:
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.

Quote:
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.

Quote:
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.)
Ursus is offline   Reply With Quote
Old 02-25-2009, 06:35 AM   #73
tblaxland
Webmaster
 
tblaxland's Avatar


Default

Quote:
Originally Posted by Ursus View Post
 (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?
tblaxland is offline   Reply With Quote
Old 02-25-2009, 06:47 AM   #74
Ursus
Rocket Tinker
 
Ursus's Avatar
Default

Quote:
Originally Posted by Drake View Post
 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"

Quote:
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 is offline   Reply With Quote
Old 02-25-2009, 07:15 AM   #75
Ursus
Rocket Tinker
 
Ursus's Avatar
Default

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.
Attached Thumbnails
AttMFD.png  
Ursus is offline   Reply With Quote
Reply

  Orbiter-Forum > Orbiter Addons > Addon Development


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 07:08 AM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.6
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.