I noticed the same thing and fixed it in build 191 ... then I tried to see if we could have a Java11 build & test - but worke node on Jenkins failed on 192..
1-The loading gesture is not a bug, I did that, this way gestures are loaded by default if you run i01.
Normally if you don't need to refresh, it doesn't need to load again the gestures.
I would say it is a bug. If you want the gestures loaded by default then have InMoov2 do it once. I thas nothing to do with the UI, and should not be triggered by it.
2-The controller not showing up is a similar issue than getPanel not working properly.
I'm looking into getPanel, I also notice the Intro is not saving state the way it is currently written, if I start a Servo intro ... and I refresh, it doesn't remember I started the Servo intro.
3-I know you fixed some sweep and enable things since this video has been made.
Ya .. I'm going through your list in the shoutbox. I already fixed the speed setting in Servo intro, which turned out to be a UI bug.
If you want the gestures loaded by default then have InMoov2 do it once.
If this can be easily added into InMoov2.java, I am for it. But the UI still needs to be able to do "msg.loadGestures()" , because I made a "reload gesture" button, which is usefull if you modify a .py and want it to be effective without restarting MRL.
How did the move of the InMoov5.j3o work ?
Ah I forgot to check that..
UPDATE: about the InMoov5.j3o, it is now correctly unzipped into resource/InMoov2/JMonkeyEngine
Now the InMoov2.java needs to be updated as well, for Simulator to have the correct path.
Additionally, state is correctly maintained for servo.
I found when I had to refresh, then look at the servo intro, it would think the servo is not there.
I "refactored" Intro ... and now it works as expected.
Part of this refactor is also simplifying the heck out of Intro. I didn't know how Intro would be used, and I appreciate you jumping into it and trying to do some demos.
You want cause and effect in the webgui with python scripts without Java modification. This would help you as a tool more than anything.
So I have done that.
Intro now only has 2 methods of interest, set(key, value), and get(key)
It acts like a pass through to the webgui. Anything you set instantly the webgui sees the change, you can get info in python.
In the webgui these properties manifest themselves in html as props.key = value
You get bonus properties too filled in by the Intro service.
When services are created you get {serviceName}IsActive = true.
When the service goes away you get {ServiceName}IsActive = false.
After refresh - intro understands servo01 is active
If I want to see quickly what the state of the props are - i look at properties with this url
To make logic decisions in the webgui I just use the props
You can set any property in Python
And they will instantly change in the webgui
The Intro Java service works as a pass through for information between Python and WebGui - no updates to Java necessary for changes or additional properties.
This is nice! I just tested the Intro servo and refreshed the browser, servo is still seen as active.
Thats good!
I noticed, speed is still not fixed though, when attaching the controller, speed changes to Max. I did a fresh install in a new directory with the PR 734
I also noticed that now virtual servo is throwing an error and crashed MRL.
-to reproduce start Intro
-start the servo
-press the button Virtual
It probably should crash at this point.
The crash is a "new edition", because I cannot close the zombies or even the windows. As you can see in the picture below, java is killed in the Window Manager, but the windows are still on my screen, and I cannot close them.
but i ran through eclipse .. i'll do a clean install shortly .. kwatter merged the change on develop now - i'll be testing web_dev_start.bat in a new dir.
The virtual switch does not have the correct state ... (refresh - go away)
I'm starting to look into the getPanel refresh problem too ..
I also did not have the maxSpeed problem - I wonder if your browser is caching some old files
I see in your video that you have only the servo without the VinMoov5.j3o .
I still get both together.
If you make a fresh install in a new directory, try also a full install of all services.
I noticed VinMoov5.j3o got installed in two locations:
1-data/InMoov2/JMonkeyEngine
2-resource/InMoov2/JMonkeyEngine
There are 3 when you use the make_web_dev.bat
~/mrl.test/gael/dev$ find . -name "VinMoov5.j3o"
./InMoov2/resource/InMoov2/JMonkeyEngine/VinMoov5.j3o <- dev repo version
./myrobotlab/resource/InMoov2/JMonkeyEngine/VinMoov5.j3o <- installed correctly from InMoov2 repo
./myrobotlab/data/JMonkeyEngine/assets/Models/VinMoov5.j3o <- installed incorrectly from InMoov dependecy
It took me a while to track down the VinMoov5.j3o being installed from an InMoov dependency, but it gets to the point that I believe we should remove InMoov from Nixie now. Agree ?
In a pr I'll be pushing I removed jme's auto-loading its own directory .. and this is were the VinMoov5.j3o gets dumped from InMoov's dependency info.
So no more standing over the servo
I'm also interested in getting rid of this menu from the jme display and implementing its functionality in the JMonkeyEnginge webgui.
I've also got the Servo & Virtual state information in Intro working correctly (beyond refresh).
However, an interesting thing now occurs, where jmonkeyengine can be attached as a controller, and since the servo only understand it can be attached to one controller at one time - it prevents it from being attached to an Arduino :P
On the good side, more stuff is starting to "Embrace the pub/sub" !
I have a plan how to fix this in JMonkeyEngine service so both can be happy.
The getPanel is irrating and at the moment don't know the details of what is happening there that requires refresh.
Thanks Astro... nice ;) I
Thanks Astro... nice ;)
I noticed the same thing and fixed it in build 191 ... then I tried to see if we could have a Java11 build & test - but worke node on Jenkins failed on 192..
I also added a stop button http://myrobotlab.org/content/we-stop-buttons
Should be fixed in 193 - although you pointed out several other bugs
@grog, 1-The loading gesture
@grog,
1-The loading gesture is not a bug, I did that, this way gestures are loaded by default if you run i01.
Normally if you don't need to refresh, it doesn't need to load again the gestures.
2-The controller not showing up is a similar issue than getPanel not working properly.
3-I know you fixed some sweep and enable things since this video has been made.
Hi Gael, 1-The loading
Hi Gael,
1-The loading gesture is not a bug, I did that, this way gestures are loaded by default if you run i01.
Normally if you don't need to refresh, it doesn't need to load again the gestures.
I would say it is a bug. If you want the gestures loaded by default then have InMoov2 do it once. I thas nothing to do with the UI, and should not be triggered by it.
2-The controller not showing up is a similar issue than getPanel not working properly.
I'm looking into getPanel, I also notice the Intro is not saving state the way it is currently written, if I start a Servo intro ... and I refresh, it doesn't remember I started the Servo intro.
3-I know you fixed some sweep and enable things since this video has been made.
Ya .. I'm going through your list in the shoutbox. I already fixed the speed setting in Servo intro, which turned out to be a UI bug.
How did the move of the InMoov5.j3o work ?
Hello Grog,If you want the
Hello Grog,
If you want the gestures loaded by default then have InMoov2 do it once.
If this can be easily added into InMoov2.java, I am for it. But the UI still needs to be able to do "msg.loadGestures()" , because I made a "reload gesture" button, which is usefull if you modify a .py and want it to be effective without restarting MRL.
How did the move of the InMoov5.j3o work ?
Ah I forgot to check that..
UPDATE: about the InMoov5.j3o, it is now correctly unzipped into resource/InMoov2/JMonkeyEngine
Now the InMoov2.java needs to be updated as well, for Simulator to have the correct path.
The servo speed in Intro has
The servo speed in Intro has been fixed.
Additionally, state is correctly maintained for servo.
I found when I had to refresh, then look at the servo intro, it would think the servo is not there.
I "refactored" Intro ... and now it works as expected.
Part of this refactor is also simplifying the heck out of Intro. I didn't know how Intro would be used, and I appreciate you jumping into it and trying to do some demos.
You want cause and effect in the webgui with python scripts without Java modification. This would help you as a tool more than anything.
So I have done that.
Intro now only has 2 methods of interest, set(key, value), and get(key)
It acts like a pass through to the webgui. Anything you set instantly the webgui sees the change, you can get info in python.
In the webgui these properties manifest themselves in html as
props.key = value
You get bonus properties too filled in by the Intro service.
When services are created you get {serviceName}IsActive = true.
When the service goes away you get {ServiceName}IsActive = false.
After refresh - intro understands servo01 is active
If I want to see quickly what the state of the props are - i look at properties with this url
http://localhost:8888/api/service/intro
To make logic decisions in the webgui I just use the props
You can set any property in Python
And they will instantly change in the webgui
The Intro Java service works as a pass through for information between Python and WebGui - no updates to Java necessary for changes or additional properties.
Hello Grog, This is nice! I
Hello Grog,
This is nice! I just tested the Intro servo and refreshed the browser, servo is still seen as active.
Thats good!
I noticed, speed is still not fixed though, when attaching the controller, speed changes to Max. I did a fresh install in a new directory with the PR 734
I also noticed that now virtual servo is throwing an error and crashed MRL.
-to reproduce start Intro
-start the servo
-press the button Virtual
It probably should crash at this point.
The crash is a "new edition", because I cannot close the zombies or even the windows. As you can see in the picture below, java is killed in the Window Manager, but the windows are still on my screen, and I cannot close them.
Hmmm... I get worky virtual
Hmmm...
I get worky virtual servo
but i ran through eclipse .. i'll do a clean install shortly .. kwatter merged the change on develop now - i'll be testing web_dev_start.bat in a new dir.
The virtual switch does not have the correct state ... (refresh - go away)
I'm starting to look into the getPanel refresh problem too ..
I also did not have the maxSpeed problem - I wonder if your browser is caching some old files
Hello Grog,Good point about
Hello Grog,
Good point about the cache in the browser, it has solved the virtual crash!
Speed is also worky!
I see in your video that you have only the servo without the VinMoov5.j3o .
I still get both together.
If you make a fresh install in a new directory, try also a full install of all services.
I noticed VinMoov5.j3o got installed in two locations:
1-data/InMoov2/JMonkeyEngine
2-resource/InMoov2/JMonkeyEngine
I am interested to know if it does the same for you.
EDIT:
Shouldn't the file VinMoov5.j3o into resource/InMoov2/JMonkeyEngine/assets/Models/VinMoov5.j3o to work properly?
For sure the path in InMoov2.java is pointing somewhere wrong.
Cool, glad that's all worky
Cool, glad that's all worky now ...
Yup, I get the InMoov standing on a servo
I see in your video that you have only the servo without the VinMoov5.j3o .
I still get both together.
If you make a fresh install in a new directory, try also a full install of all services.
I noticed VinMoov5.j3o got installed in two locations:
1-data/InMoov2/JMonkeyEngine
2-resource/InMoov2/JMonkeyEngine
There are 3 when you use the make_web_dev.bat
It took me a while to track down the VinMoov5.j3o being installed from an InMoov dependency, but it gets to the point that I believe we should remove InMoov from Nixie now. Agree ?
In a pr I'll be pushing I
In a pr I'll be pushing I removed jme's auto-loading its own directory .. and this is were the VinMoov5.j3o gets dumped from InMoov's dependency info.
So no more standing over the servo
I'm also interested in getting rid of this menu from the jme display and implementing its functionality in the JMonkeyEnginge webgui.
I've also got the Servo & Virtual state information in Intro working correctly (beyond refresh).
However, an interesting thing now occurs, where jmonkeyengine can be attached as a controller, and since the servo only understand it can be attached to one controller at one time - it prevents it from being attached to an Arduino :P
On the good side, more stuff is starting to "Embrace the pub/sub" !
I have a plan how to fix this in JMonkeyEngine service so both can be happy.
The getPanel is irrating and at the moment don't know the details of what is happening there that requires refresh.