[moved] suggestions by Manuel
4 posters
Page 1 of 1
[moved] suggestions by Manuel
I got a request...
I was travelling on Subway or Underground in some contries and thinked about what it's missing on OpenBVE.
The question came to my mind and it's this one. Where is the wheelslip indicator. or how to made them?
Looks like it's missing and could be necessary on the future. I've watched some trains with this effect on openbve but doesn't exist a indicator or a command on animated to this.
and like a month or weeks ago. I got some other ideas which are a bit delicated.
I think OpenBVE it's a "MONSTER" compared with other versions. And it's time to think on another kind of Route file...
I've watched github and it's a new command to switch rail to other rail indexes. So it's a tiny idea with big possibilities
I think CSV route file it's well defined but there are other software limitations. Per Example with Switch command exist a huge posibility on implement multi track route with dynamic routes.
So. It's a huge step convert a "single line player" into a "multi track player services". and as we know signals and track commands need other atributes like direction and rail index.
I was travelling on Subway or Underground in some contries and thinked about what it's missing on OpenBVE.
The question came to my mind and it's this one. Where is the wheelslip indicator. or how to made them?
Looks like it's missing and could be necessary on the future. I've watched some trains with this effect on openbve but doesn't exist a indicator or a command on animated to this.
and like a month or weeks ago. I got some other ideas which are a bit delicated.
I think OpenBVE it's a "MONSTER" compared with other versions. And it's time to think on another kind of Route file...
I've watched github and it's a new command to switch rail to other rail indexes. So it's a tiny idea with big possibilities
I think CSV route file it's well defined but there are other software limitations. Per Example with Switch command exist a huge posibility on implement multi track route with dynamic routes.
So. It's a huge step convert a "single line player" into a "multi track player services". and as we know signals and track commands need other atributes like direction and rail index.
Manuel18- Posts : 75
Join date : 2012-10-18
Age : 30
Location : Caracas,Venezuela
Re: [moved] suggestions by Manuel
I have heard about a multiplayer version of openBVE being developed. I haven’t seen it yet but if it’s what I think it is, then multiple trains can be loaded on multiple tracks which possibly increases the number of “running” tracks which may open up possibilities for route branches in a single file. But this is just a guess. I’m not sure how this function (if it exists) could make it into the main build or whether there will be more updates on the multiplayer version.
SP1900- Posts : 301
Join date : 2017-12-08
Age : 21
Re: [moved] suggestions by Manuel
Multiplayer is a tricky subject.
s520 recently added the ability to move AI trains on other tracks, and I've currently got a highly experimental branch which allows the player to switch between tracks:
https://github.com/leezer3/OpenBVE/pull/329
This works acceptably (ish), but it's a long way off being actually usable for anything sensible.
What you've got to remember is that BVE has been designed from the start as relative to the single track of Rail 0, and everything revolves around this to one extent or another.
Similarly, there's not really any provision yet for a train to be anything other than controlled by the local player or the AI. This is a *lot* more complicated than you might think, just a few of the more obvious problems-
* Calculate the physics on the computer of the 'driver' or the 'viewer'?
* How do we handle dropouts in the network? (Intertwined with the first question!)
* If we have different players, we need different trains (Currently, the AI train is nothing more than a lightweight clone of the player train)
* The signalling system needs to communicate between the different players, independently of the trains.
s520 recently added the ability to move AI trains on other tracks, and I've currently got a highly experimental branch which allows the player to switch between tracks:
https://github.com/leezer3/OpenBVE/pull/329
This works acceptably (ish), but it's a long way off being actually usable for anything sensible.
What you've got to remember is that BVE has been designed from the start as relative to the single track of Rail 0, and everything revolves around this to one extent or another.
Similarly, there's not really any provision yet for a train to be anything other than controlled by the local player or the AI. This is a *lot* more complicated than you might think, just a few of the more obvious problems-
* Calculate the physics on the computer of the 'driver' or the 'viewer'?
* How do we handle dropouts in the network? (Intertwined with the first question!)
* If we have different players, we need different trains (Currently, the AI train is nothing more than a lightweight clone of the player train)
* The signalling system needs to communicate between the different players, independently of the trains.
Re: [moved] suggestions by Manuel
If this were to be tackled, a flexible API would be really worth much. It could be used to connect OpenBVE to an instructor, so it could be used as a base for training simulators. It could also be used to connect OpenBVE to a signal box simulation.
Calculating the physics on the individual driver's computers would distribute loads more evenly. A buffer time would help. Let's say the individual trains send their current position, speed and acceleration every two seconds; then the receiving simulations could interpolate the display position between the last two data sets. This would mitigate any jumping/stuttering at the low cost of a small lag, which wouldn't be noticeable/relevant. In the event of a dropout it could be extrapolated for several seconds (so there's a chance connection is reestablished), before defaulting to handing the train over to the AI.
Calculating the physics on the individual driver's computers would distribute loads more evenly. A buffer time would help. Let's say the individual trains send their current position, speed and acceleration every two seconds; then the receiving simulations could interpolate the display position between the last two data sets. This would mitigate any jumping/stuttering at the low cost of a small lag, which wouldn't be noticeable/relevant. In the event of a dropout it could be extrapolated for several seconds (so there's a chance connection is reestablished), before defaulting to handing the train over to the AI.
Quork- Posts : 1437
Join date : 2012-05-05
Age : 32
Location : Hofheim a.T., Hessen (Hesse), European Union
Similar topics
» Animated Camera Variable + Sound Suggestions
» 90046 Derailment at Bletchley (Moved by request)
» Variables and other suggestions
» Non British route suggestions
» Suggestions for the Route Shifter tool
» 90046 Derailment at Bletchley (Moved by request)
» Variables and other suggestions
» Non British route suggestions
» Suggestions for the Route Shifter tool
Page 1 of 1
Permissions in this forum:
You cannot reply to topics in this forum