Orbiter beta SVN repository

[massimob]

Also for me.

Another, I can't browse repository folders (Orbiter).

Bye.

 

[martins]

It should be working again now. Can you please try again?

 

[orb]

Browsing the repository in web browser is working fine for me.

Also trying to update (with "svn up") doesn't bring any error, and tells me I'm in revision 12 (and "svn log" lists all the changes too). :shrug:


EDIT: :ninja:'ed by martins. It was fixed.

 

[Face]

Also trying to update (with "svn up") doesn't bring any error, and tells me I'm in revision 12 (and "svn log" lists all the changes too).

Now it is working again here, too. I can confirm that there is no new revision beyond 12 (2012-12-04 02:24:32 "Auto-detection of Linux/WINE environment...").

 

[Ripley]

Working again confirmed. Thanks.

 

[kuddel]

Yes. I meant the "update" command in that context. It is not possible to simply update the Orbiter beta installation in which you pre-test your add-on, if you also use Subversion there for the add-on.

Hi Urwumpe, et al.,

you can also use a combination of 'sparse checkout' and 'symbolic links':

In my example let's assume your project is 'SSU'. I will do everything direct at "D:\" which might not be what you do, but it keeps the example instuctions simple.

1. Checkout Orbiter trunk as 'sparse checkout'
   Do this by checking out in a folder (here: "D:\Orbiter") and select the repository root (NOT down to trunk!).
   Then select "Choose items..." and only select "trunk" there. You can of course select the others ("branches" and "tags") too, but that's not needed.
   The checkout dialog should look like [image_1] now.
   Note that the Repository URL is the repositories base-path (without "trunk") while the Checkout Depth indicates that we selected only some of the children (only "trunk") as we like to make a sparse checkout.
   Click O.K. to check out.
2. You should now have a Orbiter working copy that looks something like [image_3]
   Important is just, that the (hidden) .svn folder is located above "trunk" (here "D:\Orbiter\.svn")
3. Checkout your project (SSU) in a temporary directory of your choice (e.g. "C:\tmp\SSU").
4. Then create a symbolic link for your projects working copy:
   

   $> junction.exe d:\SSU d:\Orbiter\trunk

5. Now just copy or move the complete content of the temporary project checkout-directory into that new location (from c:\tmp\SSU\..." to "D:\SSU\...")
   IMPORTANT is, that the hidden Subversion folder(.svn) is also copied/moved!
6. Et voila: A combined working copy!
   The steps (3) and (5) are neccessary cause TortoiseSVN doesn't like symbolic links as checkout target. for update/commit/etc. that's fine!
7. Now you can work / develop your project under "D:\SSU\..." as usual. And when you think it's time to check for a new Orbiter beta revision, just update the according folder ("D:\Orbiter" or "D:\Orbiter\trunk" it doesn't matter here).

The trick here is, that Subversion identifies the repository via the path, and it doesn't care where those files / directories are actually located on your harddrive (all files will be physically stored in the "D:\Orbiter\trunk"
directory!).

Fortunately Subversion will handle all the SSU-Files in the Orbiter-working-copy as local unversioned files of Orbiter-working copy and all the Orbiter-Files in the SSU as local unversioned files of SSU-working copy.

The TSVNCache background task however might not be able to recognize our dirty deeds here and might display Overlay Icons at the working-copy roots that might not be accurate.
However as long as there is not a file versioned in BOTH repositories[1], this works!

/Kuddel

[1] ...as a addon-Developer you should not do that anyway!

 

[martins]

Following the callback order confusion in recent betas (and the ongoing effort to straighten it out), I've decided to provide a reference for the callbacks, as a tool for developers, and as a guideline for me to spot problems early in the future.

May I present a new page in the API reference manual:

From SVN r.15, you'll find under "Related pages | Orbiter program flow and module callback order" a flowchart for the orbiter frame update loop and vessel callback functions. It's not complete yet, and so far I've only done vessel callbacks, no MFDs, Celbodies or other modules. Once it is finished, it should be quite useful.

I guess some developers may have generated their own callback sequence graphs. Do you spot any discrepancies so far?

 

[SiameseCat]

There seems to be a problem with the order in which the callbacks run. In the latest beta, clbkPostCreation is called AFTER the first timestep (clbkPreStep and clbkPostStep have already been called once).

 

[JMW]

I've "updated my beta (version 121129) as outlined by Ripley, Orb and Kamaz previously in this thread.
Should my version now be listed as 130101 ?
I attach Tortoise log - with !'s - what are these telling me ?
Thanks.

 

[Ripley]

Yes, that's the latest Orbiter BETA version (from Launchpad -> About Orbiter).
After updating via Tortoise, it should say "Completed at revision 20".

 

[Face]

This log is not an operation log (as in "what happened during update?"), but the change-log of the repository. It details who changed what when in the repository. I could be wrong, but I think the "!" icons there simply denote that changes to files have happened in the appropriate change-set. In a similar manner the blue plus marks change-sets with additions, and the red X change-sets with deletions.

I'd suggest you read the manual of TortoiseSVN, as it is something special to this tool, not connected to Orbiter's log or executable.

 

[orb]

Should my version now be listed as 130101 ?

That's right. SVN revision 20 has the build 130101 of the Orbiter executable.

I attach Tortoise log - with !'s - what are these telling me ?

Are there any errors in the log file? I can't read it right now (why is it a DOC?). :shrug:

 

[JMW]

Thanks guys.
Orb, can't see any errors in the log (just print screened it in to Word:rofl
My orbiter.exe isn't updated to 130101, and my fonts keep altering too (have unchecked "disable font smoothing when orbiter is running" in extras.:blink::blink:

Word doc replaced with .png for Log

 

[JMW]

Seems have a conflict affecting the orbiter exe with Tortoise.
See attached.
Would appreciate any help to resolve this.
I have read the Tortoise help pages, but a lot of it is way over my knowledge.
Can you point me in the right direction please.

 

[orb]

Can you point me in the right direction please.

Did you "checkout" it into a new folder? :shrug:

 

[JMW]

No, into an existing "clean" install.......... does it need to be an empty folder???

 

[Face]

No, into an existing "clean" install.......... does it need to be an empty folder???

Yes. The idea is similar to this. The repository acts as a snapshot of a full Orbiter install as it goes through various beta versions.

If you are interested in an up-to-date snapshot ZIP of Martin's repository, you could also use the archive feature of my HG mirror of it here: http://bitbucket.org/face/orbiter/get/tip.zip .

 

[JMW]

Thanks Face - trying it now

 

[JMW]

Ok. Everything went well - I now have "version updated till 20".
Started Launchpad - ran scenario "DG-S ready for takeoff"
Stopped scenario -
Launchpad came back, but with only "Current state" with jpg - but no other scenarios !
Tried closing/re-opening Launchpad - same result. No scenarios.
Also (didn't check if there before) when go to tab "Extras" has description, but no options to click.
What's happened?????

Orbiter log:

**** Orbiter.log
Build Jan 1 2013 [v.130101]
Timer precision: 2.79365e-007 sec
Found 0 joystick(s)
Devices enumerated: 3
Devices accepted: 3
[ ] RGB Emulation (SW)
[ ] Direct3D HAL (HW)
[x] Direct3D T&L HAL (HW)
Module AtlantisConfig.dll .... [Build 121203, API 121203]
Module AtmConfig.dll ......... [Build 121203, API 121203]
Module DGConfigurator.dll .... [Build 121203, API 121203]
Module OrbiterSound.dll ...... [Build 121120, API 100830]
Module ScnEditor.dll ......... [Build 121203, API 121203]
Module Meshdebug.dll ......... [Build 121203, API 121203]
--------------------------- WARNING: --------------------------
Scenario watcher thread timed out without returning.
---------------------------------------------------------------

 

[Face]

Please try first in a clean install. Your install is NOT clean, because you've got OrbiterSound activated.

Then gradually install more add-ons and check again. As soon as you have reproduced the faulty behaviour then, you've also spotted the root-cause. More often than not it is just an incompatibility of add-ons.

In your case, it looks like the splitter is too far to the left side, so you can't see the tree view anymore. I can't reproduce this behaviour in a clean install here. More reproduction information is needed...