MSPhysics 1.0.3 (16 October 2017)
-
What version of Internet Explorer do you have installed?
-
-
Anton, are you using ENV variables to obtain the path?
-
Thanks Anton. It's odd because the program installed without any trouble.
Is there a specific order the AMS library and MS Physics should be installed? I ask because I installed MS first, then AMS second.
-
Bryan, the order doesn't matter. I tested it on Win7 with IE11 and it works very well. I could reproduce what you have only by renaming/removing the CSS folder. So I don't know. It looks like the dialog.html can't determine the CSS paths or the CSS folder or the files within it are missing.
-
Brian, I'll test it out on my Windows 7 with IE11. So far it works fine on my Win7 and IE9.
Thomthom, as far as I recall I don't use ENV variables to obtain the paths. I rather modify one of them, particularly ENV['PATH'], so that
msp_lib.soknows where to look for the required Dlls and this is only necessary on the Windows side. And instead of overwriting the ENV['PATH'] variable with the new path(s), I simply append another path to it. I don't think that should hurt other plugins or anything. Of course, I acknowledge that it would be a good idea to reset it to original paths after all the loading is done.
Edit: On the OS X Side I use install name tool to set the relative load path to the required dylibs. This can be done with xCode by adding a post build script. -
@faust07 said:
Hi Anton, do you see an opportunity to revise your MIDI-Piano for version 0.9.0?
Hi faust. I updated the MIDI piano a few days ago. It should work fine now
-
Hi Anton. Thank you very much! I've found it already. I enjoy the magic sound. PituPhysics updated his MSPhysics models too. So there is much stuff to learn.
On my side, on Win7 and Win8.1 with IE11 MSPhysics works like a charm (except to record Replay...).
-
All paths and files are verified in the right location. Everything seems to work except the UI menu tabs.
-
Bryan, if everything worked fine, your UI should have looked like this:
The screenshot that you posted above resembles a UI with missing CSS/JS files, which make it look/work improperly. Can you once again ensure that all of these files exist in your SU2015 plugins folder because at the moment I have no idea what could be the other cause:- MSPhysics/css/chosen.css
- MSPhysics/css/tabs.css
- MSPhysics/css/dialog.css
- MSPhysics/css/expander.css
- MSPhysics/js/jquery.js
- MSPhysics/js/chosen.js
- MSPhysics/js/chosen.js
- MSPhysics/js/ace/ace.js
- MSPhysics/js/ace/ext-statusbar.js
- MSPhysics/js/dialog.js
- MSPhysics/js/expander.js
-
The only difference I see is that the file path I have includes "Roaming"
I really appreciate you taking the time to help with this. I'm sure we'll figure it out. Thanks again.
-
Announcing 0.9.1.
Refer to CHANGELOG for info: http://www.rubydoc.info/github/AntonSynytsia/MSPhysics/file/CHANGELOG.mdFaust, the save Replay data to model should be working now.
Bryan K, I think the dialog displayed improperly because HTML files used HTML5 DOCTYPE deceleration. Try this version as it might be fixed here.
-
Thanks Anton. Will do.
-
Thanks for the improvements! But still have some problems:
- Full Screen Mode is not properly stored in MSP UI (still active but no check mark in the box).
- If one will store a large simulation in Replay there should be an information about the processing in the status bar. It could be that minutes nothing happens and the user doesn't know what's going on.
- there are problems to save and to open model files with large simulations stored (- No temporary space available, - partial the access to the directory in which the model is to be saved is denied by the system, - bug splats, - SketchUp crashes etc.)
-
Thanks for feedback, faust. I'll see what I can do about it. I was thinking about saving replay data into a separate file (that would be placed right where the model is), but hesitated because I was worried that two files would make it inconvenient. However, right now I'm thinking that saving Replay data into a separate file won't be a bad idea. You have any thoughts about it?
-
Yes that is a good idea. These data should possibly be stored in a subdirectory with a copy of the model to ensure that the model geometry and the replay data match later. A warning that by changing the Physics-relevant geometry no replay is possible, would be good.
-
Faust, I'm thinking of making it simpler. The file would be stored at the same location of the model, named [model_name].mspr. It will load whenever the associated model is opened, and be written to whenever the associated model is closed (if replay data is changed). If for instance the geometry doesn't match or the data becomes corrupt, it will display an error message, and then erase the associated mspr file. I want to avoid creating subdirectories and saving copies of the model because it might make it a little complicated. If the user wants to make changes to the model, they could first make a copy of the model and the associated mspr file, then proceed making changes.
-
Okay faust, I updated it. Upgrade to 0.9.2 and replay data would be saved to a separate file.
-
my sketchup 2016 crashes when starting the simulation... don't know if i'm just wrong... without putting any parameters...i just click the play button... then boom, a bug splat T^T....
-
Anton, regarding separate replay data file:
after long tests and reducing my ice-mountain-model to the minimum the following results:
Small models with moderate simulations work very well (up to 15 - 20 Mb mspreplay file size).
Large models with much physics simulated and emitted objects (mspreplay files larger 20 Mb) work until you save and exit the model.
Opening the model again, crashes or stops during loading the replay data. The replay file is then lost.
The completely reduced file example (in my post with questions and examples) after saving Replay data, exit and reopen the model Replay runs but nothing happens.
In the test file you can see an other problem too - the viewport problem with emitted objects if you try it often enough. Running the simulation the viewport goes, comes back, running replay the viewport stays away. (think that some emitted object fly into space with high speed before end of its lifetime ...)
Thanks for your efforts!
Advertisement