I noticed in the /HeadlessWorkspace/ docs there is a reference to a
/RenderInterface/ object in the constructor, is there any way to hook
into that mechanism to generate draw events for a WebSocket connection?
Conceivably, but that sounds terrifying to me. If you want to go that
route, the best way to go about getting to diffs is to use
`org.nlogo.mirror.Mirroring`. The "mirroring" stuff generates updates
of the viewable model state. Look here
<https://github.com/NetLogo/Tortoise/blob/c14974f94916b181fb312b09e1046a01fb93d67e/netlogo-web/src/test/scala/dock/DockingFixture.scala#L139>
for an example of how we use it in the Tortoise testing infrastructure.
To give an overview of what's going on there, Tortoise generates these
updates as the simulation engine runs, and then we use
`org.nlogo.mirror.Mirroring` with a headless instance of NetLogo to make
sure that both the Tortoise/JavaScript engine and the NetLogo/JVM engine
are generating the same view state updates. So if you follow the uses of
`Mirroring` there, you'll see how to use it to generate and serialize
view state updates.
Or is maybe adapting/magpie'ing from the Teletortoise codebase maybe a
better option?
I don't recommend that, but it's /doable/. That code was never
particularly pleasant, it doesn't handle widgets at all, and it's now
several years out of date (if you care about using NetLogo 6.x). If you
really want a web renderer, I think that using the NetLogo Web one is
probably your best bet. Note that the NLW renderer isn't the main
performance bottleneck of NLW; it's the JavaScript-based simulation engine.
So... if you want a web renderer, I recently put something together that
ran a version of Wolf-Sheep Predation without a simulation engine; it
was just JavaScript calls that would generate view updates. Since I
know that it worked for that purpose, I've just torn out the Wolf-Sheep
code, and marked where you should insert your code with "<!-- INSERT
RENDERING STUFF HERE -->". You can find it here
<https://gist.githubusercontent.com/TheBizzle/01152d2d6e12bf58e9a79b6d8a01017d/raw/c1d11fbd6225a7081e1bb62c7edaf4a168e6676d/NLWHusk.html>.
Copy the text at the linked location and save it into an HTML file.
To put this all together:
* Set up your headless NetLogo to run the mirroring diffs every so often
* Serialize them, and send them over a socket
* React to messages on the socket in the "INSERT RENDERING STUFF" area
* Use that diff data to update the variable `update` that I declared
in the file; what's in this file is a mock of the original `Updater`
file
<https://github.com/NetLogo/Tortoise/blob/c14974f94916b181fb312b09e1046a01fb93d67e/engine/src/main/coffee/engine/updater.coffee>
(which the NLW UI looks for to find updates), and I've set things up
here in such a way that you only need to worry about mutating that
`update` object in order to change the visualization
* When all of your updates have been applied into `update`, set
`Updater._hasUpdates = true`, and the NLW renderer will then apply
your updates to the visualization
In the 'NLWHusk.html' file that I linked, I've included a couple of
"demo" things to help show how to modify it. See the "<!-- START
PARTIAL WSP EXAMPLE -->" section to see how `update` is being
manipulated to initialize the patches and world dimensions. See the
"<!-- START WIDGETS -->" section to see where the widgets are defined.
I got that widget JSON representation from opening up Wolf-Sheep
Predation in NLW and doing
`JSON.serialize(session.widgetController.widgets())`, and then doing a
bit of manipulation of the output. Though, obviously, the widgets don't
work in this file, since I tore all of the WSP stuff out.
If you need the widgets to work (with variables being bound between the
engine and the interface), that will be more work. You'll have to do
some messing around with things in the JavaScript. You can get a hold
of the widgets by running `session.widgetController.widgets()`. The way
to hijack the buttons is to override their widget object's `run`
function (e.g. to send a message over the socket).
Surely, that doesn't cover all that you'll need to know, but ask more
questions (when you run into problems), and I can provide more answers.
On 11/29/2017 12:51 PM, Robert Bates wrote:
Jason, thanks for the quick reply! Remote desktop is not really an
option. I noticed in the /HeadlessWorkspace/ docs there is a
reference to a /RenderInterface/ object in the constructor, is there
any way to hook into that mechanism to generate draw events for a
WebSocket connection? Or just an event callback that is notified when
things change in the simulation world? Or is maybe
adapting/magpie'ing from the Teletortoise codebase maybe a better option?
Thanks!
-Rob
On Wednesday, November 29, 2017 at 1:05:32 PM UTC-5, Jason Bertsche
wrote:
Teletortoise is the best thing that exists for that use case, but
the project was abandoned some years ago in favor of
Tortoise/NetLogo Web.
Depending on exactly what you're looking for, you might be better
served by some sort of remote login service, and use that to log
into some machine that's running desktop NetLogo.
On 11/29/2017 12:00 PM, Robert Bates wrote:
Hi there! First off, thanks for providing such a well-documented
set of tools! We're currently building a solution that requires
the simulations to be run on the server, but want a nice web
client UI for the simulation run as well as controls (star, stop,
variable sliders, etc). Our current web app is being built with
Spring Boot. I ran across Teletortoise, which appears to be a
Play app that appears to have seen no activity for a while.
Could someone speak to the state of Teletortoise, and if there is
a newer solution I should be looking at for server-side execution
and browser-side viewer?
And yes, we've evaluated NetLogo Web, but we really need the full
NetLogo instruction set and extensions available on the full
Java-based implementation as well as the performance for very
complex models.
Thanks in advance for your help!
-Rob
--
You received this message because you are subscribed to the
Google Groups "netlogo-devel" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected] <javascript:>.
For more options, visit https://groups.google.com/d/optout
<https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=DwMFaQ&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=sxGjFFyk2A6rYHwAdDtnqeTKj3cEcXDGDo_G9va2ruI&m=BuqzC4RKEAycpI049S5kLVYUeDSmS2LaFR3rv64NEHA&s=lEnpoe9PRWNnn-2kBqrt2PZuNrUF1CpttTboooBX1Hc&e=>.
--
You received this message because you are subscribed to the Google
Groups "netlogo-devel" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout
<https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=DwMFaQ&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=sxGjFFyk2A6rYHwAdDtnqeTKj3cEcXDGDo_G9va2ruI&m=1f3UuBU2XOXlWw9X6_mDd5KTMCjBGzKBgRT40IN7ycs&s=X6vNHqEEN5J8O8jBH4o2dIG1GITi9Buu37xdxvMDySg&e=>.
--
You received this message because you are subscribed to the Google Groups
"netlogo-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
