Route packer tool...

Following some comments in another thread..

* A tool for 'packing' routes and ensuirng dependencies aren't missed. - This tool needs to be UI based, and should as far as possible 'hide'
the compression and meta-data generation from the content creator and downloader as far as possible.

In most respects most of this route packer is an interface to some kind of archive tool.

I'd suggest keeping it as simple as possible. Just let the dev select the route files (*.rw/*.csv) and/or the train files (panel*.cfg) and make the program detect all file dependencies.

Quork is right. If it is not simple enough it risks being ignored by the same people who ignored the original managed content facility.
It is challenging for the programmer, but it has got to be idiot-proof and idiot-friendly.
At least, it has if I'm gonna use it

graymac wrote:Quork is right. If it is not simple enough it risks being ignored by the same people who ignored the original managed content facility.
It is challenging for the programmer, but it has got to be idiot-proof and idiot-friendly.
At least, it has if I'm gonna use it

Putting on the 'problem analysis' hat.
What's a typical route package look like?

Or alternatively, when preparing content for publication, how are things collated?

Well, the optimal solution is: The package looks exactly as, e.g., Graymac's releases: It contains the whole file structure of OpenBVE\LegacyContent. Why? First off, the traditionalists among us can continue packing as they did before. Second off, old packages wouldn't need to be repacked but could be, right as they are, included into the content download system and/or installed via an offline dialogue inside OpenBVE.

Putting on the 'problem analysis' hat.
What's a typical route package look like?

Well, taking "route" specifically (though 'object' and 'sound' are similar) mine will be a folder with the routename on it, containing the .csv route files and related .txt files needed with '$Include'
This is presently downloaded by the user and the folder placed in the users own route folder, wherever he or she has it located. The same is done for the Object and Sound download.

If I update any of the routes sounds or objects the entire route/object/sound folder is compressed and I ftp the replacement to the server. From which point users are downloading latest versions.

To be frank, if it gets much more difficult than that then I wouldn't have a lot of incentive to participate in managed content, It's not exactly as if it puts food on the table!

Or alternatively, when preparing content for publication, how are things collated?

Now, with that activity there are more possible variables involved, several different approaches may be possible and no two designers will see it the same way. Or, put it another way, graphic designers are like Rabbis, two Rabbis, three opinions!

I had thought of making a program to pack ONLY useful files of a route and removing all comments, but then I think, is it really needed?

I had thought of making a program to pack ONLY useful files of a route and removing all comments, but then I think, is it really needed?

That is like exercising a form of censorship. What is "not useful"? Files with author and credits info? It's not the packer's job to decide, or to interfere with the contents. That's like the postman reading your letter from yer Auntie Fanny while bringin' it up the path!

The problem with programmers is that they can apply their brilliant minds to interesting, challenging and completeely pointless tasks. But as soon as the need for an authentic plug-in is encountered, you can't find one to make it.

Problem is, neither do we have an irish driver round here nor do we have anybody knowing how to get hands on irish railway regulations. There seems to be nothing to work with for creating a plugin. I read the wikipedia article about CAWS; it is a highly sophisticated system and to make a plugin of it, one would need to know how it acts under all conditions. Where to find that information? A Wikipedia article is not enough for doing anything. You need numbers, figures, regulations, just like, for PZB, regulation 483 and appendices. I suppose for CAWS the information ratio between what is needed and what one can find in Wikipedia (and other amateur sources) is similar as with PZB. A very basic description is provided by 483.0101 - and that's only the first module, quasi the preface of the regulation. And already this is far more than the WP article.

That's why I looked around in the internet yesterday, but nothing there. Only the contact data of the railway security board - and they might be of help in acquireing the regulations. If you have them, I hope you'll find a programmer just like me with PZB. I posted a brief description on the boards and promised I'd provide any data necessary, and shortly afterwards Timon kindly offered his help.

Problem is, neither do we have an irish driver round here nor do we have anybody knowing how to get hands on irish railway regulations. There seems to be nothing to work with for creating a plugin. I read the wikipedia article about CAWS; it is a highly sophisticated system and to make a plugin of it, one would need

to know how it acts under all conditions. Where to find that information? A Wikipedia article is not enough for doing anything. You need numbers, figures, regulations, just like, for PZB, regulation 483 and appendices. I suppose for CAWS the information ratio between what is needed and what one can find in Wikipedia (and other amateur sources) is similar as with PZB. A very basic description is provided by 483.0101 - and that's only the first module, quasi the preface of the regulation. And already this is far more than the WP article.

Quatsch! Here is the real problem, if as much time was spent on applying common sense to a simple solution as the time wasted deliberately making complications there would be something workable made.

All that is needed for a simple implementation, preferably as a supplement to an existing plug-in such as OS_Ats1 to retain functionality of wipers,switches etc.
CAWS displays the signal aspect of the next signal, or if the next signal is within a short distance then the NEXT section condition will display. It is constantly updating this information. When the aspect of the signal changes it is displayed in the cab. If the change is to a less restrictive aspect the driver need do nothing. But if the change is to a more restrictive condition then an alarm sounds in the cab. The driver must acknowledge and cancel the alarm within a short time, failing to do so results in emergency brake application.

This sort of thing is more use for routebuilders than 'managed content'.

Does the driver have to acknowledge the aspects? If so, which aspects? Within what time? What happens if he fails to? What happens if he acknowledges but doesn't act accordingly? Are there brake curves checked by the system? Are penalty brakings/automatic train stops executed? If yes, when? With what brake pressure? How can they be aborted? You write, if the distance is short, the next sections aspect is shown - what's the toggle distance? Etc. etc. Maybe it's "operational myopia" but in my eyes, a pseudo-simulation is worse than none.

Well, I was hoping for Anthony Bowden's proposed plug-in to be finished at some point, but it isn't likely. Those of us who make things (as opposed to endlessly waffling about the job) have had to rely on Anthony And Simon Gathercole, who seem to have done all the work. I see little evidence of any programming activity which would be of use, such as plug-in development. If all you have is "reasons why not", I don't want o know. It is wasting my time. I will save any descriptions and information for the time when I can pass it on to a "can do" programmer.

Plug in development... I have a poorly written somehow working ATO plugin for London Underground trains, which I somehow got to work with the always existing problem of trains underrunning the platform which happens sometimes on the real Central line... anyone wants it + the source code?

anyone wants it + the source code?

Thanks for the offer but what would I do with it, as i'm not a programmer. I shall have to put this fact in 30metre high neon lights on top of something conspicuously visible, as nobody seems to get the message.

I only wanted to show that plugin development apparently exists.. (I have the manuals and examples on my PC, fortunately)

Can I have it? I'd like to look at the source code.