Project XR Rolling Repair

[Grover]

not if youre in space and theres no oxygen to fuel the flame that did the charring. and if there is because your LOX tanks blew, then theres no point for two reasons
A) the explosion would rip the ship to pieces, so you wouldnt be alive to see it
b)if the lox tanks blow you suffocate anyway

 

[hribek]

Can we have a cheaty "total vehicle rebuild" button somewhere in the XRRR plugin? (maybe in the difficulty settings dialog) I think it would be better than saving, altering and reloading the scenario.

 

[Lucy]

Indeed, my original mock-ups for the in-flight dialogue had such a button present, but the button never made it to the current build because the message window template is re-used between the launchpad and Orbiter, and "repair all damage" wouldn't make much sense from the launchpad.

I will add it when I remember, and have it greyed out while you're not in an Orbiter simulation session.

 

[Lucy]

Wow, it's been a while since I posted anything here.

Sadly, I've not actually been doing that much with the code, but I've done enough work to warrant another test version. Some subtle changes to the MFD maps (Better pictures, all of them aligned for consistency) have created improvement, but they've also broken the locations of the indicators, so I'll need to go back through them and change them to fit properly. I've done a few, but it's exceedingly tedious, and I'll probably put that off until after I've moved house.

Also new are controls for the new debris feature (which is almost identical to 0.7.4, I've changed almost nothing there), and the requested "Repair All" button as per the above (You need the vessel you want to fix in focus at the time - I may later add a dropbox for vessel selection to the dialogue box to change that). I'm not entirely convinced that all the action areas are deleted after that's pressed, but they should be, so I'd like a little testing around that feature too.

Finally, a bug fix from the previous version means that the XRRollingRepairPreferences.cfg file is now being properly used - you may have a scrap file with no extension in your Config folder as well which calls itself XR Rolling Repair Preferences or something similar - delete it, it's useless. I've also changed my mind about how I'm going to handle debris, so if you have an XRRRDebris.dll file in your Modules directory, you can delete that too, it's also defunct now.

As always, test in a clean install if you can, but I'm still interested to see if it plays nicely with other addons. All the files it installs can be removed from your installation if it becomes necessary, but I'd suggest either making a backup or testing it in a fresh copy of Orbiter with a few addons installed just to see how it plays with them. At this point I know of no CTD bugs left in the addon, so if you find one, let me know.

I know the manual still says 0.7.4, but nothing's changed in there, so I'll leave changing that til 0.8.

http://dl.dropbox.com/u/14693382/Orbiter Mods/XRRR/XR Rolling Repair 0.7.6.zip

As I said, I'm in the process of moving house, so free time to develop has been and will continue to be in short supply while real life takes priority. I will eventually come back to it now and then, but I don't expect my pace to pick up for the next month or two at least.

 

[ProAuroraX]

Hi i downloaded this addon but everytime i load a scenario orbiter ctd i use windows 7

 

[Lucy]

Sorry I missed that. I'm not in the habit of checking this thread much. *headslap*

If you're still able to, can you provide the scenario you were running, and an Orbiter.log file from running (and crashing) the scenario? It probably won't reveal much, but it'll give me a starting point.

In other news, moving house broke everything. I got all my stuff together and worked out my new server / workstation configuration, restored my backups, etc, etc - all the code is the same version, the module is linked as it always has been, but now, the thing doesn't seem to work at all properly - even long-sorted features like actually fixing systems with action areas.

This is a major step back, and it's going to take a while to find the root cause and fix it, I think. Thus yet again, 0.8 will be delayed until it's all working properly.

I suppose it's better to make sure there's no showstopping bugs in it now than just release a beta and let everyone test it, right? Right?

Truly, I'm sorry for the wait though. This project was never actually supposed to take this long, it's just that real life gets in the way sometimes. I'm back developing when I have time, so it shouldn't be too much longer to 1.0.

---------- Post added at 09:00 ---------- Previous post was at 08:41 ----------

Update:

I know I only posted two seconds ago, but I'm having one of those thoughts that I get random inspiration for... one of my many whims.

I'm considering opening the source for XRRR. Reasons for this include demonstrating how to poke the XR's API, and to show people how I've implemented things in case they're wondering how to make a launchpad element, or a dialogue box for Orbiter, etc, etc.

The other side of it is that others may be then able to look at my code and point out where I could be more efficient, or how to do things in a better way. I'm open to suggestion for improvement, and contributors would be credited in the final release should it happen.

There's a part of me that would prefer, however, to wait until release (1.0) to do this, to protect the effort and time invested thus far.

Thoughts?

 

[Wishbone]

I have opened the source for all my add-ons so far, of course they are not as bright as yours, but I haven't seen any shred of evidence someone has actually read a line. If you're hoping someone would read your code, be prepared for disappointment. I do read other people's code (mostly it is related to automatic control, ballistics, or geometry), but only to get the algorithms I'm too dumb to invent. Looking for errors requires determination, knowledge of the maths and physics behind the code, and willingness to set up and compile a test suite. All of this occurs only rarely.

 

[Lucy]

Part of the concept as it appeals to me is remembering how hard it was to find solid examples of writing MFD modules and so on. Vessel plugins are well-documented, but less so plugin and MFD modules. XRRR uses a plugin, MFD, launchpad item, custom menu entry, and interfaces with a vessel object through the XR API.

For those interested in how to do such things, it might be worth a look.

 

[Lucy]

The link in the first post has been updated to point to the newest beta - 0.7.8c.

No, it isn't 0.8 yet - too much is still unfinished for that. This is a bugfix and method change release, tidying up from the combination of errors and new bugs I've noticed, as well as some new solutions to old ones and performance improvements.

Full changelog:

Version 0.7.8c (b110906):
• Bugfix: Incorrect sequencing code causing systems to delete other systems’ action areas.
• Bugfix: Incorrect creation behaviour for Action Areas.
• Bugfix: Heap corruption (Causing break in Orbiter.exe / CTD) from old code – removed.
• Bugfix: Invalid data in structure used for dialog components.
• Bugfix: Unexpected Orbiter shutdown behaviour corrected.
• Bugfix: Miscellaneous performance update in MFD code.
• Bugfix / Bug tracking: Heap corruption from UMMU (Visible in Performance Stress Test 1)
• Method change re: MFD dots – incomplete.
• Method change re: Vehicle status page – incomplete.
• Scope widened. Again.
• Beacons added – unfinished reference implementation.
• Alteration to Configuration Dialog box – better, cleaner layout.
• Tweaking to the Action Area maps – point size etc.
• Sifted scenario list and removed superfluous old ones.
• Added new Performance Test scenario (Bugged, see tracking entry above).
• Refactored and streamlined the way in which particles will be created (Still unfinished).

Usual testing stuff applies - please break it, then tell me how you broke it. I am aware of a bug with UMMU which is causing CTDs - this is some heap corruption noticeable from the Performance Test 1 scenario (There are 12 XR vessels in there at once, though, so it's a little unrealistic for normal operations) which I'm contacting DanSteph about to see if we can pin it down - though I think this might not be helping:



Whoops...

 

[Lucy]

I'd recommend you watch in HD on YouTube itself.

 

[Lucy]

I figured out quite quickly that a combobox isn't the best thing to list files into. Better this way;

The usual "Browse" button magic.

 

[Bonanza123d]

XRRR Beta 0.8 Development - Part I - YouTube

I'd recommend you watch in HD on YouTube itself.

Somewhere your code is bugged. Did you get it resolved yet?

 

[Lucy]

Several portions of my code are bugged; it's still beta software, after all.

Which part are you referring to, specifically? I can't actually answer you without knowing which bug you wanted splatting.

---------- Post added at 17:31 ---------- Previous post was at 15:56 ----------

Ooh, by the way, this works properly(ish) now too; Parse the selected scenario file and pick out every XR vessel in it.

---------- Post added at 22:11 ---------- Previous post was at 17:31 ----------

Last picture from today - the finished dialog, both in and out of simulation:

Next up - implement the schedules to make stuff break!

 

[dbeachy1]

Great work, mate!! I'm looking forward to this!

 

[ProAuroraX]

Hi i got 7.8 to work and when i press Enter to activate the action area, which button do i press to fix the damage?

 

[Lucy]

All the controls should be noted for reference in the included documentation (it extracts to Doc/). If a key isn't there, let me know and I'll make sure to update it for the next version.

If, however, the key listed doesn't generate the expected result, then that's a bug. Please mention that to me to so I can make sure not to include it in the next version.

 

[ProAuroraX]

All the controls should be noted for reference in the included documentation (it extracts to Doc/). If a key isn't there, let me know and I'll make sure to update it for the next version.

If, however, the key listed doesn't generate the expected result, then that's a bug. Please mention that to me to so I can make sure not to include it in the next version.

Nope only keys i see in the doc are the CTRL F4 keys. and where it says to press Return/Enter

 

[Lucy]

I've looked over what the documentation says and I admit it perhaps expects users to know how to use UMMU action areas already, so I will alter the passage to be more explicit.

However, you say you're pressing Return while inside action areas and it isn't fixing damage? If so, this might be a bug (or you might be somewhere within a sequence), so to track that down I'll need to know the contents of Config/XRRollingRepairPreferences.cfg, and also what scenario you're running and exactly what you do in the scenario each time to produce the bug. If I can replicate it here, I can fix it.

 

[Wishbone]

Would suggest writing strings to Orbiter.log when user input is recorded.

 

[Lucy]

It would perhaps help, but in terms of a bug report I still need replication instructions to have any chance of finding out what happened. I can record some things, but scribbling to orbiter.log every keypress would result in a LOT of hard drive access for any given length of session - probably easier on the hard drive and performance if I just ask people to tell me what they did, no?