• Track: Has not changed since “\pɔʁt.na.wak\” dev in PA.
• Track is part of “\pɔʁt.na.wak\” and is supposed to be a throw-away “quick” project. At that point it’s worth thinking whether there’s some real long term value in the project and in which case build a real standalone one.
• What I need is a more generic way to describe track segments.
• And import the ones from SCARM.
• Then use it on my own layout design.
• The 2D view lacks precise geometry tools that I’d take as a given:
• rulers x/y,
• units (inch vs mm),
• ability to move something at a specific place by x/y coords,
• rotate by entering an angle,
• ability to measure distance,
• ability to dup/offset a track to another one (or an anchor point).
• NCE Cab:
• Wrote a “design doc” / spec / desiderata doc for it.
• Need to do a prototype.
• First need to validate can use the RS485 interface on Windows/Java & Linux/Java (instead of Linux/Python). That first test could be a simple Java port of the existing python nce protocol decoder, without the ncurses part.
• 3D Blender:
• Desired goal would be to have a quick export from Tracks or for Scarm into a blender file, then play with materials there.
• “Cab Engineer” Android Mobile WiThrottle:
• I’ve started this for my own need as part of the old JMRI / JED experiment, then made a single use app with Wear integration also as an experiment.
• I had some desire last to reboot that into a formal project.
• See “Cab Engineer” below in 2017-12-18 update.
• Randall replacement for the NCE Button Board.
• Desktop app to access Wyze cams

It’s interesting to consider scopes:

• Cab Engineer: For me + public app.
• Value for me: mild.
• Existing apps: Engine Driver.
• 3D Blender: Only for me.
• Track: For me + public app.
• Value for me: medium/high.
• Existing apps: Plenty on desktop (can’t match), none on Mobile.
• Would be satisfied if I could just match desktop Scarm.
• NCE Cab: For me + public / for club.
• Value for me: medium / low. Technical challenge.
• Experimental: high value.
• Finished product: low value.
• Public / club: No adoption realistically expected at all.

So of these, based on value:

• Track / desktop is highest.
• Track / mobile is for fun and shows some interest.
• NCE Cab for the experimental phase value.
• 3D blender for some moderate value.

Based on this my order is going to be:

• NCE Cab - experimental phase aka validation prototype.
• Track / desktop.
• Revamp of experimental project, focusing on Scarm level.
• No mobile target at first but keep in mind for feasibility.
• Track / mobile. Maybe.

Not so quick test in 3d + Java + desktop. Part of portnawak. Could be made in its own project.

What I want, for me:

• Android version.
• Touch UX
• Running trains.
• Save online. G drive, drop box.

Doc Link from “\pɔʁt.na.wak\” in google docs.

Goal: something like this https://www.trackplanning.com/3pi.htm

Candidates that should work for either JVM desktop or Android:

• jMonkeyEngine
• https://github.com/jMonkeyEngine/jmonkeyengine
• Overview: https://android-arsenal.com/details/1/1390
• libGDX
• https://github.com/libgdx
• Overview: https://android-arsenal.com/details/1/11
• jPCT
• http://www.jpct.net/about.html (JVM)
• http://www.jpct.net/jpct-ae/index.html (Android)
• Overview: https://android-arsenal.com/details/1/10
• SmartGL
• https://github.com/smart-fun/smartGL
• Overview: https://android-arsenal.com/details/1/4715

Upfront, jMonkeyEngine describes itself as a full environment, SmartGL as just a 2d/3d view wrapper, GDX and PCT seem more in-between.

Requirements:

• Fullscreen or view
• Basic physics
• 3D import… which format, from where?
• Interactivity

Looking at this:

• SmartGL seems limited to exactly what’s in the name.
• jPCT seems to have a clear distinction between desktop and Android. Can’t tell how recent it is.
• libGDX seems to have good modern support and good wiki tutorials to get started. There are also wrappers for Bullet and Box2D for physics engines and corresponding tutorials.
• https://xoppa.github.io/blog/using-the-libgdx-3d-physics-bullet-wrapper-part1/
• https://github.com/libgdx/libgdx/wiki/Box2d

So let’s start with libGDX.

Summer travel choices:

• Hint as a base for Nawak.
• Nawak (editor / vm / platform).
• Conductor 2.
• Portnawak (quick game to learn kotlin).

Another idea to explore:

• Read a SCARM file and generate 3D track data for blender.
• Layout software for Android / mobile. Scrap existing library data to get started.

Maybe that’s what Portnawak could be: a potpourri of random mobile apps “1 day” experiments, with multiple absolutely unrelated activities in the same app.

Decided on the following plan for this summer:

• A 1-week addition to Portnawak as a simple “falling dot” game. Goal is to not focus too much on the engine part and develop some real kotlin code.
• A very very short throw-away track layout experiment. How would interaction work? Consider having only 2 pieces of tracks (1 straight + 1 curve) with auto-snapping. The goal here is to put that code in a generic library + UI that is android specific.
• After these 2, consider if I want to keep using kotlin or go back to Java.
• Then move on to the simulator for Conductor 2 (java app). Structure it at all in a library except UI in a java project (swing) or web rendering.

My main objection with the Wyze Cam is still the cloud-only and reports of outbound traffic.

Also “cell phone only, no web site”

So, way to work around this: https://openip.cam/ 

The base for the Wyze is the Xiaomi XiaoFang (see fang-hacks), which is not actually cheaper.

The next phase in Rig4 is to be able to generate a simple blog.

In Cab2 / RTAC, the mDNS discovery generally gives IPv6 addresses before IPv4.

2 things to investigate:

• Why the code always seems to fail to connect to the IPv6.
• Can I programmatically convert an IPv6 into an equivalent IPv4 (at least for local networks) and try that instead?

Things to look for:

• A per-page “share to FB”. https://developers.facebook.com/docs/sharing/web
• FB markup: https://developers.facebook.com/docs/sharing/webmasters#markup
• A per-page “share to G+”
• G+ markup?
• Twitter meta-data: https://developer.twitter.com/en/docs/tweets/optimize-with-cards/overview/summary
• Microformats v2: http://microformats.org/wiki/microformats-2
• RSS feed for “blog” page?

From http://www.kevinmarks.com/partialsilos.html: G+ will parse the FB “open graph”.

It links to http://schema.org/Article which is Meh2.

I’m not sure I want “share buttons”. What I’d like however is being able to tag a snippet + target image with an izu-tag and then let it generate the sickening tags automatically.

Rig4:

• Got a whole new implementation in Java. Works using gdoc, local hash cache to avoid updating content that has not changed. Aggressively trims exported HTML. Not even using Material Design Lite nor Bootstrap, keeping it super simple.
• This is “good” enough for now. It is all an “exp” prototype and not per spec.
• Might implement the Rig4 spec for MM later?

Randall:

• Back in business. Work on laptop, work on tablet, work on turnout control.

Software:

• Cab Engineer (v2 for Cab Throttle). Next project in line.
• Monitor (on hold).
• Nerdkill Unity (on hold).

Rig4 was not generating drawings anymore.

Two issues:

• The generated URL for drawings changed from docs.google/com/drawings/image?id=... to docs.google.com/drawings/d/<id>/image?...
• The generator was not generating an error on unprocessed docs.google.com links. That means these were exposed in the generated HTML and savvy-enough users would try to follow them, get an access denied and ask for permission to get access to the underlying doc.

Although Rig4 experimental doc generating work, it's still an ugly hack. It's very dependent on the generated html format. In essence the system is too fragile and doesn't work.

Also it regenerates every time, regardless of whether the source has changed.

So eventually I need to fix that.

The Drive.files.export API has the following formats for download:

https://developers.google.com/drive/v2/web/manage-downloads 

• Docs export to HTML, text, rtf, Open Office, PDF, MS Word, EPub.
• Drawings export to JPEG, PNG, SVG, PDF.

The Python-based implementation is a core part of the issue, and it’s clunky.

As far as languages to use, although Go works in its own clunky way, I'd like to get away from it. I'd say the contenders are Java or Node.js at that point. The Drive API also offers .Net, Python, PHP and Ruby but I need to standardize on something and JS might do it for what it's worth.