[James Ross]

rdamurphy, on 03 November 2014 - 08:39 AM, said:

What is the primary obstacle to moving to XNA 4.0?

There are breaking API changes where they tidied up the API and removed some things that were Windows-only (remember XNA works on Windows and Xbox). Work is ongoing right now to make this migration step which will enable us to then migrate to many more things in the future and generally open up our options. Think of it as the way out of XNA. :)

[cjakeman]

The posts in this thread are showing a substantial measure of frustration. The project is being pulled in different directions - towards more compatibility and also towards the new capabilities that we've waited so long for (nearly 5 years now).

We also have two different sets of users - the veterans, of course, and then there are the newcomers who try Open Rails with existing MSTS content and abandon it if they find too many problems.

So achieving compatibility has not been a wasted effort. Many more trains can be started, more activities can be run to completion and there are fewer invisible items of rolling stock.

Dave Nelson is quite right to say that what comes after v1.0 is a different sort of challenge and James has identified a number of problems with the current architecture which must be corrected.

I have started a thread on the Open Rails Development forum to nail down the minimum we need to declare v1.0.

I also think it is time we established a team to plan the long-awaited new Route Editor, so I have started a thread for that too.

[edwardk]

This is a reply to Chris's recent post concerning the minimum work needed for V1.0.

The first would be refueling(operational issue). The minimum operation is there, but it would be great if this can be refined so that the graphics that is part of the process is animated. The second part is the physics involved with refueling. It should not take seconds to refuel.

The second is involving a possible bug that was reported some time ago that involves the Lat & Long values coming from OR. These values are reported to not be accurate when they are used in MSTS's route editor. I am not sure if this can be completely fixed, but it should be possible to improve the accuracy.


I do not have any other items in mind, but this one item is more of a question of would we need this and that is the bounding box? We all know the bounding box in MSTS created a barrier. Would OR benefit from this?

Edward K.

[dforrest]

cjakeman, on 03 November 2014 - 11:13 AM, said:

I have started a thread on the Open Rails Development forum to nail down the minimum we need to declare v1.0.

Chris, you will obviously not get input from users such as myself to such a thread.

------------
David

[cjakeman]

dforrest, on 03 November 2014 - 12:39 PM, said:

Chris, you will obviously not get input from users such as myself to such a thread.

You're quite right, but I see this as a decision for the dev team to take, after considering the valuable input from this thread and from other forums.

Best wishes,

[captain_bazza]

Quote

I have started a thread on the Open Rails Development forum to nail down the minimum we need to declare v1.0.

Thank you Chris, that comment sums up the crux of this thread. Bring OR to a point of development where it will work, not standalone [yet] but fulfill the requirement that compatibility {MSTS} and new features are relatively stable - so that most features work without throwing up nasty bugs.

It is not intended to freeze development, but to mark a point version 1.0,where developers have a stable platform, at a point in time, on which to continue towards whatever development goals are desirable leading towards version 2. End users would have a stable [as close as] version to learn and experiment with. It would also be a platform to attract potential OR users.

The other point made, or should be realized is, we are moving away from MSTS because it is becoming increasingly difficult to source a legit' copy of the software. At the present time [inclusive of OR v1.0] OR requires a symbiotic installation of MSTS installed.

Version 1.0 is just a convenient label on which to hang a stable [with provisos] version of OR}.




Cheers Bazza.

[atsf37l]

Neither of the referenced links seem to be able to find their threads, each throwing an error message. Have they been taken down already?

And Chris there is another set of users like me who are relative newcomers to OR but who like what they see and are doing everything in their power to make existing things from MSTS work in OR as well as encouraging OR versions of existing motive power and equipment. :bigboss:

[markus_GE]

Said links refer to the private ORTS Dev Team Forum, which can only be seen by Dev Team members and ET Staff.

Cheers, Markus

[Csantucci]

Above there has been again some discussion on OR currently not supporting XNA4.0 (even if I believe to remember that gpz had more or less a working version).
What about .Net Framework? The actual OR installation manual states that .Net Framework 3.5 SP1 is necessary, and that .Net Framework 4.0 (4.5 is not mentioned) is not compatible with OR. Does this still apply? Does it make sense? Are there plans or ideas about this?

[gpz]

I am in a process of rebasing the XNA4 branch onto the current version, and we will see what comes out of it. But XNA4 only supports .Net4, so 3.5 will be insufficient for it.