Area 1.0

Now, when the version “Pieta” has been finally released and when I have reported that my “professional goals” of the project were reached, it is the correct time to answer the question to myself:

Will I still continue – or better resume – the project or will I lack the motivation to consume leisure time for something that is perceived as being a burden rather than a pleasure.

Well, the tricky thing is to never do any commitment to anybody.

It’s done, when it’s done.

So I have updated my little paper about “Unbound Objects (UBOs)” and I have translated it to English language.

This paper is a kind of manifesto for the next steps of the SrrTrains project and sketches the requirements for the support of UBOs and Handover:

https://github.com/christoph-v/spark/blob/devel_arimathea/3rd-party-input/SrrTrains-v0.01/HibernationReports/hr011-unbound-objects-v4.0.pdf

However, never ever this paper contains any commitment regarding a timing of the project.

It’s done, when it’s done.

Have a nice week
Yours Christoph

P.S.: if you are interested in the “professional goals”, and in how far they have been reached, feel free to contact me via e-mail

Now, when I have released the la(te)st version of the SrrTrains v0.01 software (please see here: https://areasharpa.wordpress.com/2018/06/09/spark17-a-bugfix-for-the-pieta/), and when I have bothered my readers with so many detailed information, I would nevertheless like to give a SHORT SUMMARY about the WHY of this project.

The reason for this project is the SUPPORT OF THE IDEA OF A NETWORK SENSOR.

When I started to implement a multiuser virtual model railroad based on VRML/X3D (still not finished!), then I asked at the x3d-public mailing list, whether there was some STANDARDS for multiuser communication.

Those times (I think it was around 2009), two standards were proposed – DIS and the Network Sensor – and I selected one of both for my hobby project.

Those times I thought the Network Sensor was more general and so I went for it.

Maybe I was wrong.

However, I found three standard use cases of the Network Sensor and I invented a fourth use case of the Network Sensor.

Most of the SrrTrains project is about this fourth use case (to examplify it, to try around with it and to become sure, whether I should recommend it for the community).

These results are now nailed down in the SP-ARK project.

Please refer to the power point at https://github.com/christoph-v/spark/blob/master/3rd-party-input/SrrTrains-v0.01/TechnicalSummary/Sms3DWeb_20180610.pdf.

Also refer to an overview of the SP-ARK project at https://areasharpa.wordpress.com/spark/.

So far, I am still not sure, whether it would have been better to go for DIS, however, these are my results and they can be used by anybody.

Have fun with Web3D
Yours Christoph

Hi all,

The la(te)st release of the SrrTrains v0.01 software was the “Pieta” release from May 2017 (with the version 0033.10bf2).

Now I have done a few minor corrections and improvements (see the list below) and a new release 0033.10bf3 by 2018-06-09.

The files can be downloaded directly from sourceforge:
https://sourceforge.net/projects/simulrr/files/

Please be aware: the project is “CLOSED” and “WAITING FOR 3RD PARTY INTEREST”.

Have fun with Web3D
Yours Christoph

P.S.: what’s new?

released: 2018-06-09, SVN revision: 333
– Interface Changes:
– release 0033.10bf3 (SVN333)
– small renaming activity (SVN332)
– update Concepts’ Descriptions 100 – 999 (SVN331)
– update Concepts’ Descriptions 000 – 099 (SVN330)
– necessary adaptations for SrrSwitchB (SVN329)
– moving MoosSwitchB -> SrrSwitchB (just moving!) – (SVN328)
– Registration of Object Types (SVN 327)
– Initialization and Activation of UBO Loader (SVN 326)
– new SSC Activation Controller (SVN 326)
– new naming rules (SVN 325)
– locality of console parameters is set at the dispatcher stub now (SVN 321)
– now any console parameter can be a local parameter (SVN 321)
– Default gravity in McBase is 0 -9.81 0 instead of 0 0 0 (SVN 319)
– SmsModuleLoader separated from SscBase (SVN 318)
– Other Changes:
– implemented the “SMS Dispatcher Feature” (SVN 321)
– new field “isBound” of key container (SVN 320)
– minor improvements of SmsLoader (SVN 318)

Although the SrrTrains v0.01 project has been closed, and although the project is waiting for “3rd party interest”, I felt free

to update the Concepts’ Descriptions.

I already had done it for the papers 000 – 099 (SPARK#15),

Now I have done it for papers 100 – 999.

Please find here the Overview about the SRR Framework (which is paper 100, which contains links to all papers)

and – for completeness – the SYNOPSIS Paper (even more general).

The software (0033.10bf3) will be released soon (but only minor changes, so sorry).

Have fun
Christoph

Although the SrrTrains v0.01 project has been CLOSED, and is now waiting for “3rd party interest”,

I felt free to update the Concepts’ Descriptions, to be inline with the upcoming “bugfix 3” release of the 0033.10 “Pieta”.

• 000_Synopsis.pdf
• 001_Glossary.pdf
• 011_NamingRules.pdf
• 012_Modules.pdf
• 013_ModelsAndObjects.pdf
• 014_ConsoleInterface.pdf
• 051_Extensibility.pdf
• 052_UnboundModels.pdf

The papers 100 – 999 will follow soon (detailed descriptions)

Have a nice week
Yours Christoph

Now, when we can be confident that the PS-ARK project might go well, it’s time to write a little view back on 9 years of SrrTrains.

All started with the “third child” DIGITS, which was inspired in autumn 2000.

It’s not important to explain DIGITS, it will follow automagically, when the “SMS Biotope” will have evolved based on the definition of the SMUOS component, which is an outcome of SrrTrains v0.01.

However, SrrTrains was the idea to take X3D multiuser scenes for the implementation of railway multiuser games. And it worked quite well. Only problem, nobody could be convinced to help, it was all a “one-man-show”.

No need to be angry. That’s mankind. We need not worry about. Things will never change. Everything green.

Says
Yours Christoph

The “Hibernation Reports of the SrrTrains v0.01 Project” have been translated to English language and stored at the repository of the SP-ARK Project.

https://github.com/christoph-v/spark

This was the last activity of the SrrTrains v0.01 project – now it is in “CLOSED” state – but can be “RE-OPENED” by 3rd party interest.

Btw 1: still active “little burning candle” PS-ARK Project

Btw 2: still in state “ignition” SP-ARK Project

Have a nice Easter Sunday on April 1st
Yours Christoph

Most important hibernation reports were translated from German to English:

DONE- Update SrrTrains HRs – translate from German to English -> v3.1
– update most important: HR 001, 002, 004, 005, 007, 008

https://github.com/christoph-v/spark

Have a nice week
Yours Christoph

Hi all,

I received a question “what is this”?

OK, to know it you just had to read the content of the project at https://github.com/christoph-v/spark.

However, here in short words (once again – sighing):

1. SMUOS (Simple Multiuser Online Scenes) is a very old idea
2. that idea is an optional, but not a mandatory part of SP-ARK
3. SP-ARK is an idea for a project to support Simple Multiuser Scenes based on the X3D Network Sensor (that’s it and that’s all it is)
4. SP-ARK is in state “ignition” (there is not any supporter currently)

My personal point of view on SP-ARK (i.e. SMUOS) is explained in the following slide set: PlanA_vs_PlanB_Hobby_Valentin_2018_03_03

Have fun
Christoph

Hi all,

The SP-ARK Project is still in status “ignition ongoing”.

However, I felt free to update the “Hibernation Reports” for essential fitness.

See: https://github.com/christoph-v/spark/tree/master/3rd-party-input/SrrTrains-v0.01/HibernationReports.

Have fun
Christoph