Project XR Rolling Repair

Thanks Xyon, I am sure you will find the right antidotes for these problems,and I like the idea of the scissor lift, some tools would be cool for the Eva to grab,or even a tool box full of a couple tools,anyway I'll shut up for now,oh Btw I am using the latest Xr fleet. When you use the ext mfd do you open it up in the Xrs cockpit?and do you have to use the corner pin option ?maybe, I am not using it right.keep up the great work,and thanks for your time and effort.

Can you provide a screenshot of the ExtMFD with the error message in it? I haven't tested that solution extensively, so there might be some obscurities I'm missing while running code in it.
 
Can you provide a screenshot of the ExtMFD with the error message in it? I haven't tested that solution extensively, so there might be some obscurities I'm missing while running code in it.
Hi, Xyon I am away from home for a few days,but I will take a screen shot for you Asap.thanks
 
Hi Xyon, I am home at my computer,and the ext mfd seems to work again,after fooling with the XR rolling repair mfd buttons a little.Thanks
 
Arrgh, so close. Anyone suggest a way to share a hash_map object between classes? The way I'm trying to do it isn't working properly...

---------- Post added 13-01-12 at 00:47 ---------- Previous post was 12-01-12 at 03:01 ----------

This is starting to do my nut in.

I tried to reorganise the structure of the projects in which XRRR is built to consolidate the MFD and the plugin into one module. OrbiterSound indicates it can be done (a plugin and an MFD all in one) but I'm running into a roadblock thus:

Code:
1>UMmuSDK.lib(ActionArea.obj) : error LNK2005: "public: virtual bool __thiscall MFD::ConsumeKeyImmediate(char *)" (?ConsumeKeyImmediate@MFD@@UAE_NPAD@Z) already defined in orbiter.lib(Orbiter.exe)
1>UMmuSDK.lib(ActionArea.obj) : error LNK2005: "public: virtual void __thiscall MFD::WriteStatus(void *)const " (?WriteStatus@MFD@@UBEXPAX@Z) already defined in orbiter.lib(Orbiter.exe)
1>UMmuSDK.lib(ActionArea.obj) : error LNK2005: "public: virtual void __thiscall MFD::ReadStatus(void *)" (?ReadStatus@MFD@@UAEXPAX@Z) already defined in orbiter.lib(Orbiter.exe)
1>UMmuSDK.lib(UMmuSDK.obj) : error LNK2005: "public: virtual bool __thiscall MFD::ConsumeKeyImmediate(char *)" (?ConsumeKeyImmediate@MFD@@UAE_NPAD@Z) already defined in orbiter.lib(Orbiter.exe)
1>UMmuSDK.lib(UMmuSDK.obj) : error LNK2005: "public: virtual void __thiscall MFD::WriteStatus(void *)const " (?WriteStatus@MFD@@UBEXPAX@Z) already defined in orbiter.lib(Orbiter.exe)
1>UMmuSDK.lib(UMmuSDK.obj) : error LNK2005: "public: virtual void __thiscall MFD::ReadStatus(void *)" (?ReadStatus@MFD@@UAEXPAX@Z) already defined in orbiter.lib(Orbiter.exe)
1>UMmuSDK.lib(universal_mmu.obj) : error LNK2005: "public: virtual bool __thiscall MFD::ConsumeKeyImmediate(char *)" (?ConsumeKeyImmediate@MFD@@UAE_NPAD@Z) already defined in orbiter.lib(Orbiter.exe)
1>UMmuSDK.lib(universal_mmu.obj) : error LNK2005: "public: virtual void __thiscall MFD::WriteStatus(void *)const " (?WriteStatus@MFD@@UBEXPAX@Z) already defined in orbiter.lib(Orbiter.exe)
1>UMmuSDK.lib(universal_mmu.obj) : error LNK2005: "public: virtual void __thiscall MFD::ReadStatus(void *)" (?ReadStatus@MFD@@UAEXPAX@Z) already defined in orbiter.lib(Orbiter.exe)

XRRR's MFD derives from MFD2 rather than MFD, and only uses Read and Write status, but not consumekeyimmediate, so I don't think it's anything to do with my MFD. Both MFD and plugin have always shared a header file and always imported UMmuSDK.lib before; it's only when they're together in the one module that I have this issue.

Any clues?
 
I have DBeachy1 to thank for the latest commits to indev this week. He's provided a lot of advice on alternative ways to do what I'm trying to do (specifically linking the two dlls together to share the hash map between them; and lest I forget the use of a hash map was his suggestion in the first place) which has pushed the project forward around the roadblock above.

The latest commits will remove and rename some files. If you're checking out the latest sources, you'll need to enable the modules under their new, shorter names in the launchpad. I don't recommend pulling the zipped snapshots, because cloning will take care of all the renames and removes, which the zipped packages won't. So you'll wind up with a lot of scrap files unless you delete all XRRR files first and then unpack.

Part of the change is two additional stub headers which allows the MFD and the plugin to keep some stuff separate from each other; necessary for the exporting and such, I've found. The cpp files should no longer directly include the shared header as it is included by the non-shared stubs.

This version does not draw any dots in the MFD REP page. Part of the changes I'm making are a more efficient way to draw them (resulting in less code per update), which I haven't written yet. It should, however, eliminate the CTD from the previous indev commit. That was caused by my previous linking attempt which didn't capture the return value from the helper function properly. Or catch the exception. Never mind.

This commit does not increment the external version count; internal count is 1.4.2-n160112, external is 0.8alpha7.

---------- Post added at 13:54 ---------- Previous post was at 13:37 ----------

Oh. And I've updated the first post with some clearer download instructions.
 
I've spent some time working on a little flesh for XRRR's bitbucket-hosted wiki; You can view the results here. It gives a little insight into what XRRR can, can't, and can currently do.

Additionally, indev's last commit fixes a bug I created by using LoadLibrary without then cleaning up with FreeLibrary in the MFD's source; That caused a problem on exit when the reference count to XRRR.dll wasn't zero, so the module wasn't unloaded after Orbiter was done with it.

The MFD map implementation works, but I forgot that after I changed the maps to the better-quality versions, the pixel coordinates I had became invalid. So I've stopped adding those old ones in and will need eventually to grab new coordinates off the maps as they currently are. Pain in the backside.
 
Development update:

So, there's a few new commits in bitbucket this week, and they totally break apart XRRR.cpp.

I've wanted to organise the code better for some time now, and this last few commits to indev have ripped the monolithic single-document code apart in favour of smaller, modular pieces to make my life easier and also hopefully make the code a little easier to read and dissemenate.

My thanks to Face for halping me with some global variable issues I should've been able to resolve, but couldn't, and got me stuck in linker errors - thanks to Face's input I got my mind unmuddled on statics and externs again, so thank you for that, Face.

The next thing is that XRRR now includes SQLite statically linked in (for compatibility purposes, or something, I just prefer not distributing half-a-dozen dlls to make one work) because eventually my plan is to make the static vessel data read in from a flat-file database which is in SQLite. Reasons for picking this way are simple; it will allow coordinate changes without rebuilds, I can link it statically so it works seamlessly, I can push it all into a flat file, and I already know SQL syntax so I'm not starting from scratch. With the right tool the database is end-user modifiable - if you disagree with me on where a point should be, you can move it - and if you decide you liked my positioning better, you can revert it.

The database will also hold the pixel coordinates for the MFD map. All this data at the moment is hardcoded and loaded on initialise, my only difference will be the source. I'd like to still read it all into memory and work on it from there, as it saves expensive I/O while running and less scribbling to disk is better for your hard drives (though if you're paging to disk that's really a moot point, get more RAM).

At the moment Database.cpp just holds a bare-bones load the database up and panic if it doesn't work. And yeah, don't move the sample database in /Config. I may add a configure option for the database path if you'd rather it was somewhere else.

Finally, I fixed a rather unpleasant bug which caused a CTD on load in some circumstances.

The newest version is in the indev branch on bitbucket. Instructions in the OP.
 
Ok - I've got a memory leak, and it's got me stumped.

As part of XRRR's initialisation, I create and register two launchpad elements and a custom command (for the configuration dialogue) in InitModule - as seen here). These three objects are subsequently unregistered and then deleted in ExitModule (source here).

The problem is, that the objects disappear as soon as the launchpad appears. My pointers become null (0x0000000) and thus the unregister and delete both fail, causing the memory to leak my pretty dialogues instead. I've followed it through the debugger, but I'm still not sure at exactly what point the objects cease to be valid - I do know that it happens before the launchpad is loaded, partly because my DialogBox call fails due to the window handle also being null.

I'm also not certain when this started, but my only suspicion is that perhaps it's failing to pass those objects properly through the different object files in the DLL - because I split the source up (this has literally occurred to me in the last 30 seconds). They are static, though, so I'm not sure why that would be the case.

Anybody any thoughts? C++ coders? Martin? I'm lost in invalid memory here...

---------- Post added at 23:31 ---------- Previous post was at 10:05 ----------

my only suspicion is that perhaps it's failing to pass those objects properly through the different object files in the DLL - because I split the source up (this has literally occurred to me in the last 30 seconds).

Oh hey, that's what it was, too. Something about the structure, it just does NOT want to share data across itself.

Eh well. Bugfix commit is up, memory leak is Fixxor.
 
This looks awesome, but I've been lazy with reading the thread. ;)

How far along is this project?

About 60-75%, depending on which files I choose to ignore when I'm in my denial phase.

I've a lot of tedious coding to do which I'm procrastinating (constantly) about, including the MFD maps (which I'm still writing an SQLite workaround for, as with the vessel data, but I need to pull in pixel coordinates for still). I'm putting off doing these things partly legitimately since I'm busy working and having a new baby, but also because tedium. Waaa.

There's a list of things I want to complete before I notch the numbers up to 0.8, and I'm putting most of them off as above, so right now it's 0.7.9d or e, something like that. You can check it out of bitbucket right now if you please, but it's somewhat not-finished.
 
Sweet, well good luck with the baby and the procrastination mate.

And I'm sure I can find some time in the near future to test out breaking... er repairing... a few vessels...:)
 
Sweet, well good luck with the baby and the procrastination mate.

And I'm sure I can find some time in the near future to test out breaking... er repairing... a few vessels...:)

Given the memory leak (and root-cause bug which completely broke the dialogues for configuration) I've just fixed I'd relish some tester feedback, actually. It'd be nice to get the full picture on how the whole works rather than the small pieces my developmental testing hits.

---------- Post added 10-07-12 at 19:53 ---------- Previous post was 09-07-12 at 23:00 ----------

The guru that is dbeachy1 has kindly explained to me what was causing my memory leak - apparently static, in the context I was using it, didn't mean what I thought it'd mean when I tried to use it.

So I have a more elegant solution for sharing those parameters across the DLL object files now. Thanks Doug!
 
Good to hear, WHAP. If you find any bugs, I have an internal issue tracker here - the affected version is 0.8 for the moment.
 
My first issue seems to be that the Configuration option in the Extras tab doesn't open. When I double click the 'Configuration and Settings' entry it just does nothing. Both modules are activated. Am I misreading the docu and this is not 'in' yet?

edit: you may have to forgive my stupidity, but I'm clearly missing a trick here. I'm trying to test the basic XR1 scenario with the destroyed ailerons, but when doing the EVA I just get "no action area within 15km" message... I have, I think, selected the relevant broken area in the MFD, but can't seem to fix this baby.
 
Last edited:
The settings dialog not showing up was due to a bug which should be (IIRC) fixed in the last commit - but I'll check my own copy and see, because it's newer.

That version uses SQLite to load vessel data but the implementation is only complete for the XR1 (I haven't finished porting the hardcoded data to the database for the 2 and 5).

For the purposes of testing, I'll revert the call to the older CreateReference function so that the vessels should again load properly - in truth, it shouldn't have committed with only half the implementation, I had changed the call to CreateRefFromDatabase for debug and forgot to change it before committing.

Bear with me.

---------- Post added at 14:31 ---------- Previous post was at 14:25 ----------

OK, commit f562d42c069c is my latest development, and I've switched the call around like I said above.
 
XR2 data is now ported to the SQLite database along with the XR1 data. Now just the XR5 data and the MFD maps to go in.

I've been thinking about storing additional particle effect data (for the pyrotechnics) in the database as well, but I may shelve that feature, and debris, until version 2 now. I'd like to actually release this at some point.
 
Hi there!

In regards to the settings for this add-on, will there be any other parameters than the 'difficulty'?.

For example, say that X amount of things are able to go wrong whilst leaving earth, X amount when orbiting and in space, and X amount on the moon?

Kind Regards,
NT
 
Back
Top