Full Version: V4 beta Feb-27-2019 available now

Show messages:  1-15  16-35  36-55  56-75  76-95  96-115  116-135  …  216-218

Hi stefan, ok that's the normal place where it should be.

So I think the difference in behavior with the meshing dialog is due to a setting inside moi.ini which you had set on your Mac but not on Windows. The setting is in moi.ini under:

[Mesh Export]
<...>
PersistSettingsBetweenSessions=n

Change that to =y and hopefully you should see the same behavior as you used to on your Mac.

To edit moi.ini you can go to the Options dialog, General section and push the "Edit .ini file" button.

- Michael

---

Hi Michael,

the line was not in there, so I added it with the y parameter, but when re-starting MoI it has no effect.




Regards
Stefan

---

Hi Stefan, it's a bug in MoI v4 in writing the mesh settings. It escaped notice until now because most people running MoI v4 have previously run v3 on that machine as well and v3 got those settings populated how they are used to.

So the way it is supposed to work is that the settings for Display = "Shaded, etc.." , Output type and welding are automatically saved (but they aren't that's the bug) but the other numeric ones are not automatically saved (since they can depend on the scale of the particular object) unless PersistSettingsBetweenSessions=y .

So for the moment to get it working how you were used to, delete that PersistSettingsBetweenSessions=n and add in these 2 lines:

[Mesh Export]
<...>
Expanded=y
Weld=y

It should read those in ok, it's writing them out that is busted. In the next v4 beta I'll have it fixed so it will be writing the settings out same as v3 did.

Thanks for reporting the bug! It was a little bit of collateral damage still left from the v3 to v4 porting.

- Michael

---

Hi Michael,

thank you very much! It is working now.

Best regards
Stefan

---

Hi Michael,

In the latest v4 Beta, Feb-26-2019, I've come across another "scroll wheel" bug when using nodeeditor, similar to the previously reported one, which you seem
to have corrected from the previous Beta. The correction is appreciated. The bug also occurs in the previous Beta.

There are two manifestations. The first is a scroll wheel "hole" in the nodeeditor screen, near the upper center of the MoI screen, down maybe 2 inches.
The nodeeditor screen is partially overlapping the MoI screen. (It is not too hard to find, but some scroll/zooming of the depth of the ne screen may be needed.)
Normally, mouse wheel action in the nodeeditor screen causes it to scroll and zoom. In the "hole" area, the MoI screen scroll/zooms instead.
Second, nodes dragged and dropped into this "hole" area fly off, and out of view, to the upper left corner of the nodeeditor screen.
Scroll/zooming the ne screen permits the nodes to be dragged back into the ne screen box.

So the easiest way to find it is some trial and error ne zooming, and then scroll wheel action on the upper center area of the ne screen.
When MoI scroll/zooms instead of ne, the "hole" is found.

- Brian

---

Hi Brian, I can't seem to find the scroll wheel hole. Can you please post a screenshot of how your MoI window and Nodeeditor dialog window are arranged with the approximate location of the hole marked?

I'm testing with this version: nodeeditor.v.1.0.rc3.2018.03.09

Does your version possibly generate some additional HTML elements that are positioned on top of the node editor's main <canvas> element?

- Michael

---

Hi Michael,

The good news is that it seems that my slight modification to Karsten's recent basicFunctions.js for dropdown html documentation, (so the dropdown would work for "Light" colored version of nodeeditor), caused the mouse scroll wheel "Hole" in nodeeditor.

I restored basicFunctions.js (11/2/2017 version) to nodeeditor/nodes/extensions/libs, and the "Hole" is gone, (and the dropdown does not work with "Light" or "Default Dark" version.)

Karsten's recent basicFunctions.js circa March 10th or March 11th, does NOT cause the "Hole", and dropdown only works for "Default Dark" version.

On the off chance that it is of interest, here is a .png with the "Hole" located directly above the enlarged Output node. (The "Hole" is still there if the Output node is not there.)

- Brian

(Karsten has some new code for me to try...)

---

Hi Brian, is there a .zip file anywhere with the node editor version with the scroll wheel hole in it?

I can check to see if it is possible to solve it by an adjustment MoI's mouse wheel message routing code or not.

Thanks,
- Michael

---

Hi Michael,

Here is the requested zip file.

To demonstrate the mouse scroll wheel "Hole" in the nodeeditor canvas, place the subdirectory "libs" into the nodeeditor/extensions folder.

The "Hole" culprit is basicFunctions.js 1/13/2019 3:35 PM, which includes near the beginning of the .js, under docupath, ...("indexhtml?scheme=Light","")+"nodes\...
[My addition of ?scheme=Light introduced the "Hole" "bug", and allows dropdown documentation to work with only the "Light" ne version]

A more recent BETTER basicFunctions.js would be to rename and use basicFunctionsKarstensMarch13Trial, which works for both Light and Default Dark nodeeditor versions. (Karsten added [0]) This version ALSO has the "Hole".

A renamed basicFunctionsDarkOnly-NoHole enables the dropdown documentation to work, default dark version only, and does not have the "Hole".

The Documentation folder, which also goes in the extensions folder, just holds the dropdown documentation Sweep.html, with a bit of proofreading,

and the construct2.js extension, which goes in the extensions folder, adds a new Sweep node. [Neither a problem as far as I know.]

- Brian

---

Hi Brian,

re:
> To demonstrate the mouse scroll wheel "Hole" in the nodeeditor canvas, place the subdirectory
> "libs" into the nodeeditor/extensions folder.

Using nodeeditor.v.1.0.rc3.2018.03.09, I didn't see any already existing extensions folder inside the main node editor folder, should I add it in there?

Could you maybe package up the entire node editor folder with the hole problem active so I can make sure I've got it all set up ok?

Thanks, - Michael

---

Will do Michael.
- Brian

---

Copy of my nodeeditor directory, under %apprecs%

- Brian

I'll delete it after you get it...

And thank you for all of your help!

The version of basicfunctions.js is Karsten's with latest modification, good for Light and Dark nodeeditor, but it has the "Hole".

[7zip deleted. Snaggit13 was the problem]

---

Thanks Brian I got it, I'll take a look in just a bit here.

- Michael

---

Hi Brian, I'm not able to locate the scroll wheel hole but over here your nodeeditor is showing with a dark background, not a light background like in your screenshot at http://moi3d.com/forum/index.php?webtag=MOI&msg=9266.62 .

Is there something I need to modify to get the light background or additional HTML documentation set up so the scroll wheel hole will manifest?

- Michael

---

Hi Michael,

Hmm, I have the "hole" both at home computer, and at work computer, in both Light and Default Dark nodeeditor, with the basicFunctions as in the uploaded 7z file.

MoI Hotkey for Light mode is: CTRL+ALT+N
moi.ui.createDialog( 'moi://appdata/nodeeditor/index.html?scheme=Light', 'resizeable,defaultWidth:680,defaultHeight:420', moi.ui.mainWindow );

MoI Hotkey for Default "Dark" mode is: CTRL+ALT+M
moi.ui.createDialog( 'moi://appdata/nodeeditor/index.html', 'resizeable,defaultWidth:680,defaultHeight:420', moi.ui.mainWindow );

My monitors are both Samsung. Home monitor is high definition U28E510D, model code LU28E510DS/ZA.
Just tried another Samsung monitor at home with # LS27D360 HSY/ZA, and have the same "Hole".

Logitech cordless mouse M510.

In Split view, the Hole seems to be absent.

The "Hole" is usually at the top center of the nodeeditor canvas, in 3D, Top, Front, or Right views. It is at top center, when a new ne canvas is opened.
If the canvas is moved left, the "Hole" moves right. And vice versa. Hole may not be associated with proximity to the red vertical MoI axis.

- Brian

I did not notice any "Hole" in the Feb26 Beta until March 12, 2019... and the "Holes" association with the nodeeditor dropdown doc basicFunctions changes...

---

Hi Brian, I still haven't been able to get the hole to happen over here.

Does it make any difference if you have Options > View > "Show view controls" turned on or off?

Does it seem like the hole is about the same size as that little view controls toolbar with zoom/pan buttons on it that's at the bottom of viewports?

- Michael

---

Thank you Michael.

The hole is about the same width as the view controls toolbar. It has always been on.

Your size questions triggered the following:

The Snaggit13 window, which is minimized as a thin sliver at the top of the screen, is also the size of the "hole".
The hole occurs below the minimized snagit13 window. Sliding snaggit13 horizontally causes the hole to move the same.
Closing Snaggit13 eliminates the "hole" problem!

- Brian

(I'm going to miss snaggit:-) but it can be closed, and reopened when needed.

---

Not necessarily for v4 but two features I think would be golden!

1. Some kind of notification of a conversion of a solid to joined surface. Even turning the Joined surf text at the top right to red would be useful. Sometimes I destroy a solid and I do not even realize until much later when undoing is a pain. It's especially painful after a fillet, where there is no visual indication that something went wrong- everything looks like it worked but you do not have a solid.

2. Local symmetry mode when manipulating points for surfaces with points visible. I was able to do it by mirroring the curves for half of the object and then seeing the loft result update, but I think that it would be really useful to have something more direct. You can get the most interesting shapes I've seen, using loft flow and point manipulation, it's a shame :)

---

Hi Brian, that's great you found out what's going on, that was a tricky one! Thanks for keeping after it and tracking it down.

- Michael

---

Hi nameless, both of those are definitely on my radar for future work.

I have what I hope will turn out to be a good idea for displaying warning messages at the end of a command, I'm eager to experiment with it after v4 is settled down.

- Michael

---

Show messages:  1-15  16-35  36-55  56-75  76-95  96-115  116-135  …  216-218