Hi Michael,
Setting the mesh angle with a script in the startup folder works great.. Thanks.

Just so I am clear, this "Gaurd Rail" function is "NEW", Correct?

It didn't do this previously.

So, the mesh angle ini setting is obsolete if you can only set it for a current session within the UI. But the new flag you mention could make it relevant again?

(As a side note, I understand the explanation of "Low mesh angle being persistent can cause issues". I just want to understand the best way to move forward)

Thanks again for all the hard work.

Hi Burr,

re:
> Just so I am clear, this "Gaurd Rail" function is "NEW", Correct?

Correct.


> So, the mesh angle ini setting is obsolete if you can only set it for a current session
> within the UI.

It still works as before for values between 10 to 45 degrees.


> But the new flag you mention could make it relevant again?

Yes, the new flag that I'll add will make things behave same as before.

- Michael

Regarding the ini location. If I start MoI from the install location (Program files) Clicking "Edit Ini" from the options dialogue shows a location of "appdata" folder located in the root folder.

If I run MoI from a copied backup location, or my USB install. then the edit ini location shows as the root.

So basically, I have 2 ini locations to keep.

It "Should" just read the root one and be done, yes?

Thanks, clear now on the new gaurd rail. Will look for the new flag also in a future release.

Hi Burr,

re:
> Regarding the ini location. If I start MoI from the install location (Program files) Clicking "Edit Ini" from
> the options dialogue shows a location of "appdata" folder located in the root folder.

Yes, that's the default behavior.


> If I run MoI from a copied backup location, or my USB install. then the edit ini location shows as the root.

If you have copied the moi.ini file into the same location as moi.exe and it has write access to the file then it will use the one that is in the same folder as moi.exe .

When MoI starts up, it first checks if there was a moi.ini file passed in as a command line parameter to MoI.exe, if there was then that's what it will use.

If there was no command-line parameter for the .ini file then it next checks if there is a moi.ini file in the same folder as moi.exe and if it has write access to that file it will use that one.

If neither of those cases are set up then it will use appdata.

Some things to check if you're seeing different behavior in this beta:

- in the previous beta did you pass in a moi.ini filename as a command-line parameter to moi.exe and this isn't set up for the new beta?

- did you copy a moi.ini file into the same folder as moi.exe for the new beta but not done the same for the new beta?

- did you set the previous beta to run with elevated admin privileges (to have write access to the Program Files folder which is denied by default) but haven't got the same set on the new beta?

- Michael

""""""""""""- in the previous beta did you pass in a moi.ini filename as a command-line parameter to moi.exe and this isn't set up for the new beta?

- did you copy a moi.ini file into the same folder as moi.exe for the new beta but not done the same for the new beta?

- did you set the previous beta to run with elevated admin privileges (to have write access to the Program Files folder which is denied by default) but haven't got the same set on the new beta?""""""""



No to all of those, but I have looked at previous backups of previous betas, and they have the 2 ini files. Which means my installs have been using the appdata folder located under my installation location...

This would just be an error on my part and a misunderstanding.

I'll just move my ini location from the root, next to the MoI.exe into the appdata folder located at C:\Program Files\MoI 4.0 beta Sep-10-2020\AppData...

That should straighten me out.

Congratulations on the release and bug fixes !

One remark about the beta period : it would be great to have an elegant way to warn the user about a beta period being just about to end. Of course I understand that in theory one shouldn't do serious work with a beta, but in practice it obviously happens ; and it can be frustrating to be forced to update a piece of software just to keep working on an ongoing piece (as this just happened to me at this very minute :D). Most of the time it is 100% fine, but it can get troublesome when working towards an upcoming deadline, or when cut off from the internet (not sure if the current system accounts for that). I think it would be fair to expect beta periods to at the very least have some overlap of a few days to a few weeks, while giving the user some warnings about the requirement to update soon.

There's no perfect solution to that issue of course, but I feel like it could be handled better than the way it is done at this time, which essentially prevents the user from working for a while. I hope this make sense !

That said, maybe that's just a coincidence on my end ? Not sure if the validity of the beta period is per user, or tied to the releases/established calendar dates.

Hi pior, yes usually the way to help out with that is to have a fairly long overlap period of several months between when a new beta is released and when the previous one expires. Usually that's what I try to do, but that didn't happen with this release, sorry about that.

I had been hoping for a while to have this be the last beta and trying to wait to release it until everything was all finished.

- Michael

Ha, understood - indeed I don't remember it happening during earlier beta periods, true.

- - - - -

Back to comments !

I find myself using the Image feature a lot as I mostly use Moi for 2D drafting these days. It works great overall but there are a number of little details about it that could be smoother.

- I think it would be great to be able to interact with images present in the scene without having to go back to the Image tool manually. Maybe some key combo allowing to select the image planes just like regular objects (key+click), or some clever mouse input (triple or quadruple click), or some UI widget which would enter Image mode from there.

- Once in the Image tool there should be a way to duplicate a current image. And even better, doing so in the scene state it is currently in. Either by somehow interacting with the image object itself by copy/paste, or through a duplicate button. Without that, making a duplicate of a current image involves importing it again and placing it in the viewport again, which is annoying and breaks the flow of work. At the moment if I need to have, say, 5 duplicates of a rough draft to make 5 clean variants from (which, as you might guess, is precisely what I need to do for some design work at the moment :D), I need to import and place the rough 5 times. I should really only have to import once and then duplicate from there. It seems minor but in practice it is quite a blocker, especially since each time the image needs to be "drawn in" from corner to corner meaning that for a perfect duplicate the user needs to remember to enable object snap too. It really does pile up :)

- The "Transparency" value (with 90 being very transparent and 10 being near opaque) is counter-intuitive. It should be labelled Opacity, with 10 being very transparent and 90 being near opaque.

- The numerical input field is error-prone, especially for fast users used to keyboard input. I understand that it is the same as everywhere else in the program and that many users are probably used to it, but imho it could behave much better (of course I don't know which part is tech limitation from the UI API and which part is intentional behavior here.)

First of all, there is really no need for the big keypad to show up for anyone using a keyboard (which I assume is 99% of the user base). It seems good in theory but in practice it is laggy (shows up a few milliseconds late) and visually distracting ; and any power user will just type with the physical keys of their keyboard anyways (either top row or keypad). I believe the visual keypad should be an option, probably best turned off by default. It is also stealing the cursor (making the caret disappear) which breaks the visual confirmation that the field is ready for keyboard entry so that's another way it goes against the habits of power users used to the subtle but universal visual clues of any OS.

Also, the visual keypad shows up when a field is highlighted and disappears when it isn't. It "makes sense", but it is strange for such a big UI element to be turned on by a positive input that is usually not a toggle (click), but *also* turned off by the same input (another click, removing the field highlighting). It gives the impression of a UI element that is always "just about to break" so to speak, which is problematic UX-wise.

An alternative (on top of the option to have it show up by itself or not) would simply to have a button that opens it up (see mockup). This would have the advantage of being more practical for tablet users, since hitting big buttons on screen is easier than hitting text entry fields.



Lastly in the case of the Image tool in particular, the entry field sometimes fails at displaying the current Transparency value of the currently selected image in the list.

I hope this helps !

Thanks for the comments pior!

It is possible to turn off the numeric input panel using a setting in moi.ini, it's in the [UI] section:

[UI]
<...>
DisableNumericInputFlyout=n

Set that to DisableNumericInputFlyout=y and it shouldn't show up.

- Michael

I would like to add that it is inconvenient to search for images when they do not fit in the list of inserted images.
When there are a lot of them, in order to find the right one, you have to disable/enable viewing of each image.

PS. Zoom with the mouse wheel behind the scene is this normal?

I've been thinking of having images listed in the scene browser instead of in a command like it currently is.

- Michael

Hi WN,

re:
> I would like to add that it is inconvenient to search for images when they
> do not fit in the list of inserted images.

If it helps, it is possible to enlarge the image list. To do that edit the Image.htm file which is in the Commands sub-folder inside the MoI install.

The list height comes from this CSS at the top of the file, the line marked with >>>> <<<<

			#FilenameContainer {
				width:100%;
>>>>			height:5.1em;       <<<<
				-webkit-box-sizing:border-box;
				margin:0.05em 0.15em;
				overflow-x:hidden;
				overflow-y:scroll;
				border:1px solid #AAA;
				background:white;
			}

If you change that to something like height:15em you'll have a larger image filename list area.

Lists of things that might get long like this are probably better to have in the scene browser rather than in a specific command. The Image command pre-dates the existence of the scene browser which is why it didn't go there to start with.


re:
> PS. Zoom with the mouse wheel behind the scene is this normal?

Sorry, I don't understand this part. Could you describe what's going on a little bit more please?

Thanks,
- Michael

If you move the cursor behind the scene, for example, over some button, and rotate the mouse wheel, you can see the zoom change in the scene.
I just saw it now. It seems to have always been so, my inattention, sorry.

>If you change that to something like height:15em you'll have a larger image filename list area.

Michael, thank you so much, it's much more convenient.

Something has become wrong! :)

Wow, nice update, thanks very much.

Hi Pilou, inside your %appdata%\Moi\Startup folder there will be files named XX Scripts.js and/or XX Scripts Full.js , can you please post them? maybe you have an old version.

Oh, also please let me see what you have for your %appdata%\Moi\Scripts.menu.htm file.

Did you happen to recently add a script and have any punctuation characters in its filename like a ' quote character?

- Michael

Here the 2 files...
https://moiscript.weebly.com/uploads/3/9/3/8/3938813/2scriptsmenus.zip

Don't remember to add some special names of scripts..

Thanks Pilou, those seem to be ok.

Can you please go to a command prompt window and use this:

dir %appdata%\Moi\commands > output.txt

And then send me the output.txt file? It will have a listing of all the files in your appdata commands folder so I can see if there is a problem with any of the names.

- Michael

where must be this output.txt ?

Not more easy for me to send you the commands folder by mail? (810 Kb )
because my Windows CMD says dir is not found! :)