Meadville Space Center
Welcome,
Guest
. Please
login
or
register
.
May 21, 2013, 05:56:27 AM
1 Hour
1 Day
1 Week
1 Month
Forever
Login with username, password and session length
Search:
Advanced search
Gemini 060615 released!
20010
Posts in
1929
Topics by
2250
Members
Latest Member:
mikegk
Meadville Space Center
Project Apollo - NASSP
Project Apollo - NASSP Development
(Moderators:
movieman
,
Tschachim
,
Swatch
,
lassombra
)
LunarTransferMFD
« previous
next »
Pages:
1
2
[
3
]
4
Author
Topic: LunarTransferMFD (Read 9610 times)
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
Posts: 3687
nassp.sf.net
Re: LunarTransferMFD
«
Reply #30 on:
March 30, 2009, 08:09:39 AM »
I understand the problem, but I do not like a "keyboard simulation" solution, I think the problem can be solved by changing the current IPC solution as well, it's just not designed to support multiple "communication partners". I need to think about that...
Cheers
Tschachim
Logged
jarmonik
Full Member
Posts: 130
Re: LunarTransferMFD
«
Reply #31 on:
March 30, 2009, 09:40:45 AM »
Quote from: Tschachim on March 30, 2009, 08:09:39 AM
I think the problem can be solved by changing the current IPC solution as well, it's just not designed to support multiple "communication partners". I need to think about that...
Yes, that's possible. Two most important things are GET syncronization and burn data uplink. GET syncronization can be solved by making the launch MJD globally available for all MFDs. This could be done by the master MFD (the first one called by the Orbiter). Burn data uplink can be solved by adding uplink button in the MFDs. In that case used must press 'REQ' button from the PAMFD and after that 'uplink' button from the MFD that is holding the data. This shouldn't require any modifications in the current IPC interface.
One possibility is to count a number of active source MFDs, and if there is only one active MFD then that's the one that should interface with PAMFD. I suppose that should be the case most of the time.
However, if turning over to active data interface class is better idea than staying in a static data structure, there are severals ways to deal with that too and the callbacks if needed.
Logged
Graham2001
Guest
Re: LunarTransferMFD
«
Reply #32 on:
April 13, 2009, 07:44:58 PM »
I'm still getting the CTD problem on my installation when I select the LTMFD. However with the latest version it is not an immediate CTD. I hear the slection 'click' noise and a couple of seconds later I get the windows error box.
I'm attaching the error log that resulted to this email.
IFP-SDK_Err.html
(2.77 KB - downloaded 112 times.)
Logged
jarmonik
Full Member
Posts: 130
Re: LunarTransferMFD
«
Reply #33 on:
April 14, 2009, 03:05:48 AM »
This could have something to do with the sound interface. It could be some other thread that will CTD. There is nothing in the LTMFD that could do this in this point. Can you run Orbiter under debugger ? And what does the technical information say from the dialog after the CTD ?
I was once able to trace the CTD in "DoTrace" function. This is probably not the same CTD but it happend while opening MFD and it had something to do with a Sound system. Here is a screen shot attached:
EDIT: I suppose that the reason for the CTD was that MsgProc() returned NULL pointer for the Orbiter instead of valid MFD pointer. That's not an issue with the LTMFD now.
CTD.gif
(50.06 KB, 1280x1024 - viewed 149 times.)
«
Last Edit: April 14, 2009, 03:12:28 AM by jarmonik
»
Logged
Graham2001
Guest
Re: LunarTransferMFD
«
Reply #34 on:
April 14, 2009, 06:36:48 PM »
Quote from: jarmonik on April 14, 2009, 03:05:48 AM
This could have something to do with the sound interface. It could be some other thread that will CTD. There is nothing in the LTMFD that could do this in this point. Can you run Orbiter under debugger ? And what does the technical information say from the dialog after the CTD ?
I was once able to trace the CTD in "DoTrace" function. This is probably not the same CTD but it happend while opening MFD and it had something to do with a Sound system. Here is a screen shot attached:
EDIT: I suppose that the reason for the CTD was that MsgProc() returned NULL pointer for the Orbiter instead of valid MFD pointer. That's not an issue with the LTMFD now.
I don't think I have the right software to run it under debugger, I was using the latest (Alpha 4) version for the flight I've just reported. I'm going to disable orbiter sound and see what happens.
Logged
jarmonik
Full Member
Posts: 130
Re: LunarTransferMFD
«
Reply #35 on:
April 14, 2009, 11:13:03 PM »
You could try to run it in clean installation of Orbiter without any other addons. With default DeltaGlider for an example.
Logged
jarmonik
Full Member
Posts: 130
Re: LunarTransferMFD
«
Reply #36 on:
April 15, 2009, 10:41:52 AM »
Quote from: Graham2001 on April 14, 2009, 06:36:48 PM
I don't think I have the right software to run it under debugger...
In order to do so you need at least MS Visual C++ 2005 Express or MS Visual C++ 2008 Express, they are both available for free from the internet. But I suppose it's pretty big download.
Logged
jarmonik
Full Member
Posts: 130
Re: LunarTransferMFD
«
Reply #37 on:
April 25, 2009, 05:29:34 AM »
Ok, I have fixed the IPC issue form LTMFD and IMFD. When PAMFD is requesting burn data, MFD that has been last, previously, used will reply to request. When any button is pressed from MFD, focus will change to that one. This doesn't require any modifications to IPC interface.
I also founded a bug that could have caused the CTD that we have been talking about. CTD would happen if PAMFD is allready requesting data while opening LTMFD.
I'll still need to implement few things before uploading final betas and start working a manual for LTMFD. I tried to implement the advanced features of lunar orbit insertion (PeA, LPe) but things didn't worked out as easily as I hoped. Also implementation of plane change during LOI would require more information about the goal of the plane change. (i.e. what should be archived with it). One possibility is that I would simply add dVp (Plane change delta velocity) parameter to LOI program so that it would be user decision of how much of plane change velocity will be applied.
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
Posts: 3687
nassp.sf.net
Re: LunarTransferMFD
«
Reply #38 on:
April 25, 2009, 01:44:28 PM »
Great news, I'm very happy that we don't need to change the interface (and AMSO/Alain, too) as I'm still busy with the new pad loads, thanks for your efforts!
Cheers
Tschachim
Logged
Graham2001
Guest
Re: LunarTransferMFD
«
Reply #39 on:
April 25, 2009, 07:27:45 PM »
Quote from: jarmonik on April 25, 2009, 05:29:34 AM
I also founded a bug that could have caused the CTD that we have been talking about. CTD would happen if PAMFD is allready requesting data while opening LTMFD.
I look forward to testing out the latest version when available to see if it does cure the problem.
Graham
Logged
jarmonik
Full Member
Posts: 130
Re: LunarTransferMFD
«
Reply #40 on:
May 03, 2009, 11:59:08 AM »
OK, I have finished and uploaded the release candidate of IMFD 5.2 and LTMFD 1.0. There are still many features unfinished in LTMFD but I don't know how much time I have during the summer, therefore, I'll try to release it with the current features A.S.A.P.
This release doesn't have a manual yet but I am working on it.
LTMFD:
http://koti.mbnet.fi/jarmonik/LTMFD10.zip
IMFD:
http://koti.mbnet.fi/jarmonik/IMFD52.zip
EDIT: BTW, I was thinking of removing P30Comp mode 2 from the IMFD. Is there any versions of NASSP those would actually need it ?
«
Last Edit: May 03, 2009, 12:02:52 PM by jarmonik
»
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
Posts: 3687
nassp.sf.net
Re: LunarTransferMFD
«
Reply #41 on:
May 06, 2009, 06:25:05 PM »
Quote from: jarmonik on May 03, 2009, 11:59:08 AM
EDIT: BTW, I was thinking of removing P30Comp mode 2 from the IMFD. Is there any versions of NASSP those would actually need it ?
As far as I understand it, no, as the latest beta already contains your patch?
Testing the new versions...
EDIT:
Mini-Bug LTMFD LOI program: In Pri = ApAlt, if I set ApA to 0, it displays -1.7381M (altitude / distance mismatch?)
Question: Would it be possible that I enter the landing site, too, and the LOI program tries to optimize the landig site alignment, too (as far as possible)?
Cheers
Tschachim
«
Last Edit: May 07, 2009, 12:19:35 PM by Tschachim
»
Logged
bluespace88
Project Team Member
Full Member
Posts: 241
Re: LunarTransferMFD
«
Reply #42 on:
May 08, 2009, 08:40:32 AM »
For the landing site, just change the mod from heading to surface, and then change the new target function to a landing site.
Logged
Graham2001
Guest
Re: LunarTransferMFD
«
Reply #43 on:
May 08, 2009, 11:23:25 AM »
I've just tried out the DG_TEI scenario and got the same result as before, CTD shortly after the MFD is selected. I'm wondering if my older model machine is not powerful enough to handle the calculations
.
Attached is the debugging log from the test run.
IFP-SDK_Err.html
(0 KB - downloaded 80 times.)
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
Posts: 3687
nassp.sf.net
Re: LunarTransferMFD
«
Reply #44 on:
May 08, 2009, 12:45:12 PM »
Quote from: BlueDragon8144 on May 08, 2009, 08:40:32 AM
For the landing site, just change the mod from heading to surface, and then change the new target function to a landing site.
Yes, in the TLI program, but in the LOI program I only see mod = simple?
Logged
Pages:
1
2
[
3
]
4
« previous
next »
Jump to:
Please select a destination:
-----------------------------
Meadville Space Center
-----------------------------
=> NEW MEMBER REGISTRATION
=> Site News
=> Project News
=> Orbiter
=> Off Topic
=> Rob Conley's Blog
-----------------------------
Project Apollo - NASSP
-----------------------------
=> Project Apollo - NASSP News & Discussion
===> News & Announcements
===> Support & Bugs
=> Project Apollo - NASSP Development
===> Planning
===> Programming
===> Modeling
===> Sounds
-----------------------------
Project Mercury
-----------------------------
=> Discussion & Help
=> Development
===> Planning
===> Programming
=> Mecury Mission Control
-----------------------------
Project Gemini
-----------------------------
=> Discussion & Help
=> Development
===> Programming
===> Modelling
===> Sounds
===> Planning
-----------------------------
Orbiter Mars Direct
-----------------------------
=> Planning
===> General News
=> Development
===> Programming
===> Modelling
===> Sounds
-----------------------------
General Projects
-----------------------------
=> The After Columbia Project
===> Sprint
===> Greenstar
===> Cyanstar
===> Bluestar
===> Mars Challenger
-----------------------------
Sol 2018
-----------------------------
=> Planning
Loading...