@ Glacierise & xXm0RpH3usXx: thanks guys!
one question though, i skimmed through the thread and i think you said something about making ui’s like CodeFather does.
Yes, the VME ui is completely based on code provided by CodeFather. The way VME writes imgTags is based on the same code as well.
this would mean hiding the default window bar, are you planning on implementing that, too?
No, I am not planning on writing code that will provide the user the option to create a windowless rollout, for reasons explained below.
as far as i saw until now you place those bitmaps in a rollout, but there is still the default window around it?
Yes, there is still a default window around the rollout. This can be changed to be windowless, but you have to make a close button – otherwise you can’t close the rollout (I learned that the hard way ;)). So, if you don’t create a close button, you can’t close a windowless rollout – thus I left the option out of VME (if the user didn’t know to create a close button, then the script couldn’t be closed, forcing them to close and restart max to get the windowless rollout to go away, and that reflects poorly on the VME script). For now, you must hand-code the rollout to be windowless, and it’s just a few lines of code. You can find a code example of a windowless rollout in the VME script – just don’t forget the close button!
okay, if its a copy and paste thing even i would be able to deal with it
i’d love to make some cool ui, but there’s no script to be to it, so probably i’ll just keep lurking then…
You can use RMB or MMB click or doubleclick within the rollout to close it.
Yes, the VME ui is completely based on code provided by CodeFather. The way VME writes imgTags is based on the same code as well.
The code was provided by me
@ miauu: You are correct. The code was written by Kostadin. Codefather provided me a link to the polycount forum where you discussed the code for the UI. I didn’t mean for it to seem as though I was stating ‘codefather wrote this code’. You are the rightful author – and you’re awesome! I actually meant to ask you a question on the polycount forums, but didn’t want to go thru the registering process just for 1 question. But since you’re here now…
I was wondering how I could make an imgTag ‘draggable’, meaning I want to have an imgTag for the title of a rollout and when a user clicks and drags on the imgTag the rollout follows the cursor. I tried various combinations based on the following, with no success:
local mouseLBD = false
local roPos = [0,0]
on VME lbuttonup pos do (mouseLBD = false)
on VME lbuttondown pos do (mouseLBD = true; roPos = pos)
on VME mousemove pos do ( if mouseLBD do (SetDialogPos VME (mouse.screenpos - roPos)))
You can use RMB or MMB click or doubleclick within the rollout to close it.
Good idea! I think I’ll add that into the script!
Hi, TheGrak!
The trick i pretty simple. You have to use “enabled: off” to make the imgtag “draggable”.See the code:
rollout VME “”
(
local mouseLBD = false
local roPos = [0,0]on VME lbuttonup pos do (mouseLBD = false) on VME lbuttondown pos do (mouseLBD = true; roPos = pos) on VME mousemove pos do ( if mouseLBD do (SetDialogPos VME (mouse.screenpos - roPos))) ImgTag it_1 bitmap:(bitmap 20 20 color:white) pos:[10, 10] width:130 height:50 enabled:off -- change the mouse cursor when moving the dialog on VME moved pos do ( setSysCur #move ) -- close the rollout on VME rbuttonup pos do ( destroyDialog VME ))
createdialog VME style:#() width:150 height:100
Thanks miauu! I’ll get to working on the next release! I hope you find some use for my little script!
So, I lied. The VME is going to support nodal programming.
I have been hard at work crafting the next version of the VME. My aspirations for the next version have necessitated that I learn other programming languages (and concepts). I have found that the “inconsistencies and limitations” turned out to be design flaws.
Here is a snippet to chew upon:
The above nodset can be ‘interpreted’ to maxscript, C#, C, or Python(3.x).
I’m imagining a UI dropdown that tells the script how to ‘interpret’ the nodes. This would mean that the nodes built in the viewport are a layer of abstraction that does not suffer from a syntax. In addition to that, if the nodes can be interpreted into code, then code can be interpreted in reverse into nodes. Then the nodes could be interpreted into another language. The VME then begins to serve as a naive IDE inside Max.
More coming soon.
how does it know which line comes first?
i mean, in your example its no matter if it first prints “Hello WOrld” and then adds 1 to i or vice versa.
but there are situations in which you cant switch lines…
does it take into account the position in the bubble?
@xXm0RpH3usXx: Good questions! Here’s a visual response:
Hope that clears things up!
heh, thx for the compliments
but what if we’d got another node between 4 and 5?
it wouldnt have to touch the “do block”, but letting it float freely would leave max with the decision which one comes first, wouldnt it?