Area 1.0

Hi all,

As you might know, I am still doing some small updates to the SrrTrains v0.01 project, although THE PROJECT IS IN A CLOSED STATE and I AM WAITING FOR 3rd PARTY INTEREST.

Well, I have done some updates to the “Hobby Reports” (former “Hibernation Reports”), which had been granted to the SP-ARK project at GitHub. Now they are available in Version 4.3:

1. HR 001 Pieta / Rebase to MIB Core
   some minor updates
2. HR 005 SRR Objects
   major changes regarding vehicles/trains
3. HR 007 New Concept Paper of SrrTrains v0.01
   a few small but essential updates
4. HR 009 SMS Facility Loaders
   a new chapter about unbound objects (UBOs)

All the Hobby Reports can be found at the master branch here at this link.

The README is here.

Merry Christmas
Yours Christoph

Hi all,

I have frozen Release 3 of the documentational “Hibernation Reports”:

Only bugfixes will be done any more: Hibernation Reports (3.x) – Frozen

On the other hand, I have merged and deleted the branch “devel_arimathea”.

Now the Release 4 of the documentational “Hibernation Reports” will be developed at master:

Development: Hibernation Reports (4.x) – Open

Have a nice week

Yours Christoph

Hi all,

This is the final planning for the SrrTrains v0.01 project (nothing new so far):

I added the key words *TODO11*, *TODO12* and *TODO* into the Concepts’ Descriptions to have a feeling of

1. What has already been done – no tagging
2. What is planned for step 0033.11 – tagged by *TODO11*
3. What is planned for step 0033.12 – tagged by *TODO12*
4. What has not been planned yet – tagged by *TODO*

Please find the updated Concepts’ Descriptions here:

001_Glossary…*TODO12*………overview of the concepts and some terms
011_NamingRules……………..using names in an SMS; the MMF paradigm
012_FrameAndModules………….the frame and the modules
013_ModelsAndObjects…………astral, bound and unbound objects
014_ConsoleInterface…………influencing an SMS from a Command Line Interface
051_Extensibility……………extending the software (e.g. for road vehicles)
052_UnboundModels.*TODO11*……creating and deleting models at runtime
053_Handover.*TODO11*………..unbound models changing modules dynamically
054_MovingModules.*TODO11*……including modules as parts of a model (eMMF)
099_PerformanceConsiderations…is performance an issue?

The Overall Planning (i.e. Prophecy)

STEP0033.11 / architectural features

unbound models, handover, moving modules with experimental vehicles (v=const)
not before 2020

STEP0033.12 / railway kinetics (v not equal const)

with basic vehicles
not before 2021

LATER

1. Rebase to some “SMS”/”DIGITS” environment
2. additional railway features
   1. coupling and collisions
   2. 1900’s Interlocking

Have a nice week
Yours Christoph

Hi all,

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

However this fact should not prevent me from continuing on a “hobby level”.

In my latest posting (The “Regway”) I introduced the experimental vehicle that will be implemented by the release 0033.11 “Arimathea” (not before January 2019).

This week I’d like to publish an overview of all features of the SRR Framework.

In red font: the “bleeding wounds” of SrrTrains. Things that are being awfully missed currently.

In case of questions or comments please feel free to use the commantary function any time. Your mail address will never be published.

Yours
Christoph

Hi all,

I have started to design the what-I-call Regway.

It’s a kind of “R-Segway” (a Segway for railways) and it will be the first vehicle of the new SrrTrains software (after the redesign, which has been lasting since 2010).

I am expecting the new software “Arimathea” (0033.11) not before January 2019.

You can download the current software (0033.10bf3 “Pieta”) at http://simulrr.sourceforge.net

Have a nice week

Yours Christoph

Hi all,

I have done a check and some small improvements on the SrrTrains Web Pages:

1. Die Projekte (German language) – Overview
2. SrrTrains v0.01 – the first project (closed)
3. Simple Playground – future option for SrrTrains v1.0
4. Packet Switched ARK – something different

Have a nice week
Yours Christoph

The “Concepts for Rail Vehicles” turn out to be a “neverending story”.

Doing baby steps – little baby steps – but the direction is correct (hopefully).

Updated chapter 4 of “Hibernation Report 009” again – now version 4.1:

https://github.com/christoph-v/spark/blob/devel_arimathea/3rd-party-input/SrrTrains-v0.01/HibernationReports/hr009-facility-loader-v4.1.pdf

Have a nice week
Yours Christoph

Hi all,

Happy I am now in a situation to be allowed to publish the basic idea about how it could be possible to use group calls in a R’4 GSM-R network to define a “Mixed Reality Theatre” for display at some “VR Equipment”.

This is the paper (GPL): MixedRealityGroupCall-Valentin-v1.0.pdf

Have a nice week
Yours Christoph

Hi,

In my latest postings, see

• here: SrrTrains – Reduced to a pure hobby project and
• here: SrrTrains – Concepts for vehicles clearer

I told you that I am actually thinking about how to proceed now.

The concepts are getting clearer and clearer, but I have not yet thought about how we should proceed, if we had the “Mixed Reality Mode” (MR Mode) one day in a future far far away from now.

What, if we connected the virtual railroad with *real* 3D printers and 3D scanners, generally spoken, real replicators (RR)?

I think, we would have to split the process of creation of a vehicle (aka UBO) into two phases:

1. The Definition Phase
2. The Creation Phase

The 1. Definition Phase – where the *real* replicator did his job – could last very long, many seconds, even minutes or hours.

The outcome were an “Object Type” (OT), identified by an “Object Type ID” (OTI) and a URL, where the Web3D Browser could load the model (aka UBO) from.

At the end of the definition phase, we had

• a Real Life Object (RLO),
• being situated within a real replicator,
• ready to receive an “initial state” from the multiuser scene

In the implementation I’m currently thinking about I would skip the Definition Phase (because I have no MR Mode and I will be using pre-defined OTs).

Now, in the 2. Creation Phase, the SMS would load the UBO from the URL in all scene instances and finally the global state of the UBO would be initialized to the “initial state” (in the multiuser scene and in the RLO).

Sounds reasonable, doesn’t it?

Have a nice week
Yours Christoph

Hi all,

The more detailed I think about the concepts for SrrTrains Rail Vehicles, the clearer it gets to me: yes, this is the right direction. These are concepts for centuries.

Now I have updated chapter 4 of the “Facility Loader” document.

If you like to dig into the concepts in a very detailed way, you can do this at:
https://github.com/christoph-v/spark/blob/devel_arimathea/3rd-party-input/SrrTrains-v0.01/HibernationReports/hr009-facility-loader-v4.0.pdf

Have a nice week
Yours Christoph