Project XR Rolling Repair

It is amazing how helpful this logging feature is... The key is, since you're in beta phase, you need lots of telemetry, just like in real space applications. Logged strings are flushed instantly, this may be a shortcoming often; yet very useful when something CTDs.
 
Hmm. It hasn't been a problem so far; those who have submitted bugs have been able to work out how to create a situation which replicates the problem every time, and passed that on to me. If it becomes something necessary, I'll look at adding it for the final beta stages.

Technically, since I'm still adding features, it's somewhat Alpha too. Never mind.

Any additional features now can wait until Version 2 (probably when the next XR vessel is released, since I'll need to expand XRRR to cope with it - it will not automatically work with new vessels).
 
Ok, I see you've got all three unfinished "effects" enabled in the config. While that shouldn't cause a CTD, it's probably better to leave them disabled until they're finished.

At what point did the crash occur? On load? Or did you do something with the XR2 which caused it (like activate an action area)?
 
I've been fiddling.

While this statement raises all sorts of connotations, what it actually means is that the source code and binaries for XRRR are now available via bitbucket in a mercurial repository.

If you don't have mercurial, don't know what it is, or yadda yadda et cetera, fear not. Just go to https://bitbucket.org/Xyon/xrrr/downloads and download the "default" branch in your preferred compression format. I'm not apparently able to prevent bitbucket from compressing it inside a folder within the archive, so you'll have to pull it out of there, and push it into an Orbiter install.

For those of you inclined to use mercurial, do this;

Code:
hg clone https://bitbucket.org/Xyon/xrrr <location>
to clone the latest revision into the specified location.

You'll get binaries in the right folders to run XRRR and source code within the orbitersdk/XyLabs folders. There's enough there to compile your own version with VS2010.
 
It seems I can never get to download this beta :( Are there any other alternate links/mirrors? Thanks!

-RODION
Hmmm... why you can't?
I can not see how anyone can have a problem with the web-
interface to bitbucket...
If you can download this link, you should be able to download any revision there.
Maybe you just didn't saw the (small) download links...(they are called either 'zip' or 'gz' or 'bz2', depending on the format you like to download)
/Kuddel
 
Yeah, I admit the download links there aren't the most obvious in the world, but they're there. Those files are the default branch snapshots.

When I get chance to code again I'll be opening an indev branch, which will have more frequent updates, but whose only requirement is that it compiles. Currently "default" must compile and run in Orbiter (at least initialisation), so you can be sure it'll at least load and scream into its logfile as it dies.

This is really the first time I've bothered to use version control for anything, but I can see the benefits it can bring. For those who hate it with a passion or aren't interested in source code the dropbox links willstill work for new versions, and won't contain the source.

---------- Post added at 15:46 ---------- Previous post was at 15:46 ----------

Yeah, I admit the download links there aren't the most obvious in the world, but they're there. Those files are the default branch snapshots.

When I get chance to code again I'll be opening an indev branch, which will have more frequent updates, but whose only requirement is that it compiles. Currently "default" must compile and run in Orbiter (at least initialisation), so you can be sure it'll at least load and scream into its logfile as it dies.

This is really the first time I've bothered to use version control for anything, but I can see the benefits it can bring. For those who hate it with a passion or aren't interested in source code the dropbox links willstill work for new versions, and won't contain the source.
 
Hmmm... why you can't?
I can not see how anyone can have a problem with the web-
interface to bitbucket...
If you can download this link, you should be able to download any revision there.
Maybe you just didn't saw the (small) download links...(they are called either 'zip' or 'gz' or 'bz2', depending on the format you like to download)
/Kuddel

Thanks, I'm trying your link (though it seems similar to the link I've been trying before)...previously, I could get the download to start but it would stop halfway or 2/3rds of the way...well, I'm sorry, I live in the place with the worst possible internet connection (worse than dial up probably) :( Things might hopefully change in a month or two though.

-RODION
 
Thanks, I'm trying your link (though it seems similar to the link I've been trying before)...previously, I could get the download to start but it would stop halfway or 2/3rds of the way...well, I'm sorry, I live in the place with the worst possible internet connection (worse than dial up probably) :( Things might hopefully change in a month or two though.

-RODION

In that case I'd recommend the mercurial clone. Instead of one larger file, it's several smaller files, which means if your connection gets disrupted mid-transaction you don't just have to restart the whole thing again.
 
In that case I'd recommend the mercurial clone. Instead of one larger file, it's several smaller files, which means if your connection gets disrupted mid-transaction you don't just have to restart the whole thing again.

No need--my 'net connection seems stable today and I was able to get it using the link that kuddel provided :D Thanks again for the suggestions!

-RODION
 
Yay!

In other news, the indev branch is open for business too. I should point out that, because I wasn't thinking about what I committed to default, currently the modules in your Orbiter folder will be debug modules, rather than release ones. Because of this line:

Code:
#ifdef _DEBUG
	_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_CHECK_CRT_DF | _CRTDBG_LEAK_CHECK_DF | _CRTDBG_CHECK_ALWAYS_DF);
#endif

they'll be performing a lot of memory tests which are probably unnecessary. For now, you can either compile a Release module by switching your compiler to "Release" mode and hitting build (Not sure that'll work out of the box because, well, I haven't checked), or wait ten minutes for me to push a Release version up.

---------- Post added at 23:55 ---------- Previous post was at 23:21 ----------

OK;

Default and the somewhat confusingly closed indev (I'll clean that up in a while) are now identical versions, and both are here or via hg. Important to note is this: There are two property files you need to edit to build the projects. Both are called orbiterroot.props and they reside within XRRR and XRRRMFD. Just change the paths in there, pointing the OrbiterDir macro to your Orbiter directory and your RepoPath to wherever you cloned the repository to. This inheritance of properties should make all the include and library paths work OK provided you specify the correct path (And the debugger should work OK too). It's the easiest way I can see to make the code compile without a ridiculous relative path string in there somewhere.

In truth right now, I haven't developed anything yet, but that will change at some point and I will be forking into indev to do that. I recommend people to grab the default branch unless they're particularly interested in the in-development version, which I've mentioned may CTD Orbiter and other interesting oddities may occur with it.
 
The XR1 has taken up smoking.

smoking.png


That represents about as far as I've got with particle streams; they're something of a headache to work with IMO. Thanks to Doug for pointing me in the right direction and they do at least work and differentiate OK thus far - no, that isn't their final appearance. I'm just giving up tweaking.

On another note, bitbucket plugs into my twitter thingy and apparently makes a noise like a bird whenever I push changesets to the online repo. Fascinating.
 
Great work, mate!! :thumbup: MOAR!
 
Moar? Well, the XR2 and XR5 have also taken up some smoking too; Though the stream effects need some fine-tuning.

https://bitbucket.org/Xyon/xrrr/get/default.zip is the latest indev version and default version - I'm happy that these changes are stable now that I've fixed all the CTDs I first got. This includes a major refactoring to the way the action areas are defined which should save a (comparative) lot of memory, and a much better framework for me to add in the remaining particle effects with. I just need to work out how the hell to get the additional effects I want in there beyond huge, thick clouds of smoke...

oopscram.png


xr1moustache.png


xr2smoking.png


Meanwhile, in the D3D9 client...
meanwhiled3d9.png


Enjoy! The MFD will call this version 0.8, but I'm personally tagging it as some ridiculous extension of 0.7.999999999999 et cetera. It's essentially an alpha version of the beta version I'm wanting to put out as 0.8 - features are mostly in, but almost none are finished.
 
Last edited:
Great work, mate!! :tiphat:
 
Great work, mate!! :tiphat:

Hi Xyon on your test scenarios Xr2 You can't get close enough on the ground
to the rear alerions to repair them unless you use UcargoDeck to lift the Tech Eva up to the damaged alerion,also I have only been able to use the ext mfd one time,all the other times it says that the XR2 API is not compatible,or something to the like of it.thanks for this great. Addon it adds a brand new dimmension to orbiter.
 
Hi Xyon on your test scenarios Xr2 You can't get close enough on the ground
to the rear alerions to repair them unless you use UcargoDeck to lift the Tech Eva up to the damaged alerion

This is true. The reason for it is that, if the action areas are in the correct location and of a reasonable size for it to work in space, you can't reach the system from the ground. This is notable with a few XR1, 2 and most of the XR5's systems because of the landed height of the vessel.

Originally I thought about moving the point lower when the vessel is on the ground, but I'm not sure it'd work out entirely logical as for it to be reachable from the ground you'd be activating empty space beneath the vessel instead of the system you're actually trying to activate.

I may work something out with a taller UMMu or some kind of scissor lift (image: http://www.lift-equipment-parts.com/parts/images/gs.jpg) but the trouble is I'm not a modeller, I'm a programmer, so that could pose a problem. I suppose the other alternative is to wrap the "lower the action areas when the vessel is landed" concept into an optional feature and leave it at the users' discretion...

also I have only been able to use the ext mfd one time,all the other times it says that the XR2 API is not compatible,or something to the like of it.thanks for this great. Addon it adds a brand new dimmension to orbiter.

You shouldn't be getting that message; It means your XR fleet is not of the right version. I recommend downloading the newest version of the fleet from Doug's pages (it pays to keep updated anyway). XRRR is compiled against the most recent version of the API at time of release; That means you currently need to download the versions specified in the manual included with XRRR.
 
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.
 
Back
Top