[Openrail-devel] general API discussion

[Raphael L. <rap...@gm...>]

Am Mittwoch, den 04.06.2008, 01:39 +0200 schrieb Adam Czerwiński: 
> On May 30, 2008, at 8:08 PM, Raphael Lisicki wrote:
> 
> > Have float gauge; and let (or not) be interpreted by the application?
> > I think, every track should be considered as one. If there are two
> > tracks running parallel for a very long time, then they do. but I  
> > think,
> > that should be enough.
> 
> Right. There is no difference how many rails does the track have. One,  
> two - it goes one way.
> There is only a problem with limiting posiblities of them - more tight  
> gauge is, more tight curves we could model, but this is minor.
> So we just have to remember center of the track.
> 
> About simplifying modeling parallel track we could think of later.
>  From logical point of view they are two tracks, because if one is  
> busy, it does not mean, the other is also.
> 
> 
> > I would suggest absolute coordinates. For example in the UTM-Format.  
> > At
> > least for some points.
> > This also helps to find out a way where to start a construction or how
> > to proceed if there is no connection between to things.
> > Oh, this is too physical, I guess....
> 
> At some point we have to provide an API to represent physical tracks.
> UTM might be good way.
> The problem you have mentioned, connection between tracks (i mean  
> these - 40 meters long rails), how to connect them.
> 
> 
> >> Maybe something like "segment modelling"?
> >> When the map is big, next segment may be loaded when we are near it.
> >> But what if logical structure (like a Train Station) ends in the
> >> middle of quadrant?
> >>
> >> What do you think about it?
> >
> > I think, it is something, the 3d-Engine could do for us.
> 
> True. How representing UTM in Monkey works?
> Would mapping class (from our physical representation, to jmonkey  
> representation) be complicated?


As far as I know, UTM is not implemented into this engine and I couldn't
find any engine which has got. So we would have to transfer the
UTM-stuff to common 3d-space-coordinates :(

> 
> 
> > When moving forward on a trackpiece we would ask typically ask for
> > piece0.getConnection2(), same for every other TrackPiece. In this
> > triangular form, up and down will change at some point.
> 
> I think now I understand.
> Have you ever seen the map from the point of australian view?
> http://www.paradoxing.com/article/index2.html
> Nothing changed - North is in the same place it was from the beginning  
> of the globe :).

No I think it is not quite the point, but similar. In this case you will
get different information depending on which way you go.


> 
> I think I solved it providing method getOutputConnection.
> We provide an input connection (this, we are on now), and it returns  
> an output.
Correct

> If junction is set left - we go left, if it is right - we go right.
> If we are going from the right side and junction is set well - we go;  
> if it is set left ,and we are going from right - it should return an  
> exception or something.
> (DerailedException? ;)
> 
> 
> > Sounds really complicated to me. I think, there is no way to give a
> > possibility to cover all signalling systems + staying in a logical
> > world? So it needs to be on a higher level, right?
> 
> Exactly. Every signaling system is based on information whether track  
> is free or not.
> And this is the simplest way to provide an API for every possible  
> signaling system.
> 
> 
> >> PS. Maszyna EU07 (The Machine) is a polish train simulator, free of
> >> charge, but closed source. Closed source of that one, and problems
> >> with porting (without a source) made me started thinking about  
> >> openrail.
> >>
> > Are you in contact with this guy and asked about releasing the source?
> 
> I am in contact with them. Several people asked about releasing the  
> source.
> It even once was GNU GPL, but they have closed it (sic!). It was  
> possible, because original authors,
> had left project.
> 
> They have very strong modeling team (3d, etc), and I think it would be  
> possible to move part of them at some point;
> but as far as I know them - they would help us only when our project  
> is mature enough.
> 
> I have seen source code (c++ and pascal), but it was so crappy, that  
> even hard to read.
> For example - choosing physics (electric engine, diesel, draisine,  
> etc) is done using... strings parsing passed to
> the method. I would rather do that just using several classes loaded  
> on demand.
> They have problems with such things like modeling steam locomotive, or  
> a car on rails
> (we have built one http://www.youtube.com/watch?v=70fIm-a3IQo :),
> because source is closed and people are not able to make it possible  
> without hacking.
> 
> We could look how do they represent scenery, but actually I would  
> rather try to consider "The Best Way", and then look,
> not to be tempted to use their:
> http://www.eu07.pl/modules/mydownloads/viewcat.php?cid=8
I think, for representing scenery, we do not need to reinvent the wheel,
the Monkey Engine and a lot of other Engines have got heaps of ways to
store objects.
> 
> PS. What is your main rail interest? How is about your rail-knowledge?
> I really love steam.
contemporary urban transport, subway, lightrail, tram and things like
that
my rail-knowledge is rather basic.


> 
> PS.2 I've found simillar, but inactive project - http://sourceforge.net/projects/jrail
> Maybe some problems are already solved there, and we could move some  
> things into our API; but we have to be careful.
> 
Question is: why did they stop? ran into problems or no more motivation to continue...
I had a short look at the code but I am unable to judge.




//Raphael