Can someone confirm a bug in quadrify via Maxscript? (sample script provided)

#1

I’m having an issue using quadrify via maxscript. If I use it from the ribbon manually, or even in the script listener, it works as expected. If I issue the command in a maxscript, it deletes faces.

Am I doing something wrong, or is there an issue? I’m on Max 2020.3.

Here is a sample to test:

verts = #([84.7432,49.8489,0],[-71.148,69.4864,0],[-97.432,-7.85498,0],[-42.7492,-64.9547,0],[-3.77644,-10.8761,0])	
faces = #(#(5, 3, 4),#(5, 1, 2),#(5, 2, 3))	
	
testmesh = mesh numverts:5 numfaces:3

for v = 1 to 5 do meshop.setvert testmesh v verts[v]
for f = 1 to 3 do meshop.createpolygon testmesh faces[f]
update testmesh

convertto testmesh editable_poly

referencemesh = copy testmesh
referencemesh.pos.y += 200

max modify mode			
select testmesh
polytoolsmodeling.quadrify false false
#2

Appreciate it if someone could verify this bug. All you need to do is run the included script and see if the two meshes have the same shape.

#3

When I execute the code the objects are not the same(one face is deleted).
When i execute the code line by line the objects are the same(one edge is removed, but no faces are deleted)
When I execute all lines, except the last one at once, and then I execute the last line the objects are the same(one edge is removed, but no faces are deleted).

#4

Thank you Miauu!

I think there’s a bug in quadrify. I can’t think of a reason why it should execute differently, or give results inconsistent with using it via the user interface(ribbon->modeling->geometry(all)->quadrify all.

#5

No, it isn’t a bug.
Many ribbon functions behave diffirently with modifier keys being pressed.
Run your script without pressing Ctrl key and it will work as expected.

#6

That’s very interesting. Thank you for the insight!

It does indeed work if I execute the script via the editor menu and not using ctril+e to execute. If I add a sleep(2) to the script so that the control key isn’t being pressed when the quadrify call is made, the error persists. It must be looking at the keyboard buffer rather than the current state.

It may not be a bug per se, but I’d argue it’s very bad design at least. The quadrify function accepts arguments, so any options should be passed in rather than polling the keyboard, which as I’ve demonstrated is unreliable and potentially undesirable. It also means that functionality is missing since you can’t force the behavior you get when pressing ctrl.

Is there a way to flush the keyboard buffer via maxscript to avoid this?

#7

put it before the function call
(dotnetclass “System.Windows.Forms.SendKeys”).flush()

#8

Thanks for the help.

Unfortunately this code errors out complaining about windows being undefined: – Unknown property: “windows” in undefined

I’m not familiar enough using dotnet in maxscript to know why or to fix it. I spent a while searching online for any hints but made no progress on getting it to work.

Something like this would be fantastic if it worked.

#9

quotation marks are your problem
this forum became pure trash after redesign

#10

Fantastic! It works with regular quotes.

Thanks again, this is a huge help for me.