[LDCad] Lua - prompt and wait for selection?

[David Manley]

Hi Roland,

another LDCad scripting question for you.

I'm trying to write a script which will loop, prompt the user to select a particular part and then wait until the part is selected before moving to the next prompt/part selection. Looking through the sample Lua scripts, they seem to expect any part selections to be done prior to invoking the macro. But I'd like to have a script which will prompt the user as they go, so they don't have to remember the order in which to select the parts.

The Lua script I am using is invoked as a macro and looks something like this (it has been simplified to assist in understanding its purpose):

Code:

    -- Clear the current selection (if there is one).
  local selected_item_lo = ldc.session.getCurrent():getSelection()
  if (selected_item_lo ~= nil) then
    selected_item_lo:remove()
  end
    -- Prompt for the appropriate part.
  prompt_ls =
  {
    'Select the part/subfile which drives the rotation.'
  }
  linkage_phase_si = linkage_phase_si + 1
  ldc.dialog.runMessage(prompt_ls[linkage_phase_si]);
    -- Loop until an item is selected.
  repeat
    selected_item_lo = ldc.session.getCurrent():getSelection()
  until (selected_item_lo:getRefCount() == 1)
  ldc.dialog.runMessage('Done')

Basically, the intention of the script is to display a message dialog and, once the dialog is closed, wait until the user selects a part. However, when attempting to run this macro, the console open and displays the message

Code:

"linkage_parts_select_gf" execution exceeded the maximum duration of 250ms.

linkage_parts_select_gf is the name of my macro containing the script.

Is there a "proper" way to achieve what I'm wanting to do (i.e. wait until a part is selected) using the LDCad Lua scripting?

Regards,

David

[Roland Melkert]

Is there a "proper" way to achieve what I'm wanting to do (i.e. wait until a part is selected) using the LDCad Lua scripting?

Interesting use case.

At the moment any callback function will block the main gui until it returns (hence the maximum execution time protection).

Only exception are the ldc.dialog calls which will reset the script execution timing.

This also means writing an infinite loop with a message box will lock the program , an issue which will be solved in Alpha 2 though.

A proper way of doing what you want would need a way to setup a callback on selection events.

Alpha 2 has an ldc.event object, which is used to capture mouse and keyboard events for use during the new interactive animation mode, but what you are describing here would need such callbacks during normal editing.

An interesting thing to do though, so I might add something for it.

In the meantime you could solve this by using multiple macros like eg "start", "proceed", "done", "cancel" which the user could use to go trough the stages of the intended process.

If you, or anyone else, has some additional ideas on api extensions please let me know.

[David Manley]

Interesting use case.

</snip>

If you, or anyone else, has some additional ideas on api extensions please let me know.

One idea which struck me as I was trying the diakog/selection method was would it be possible to incorporate a "select part" control within a dialog? The dialog could provide for "N" prompts via a table and a button (?) per prompt which when clicked would hide the dialog, wait for a part/sub-file to be selected and then resume displaying/operating the dialog.

David

[Roland Melkert]

One idea which struck me as I was trying the diakog/selection method was would it be possible to incorporate a "select part" control within a dialog? The dialog could provide for "N" prompts via a table and a button (?) per prompt which when clicked would hide the dialog, wait for a part/sub-file to be selected and then resume displaying/operating the dialog.

I prefer to keep the api low level, this sounds very specific.

I'm thinking about extending the macro setEvent function to include some internal editor callbacks, like:

Code:

macro:setEvent('selectionChange', 'handleSelChanged')

The handleSelChanged function could then do something with the current selection when it's called, a "Select more?" confirm dialog would then be used to finish the work or repeat the selection.

Only thing I'm not sure about is when to make those callbacks, I don't want them to fire all the time.

It should somehow only be triggered when running the macro.

Maybe something like

Code:

macro:waitForEvent()

which will set a flag signaling the scripting engine a macro needs an event to continue.

waitForEvent will not block the script, it will still run to the end, but when the selection changes it will continue trough the handleSelChanged function.

[David Manley]

</snip>

If you, or anyone else, has some additional ideas on api extensions please let me know.

Perhaps add a setHint function to ldc.animation in the same manner as that for ldc.macro? I'm in the throes of adding prompts for different aspects of a rotation (e.g. axis, duration, ...) and I update the hint of the macro to include the current values (e.g. 360 degrees, clockwise around Y for 10 seconds). It would be nice if the hint text for an animation could be set.

David

[David Manley]

If you, or anyone else, has some additional ideas on api extensions please let me know.

Another possible API extension (if there isn't already a way to do this), related to the Interaction menu
1) the ability to query the current interaction "mode" i.e. normal, nested or animation
2) (a) the ability to end the nesting mode or (b) the ability to end the animation mode
3) the ability to set the interaction mode to normal, nested or animation. I'm not sure if there is a use case for this one but if you can query the current mode, it seems to complete the circle to be able to set it.

David

[Roland Melkert]

1) the ability to query the current interaction "mode" i.e. normal, nested or animation
2) (a) the ability to end the nesting mode or (b) the ability to end the animation mode
3) the ability to set the interaction mode to normal, nested or animation.

There is a way to set the animation mode, but currently there is no way to 'read' the current one.

This is because you can do it trough an action, with actions you can call anything inside LDCad which can have a hotkey.

For example, to set nested mode:

Code:

ldc.action('editSes_modeSetNest'):run()

For a complete list of strings like "editSes_modeSetNest" see the main.hkc (key binding) file in the config folder.

[Roland Melkert]

Perhaps add a setHint function to ldc.animation in the same manner as that for ldc.macro? I'm in the throes of adding prompts for different aspects of a rotation (e.g. axis, duration, ...) and I update the hint of the macro to include the current values (e.g. 360 degrees, clockwise around Y for 10 seconds). It would be nice if the hint text for an animation could be set.

I will add a setHint to ldc.animation just like the macro has.

[David Manley]

If you, or anyone else, has some additional ideas on api extensions please let me know.

A longer explanation may be helpful before the suggestion. This post about wanting an animation for a 4 bar linkage started me thinking and fiddling with some scripts to try to come up with a user-friendly point-and-click solution. The thinking and fiddling has been the reason for my recent questions/API suggestions.

As part of coming up with a solution, I needed a test assembly. At one point it looked something like this screenshot.


Leveraging the technique described in your LDCad advanced editing page, I was able to determine how much to rotate the red and light bluish-gray liftarms to ensure the holes in the liftarms were correctly aligned. And that got me thinking. It might be helpful if there were a script which would (a) work out the necessary rotations, (b) show a preview of the rotation and © allow the user to apply or discard the rotations.

The next step was to conceptualize what would be required from the API to be able to write such a script. Here are the resulting thoughts/suggestions.
1) I'm inclined to think that this would require the "prompt/select" capability suggested earlier in this thread (i.e. your macro:waitForEvent() thoughts).
(2) Suggested API addition #1. Add the ability to display/hide the connection points for a part, which would be driven by the data in the shadow library for the part.
(3) Suggested API addition #2. Add the ability to select a part's connection point, visible from thought #2.

With these two additions to the API, it could help reduce/eliminate the need to add temporary parts to a model to help when attempting to align non-simple assemblies.

Happy to discuss further if desired.

Regards,

David

[Roland Melkert]

A longer explanation may be helpful before the suggestion...............

A fully integrated lua oriented editor extension is somewhat beyond the 1.x scripting engine.

2.0 was supposed to be much more script based, making the executable basically a gui orientated rendering engine.

But lack of time, and to some extend motivation, made me decide to go for a 1.7 instead.

I probably pick up 2.0 again at some point, and maybe switch it to a Vulkan rendering engine to make it more interesting as a study project.

That said:
The closed triangle problem has a dedicated native tool, or do you mean you want to solve it fully automatically?

[David Manley]

</snip>
That said:
The closed triangle problem has a dedicated native tool, or do you mean you want to solve it fully automatically?

Yes, the concept I had was for a script to do something like; the user picks the key parts/connection points, the necessary part rotations are calculated automatically, use the animation to preview the result and prompt the user with the option to accept the result (which would move the parts) or decline the result (which would leave the parts unmoved).

David

[David Manley]

If you, or anyone else, has some additional ideas on api extensions please let me know.

I'm wondering about adding to the API the ability to query the clock "tick" unit size for an animation. Knowing this metric would help make some calculations when working out how far through an animation the current time represents.

While using getFrameTime() / getLength() does give the proportion, the challenge I'm facing is getting the 4 bar linkage working when using the "set interval start" at something other than the start of an animation. Knowing the clock "tick" unit size (which differs for normal speed vs slow speed) should enable me to work out the change of angles required between frames.

David

[Roland Melkert]

I'm wondering about adding to the API the ability to query the clock "tick" unit size for an animation. Knowing this metric would help make some calculations when working out how far through an animation the current time represents.

While using getFrameTime() / getLength() does give the proportion, the challenge I'm facing is getting the 4 bar linkage working when using the "set interval start" at something other than the start of an animation. Knowing the clock "tick" unit size (which differs for normal speed vs slow speed) should enable me to work out the change of angles required between frames.

An animation 'frame' event should be self contained, meaning it should render the scene at a certain point in time without knowledge of what happened before.

This because the call can be for any random frame at any time resulting from: skipping,  playing backwards, speed changes, etc.

I'm also playing with the thought of making it multi threaded to allow for more complicated animations needing more then 40ms of work per frame.

That said, you are free to ignore all that and use the incremental approach and use

getLength()/getFrameCount()

To get the 'frame tick' you are looking for.

Or do you mean something else with 'tick'?

Or maybe you where expecting getFrameCount to be .e.g 25 no matter the current play mode.

From the documentation:
"Do note the number does not have to be equal to fps*length as it accounts for extra frames resulting from things like slow motion"

edit:
Or do you need the current interval settings (ofs, length)?
Those are currently not available, I could add them though.

[Roland Melkert]

The challenge I'm facing is getting the 4 bar linkage working when using the "set interval start" at something other than the start of an animation. Knowing the clock "tick" unit size (which differs for normal speed vs slow speed) should enable me to work out the change of angles required between frames.

The 'self contained' thing I was talking about above does allow for an incremental approach, but you would have to 'walk the whole path' upto the current time inside each frame event.

An example of this is shown in the big 8860 animation.

The gear shift portion of that animation needs some of this 'past' information.

I solved it by using 'state data', which is part of the aniTools.luia module.

[David Manley]

The 'self contained' thing I was talking about above does allow for an incremental approach, but you would have to 'walk the whole path' upto the current time inside each frame event.

An example of this is shown in the big 8860 animation.

The gear shift portion of that animation needs some of this 'past' information.

I solved it by using 'state data', which is part of the aniTools.luia module.

By clock "tick" unit size I was thinking getting visibility of the value of the clock tick e.g. when running at normal speed I see a unit size of 0.04 seconds and at slow speed a unit size of 0.02 seconds.

At the time I made that suggestion I had needed that for my 4-bar code to cope with an animation starting at other than time frame 0. The currently released code is based on deriving the next position for the parts using the previous position as their starting point. However, I've since reworked the angle computations for each frame to instead work from the known starting position. This does away with the need to know the clock "tick" unit size. Moreover, I think it will allow me to calculate whether the 4 bar assembly is a crossed or uncrossed configuration (still work in progress). But perhaps there are other circumstances where knowing the clock "tick" unit size is worthwhile?

As I'm treating this thread as an opportunity to bounce ideas, here is another thought for your consideration. In the "start" event for an animation, it looks like the frame time is always 0.0. If the interval start is set, could the frame time in the "start" be set to the interval start value? Or perhaps an API defined for ldc.animation to return the interval time frame start and end values?

Regards,

David

[Roland Melkert]

As I'm treating this thread as an opportunity to bounce ideas, here is another thought for your consideration. In the "start" event for an animation, it looks like the frame time is always 0.0. If the interval start is set, could the frame time in the "start" be set to the interval start value? Or perhaps an API defined for ldc.animation to return the interval time frame start and end values?

I will add functions to get information about the current playback interval.

Probably something like:

Code:

local ofs, len=ani:getTimeInterval()

and

Code:

local ofs, cnt=ani:getFrameInterval()

[David Manley]

If you, or anyone else, has some additional ideas on api extensions please let me know.

I'm exploring whether I can integrate running an animation as part of running a macro and capturing a user reply to the animation. I've got a simple sample case available for downloading as a zip file from BrickSafe. The zip file contains a LDraw model and its Lua script. Note that this sample is deliberately simple - the longer term aim is for more complex cases but it is easier to use a simple case to pose the following questions.

This is the model in the zip file:



The intention is for the macro to take four selected parts and (for this example), rotate the tan coloured pin, green lift arm and green pin around the tan pin so that the green pin is positioned on the blue axle pin. But I want to be able to give the user a preview of the rotation and the ability to accept or reject the rotation.

The premise I had was that I could create animations to show the consequence of a potential rotation and then prompt the user to accept or reject the rotation.

So here are my challenges;
1) I want to run the animation from within the macro. But I''m not sure the API allows me to do this. I can fake it a bit by using actions (take a look at lines 93-95 in the Lua script) e.g.

Code:

  ldc.action('editSes_modeSetAni'):run()
  ldc.action('aniMan_play'):run()

but this will (I think) run whatever the most recently run animation was. Thus if the most recent animation was "Sample/Color fest", it will run that animation. Is there something already available where I can get a macro to "run" a given animation? If not, could something be added to the API to allow it?
2) At the end of the animation, when the animation has been run via the macro (as opposed to being run as an independent animation), if the user accepts the proposed rotation, I'd like to apply the actual rotation to the parts. This is a slight speculation but if I apply the part rotation within the animation's end event, would it be correct to assume that the rotated parts would still be returned to their original position (refer to lines 114 and 115 in the Lua script)? If so, is there a technique to make the rotation "stick" post the end of the animation? If there isn't presently a technique, would you consider adding something (he wrote, waving his hands in the air) to the API to allow suitably designated part transformations within an animation to "stick" after completion of the animation?

Regards,

David

[David Manley]

Having thought about this overnight, I realise that the resolution for what I'm trying to do is to not use an animation.

If I take the core logic from the animation frame script into a separate function and invoke the function from the macro, I no longer need to use the animation to achieve what I am trying to do. The function with the core logic can be invoked by the animation script any way, so I'm not going to end up with undesirable code duplication.

Regards,

David

[Roland Melkert]

... to allow suitably designated part transformations within an animation to "stick" after completion of the animation?

Before an animation starts all the current matrices of the model are pushed onto a stack.

These matrices are restored once the animation is stopped.

But there is a way to apply the current matrices while an animation is paused.

This is done using the animation menu's (right click in animation mode) "Apply animation posOri" option.

[David Manley]

If you, or anyone else, has some additional ideas on api extensions please let me know.

Hi Roland,

I was wondering whether there is any ability to pass arguments to the LDCad Lua script?

Let's say the sub-model scripting source file is defined as:

Code:

<path-to-lua-script>\argv.lua

with (trivial example) the Lua script argv.lua looking like:

Code:

print('#arg = ' .. tostring (#argv))
for i_li = 1, #arg do
  print(tostring(i_li) .. ' : ' .. arg[i_li])
end

Is there any way to supply arguments to the script? e.g. define the sub-model scripting source file as:

Code:

<path-to-lua-script>\argv.lua abc

I tried the above approach but it was unsuccessful so I thought I would check before going any further.

If it can't be done, is it something that could be added? I can see some use for it to pass values to scripts to alter their behaviour e.g. for the linkage animation script, passing the axis around which to rotate the sub-file as a parameter rather than requiring the user to set it when the file is opened.

Regards,

David

[Roland Melkert]

I was wondering whether there is any ability to pass arguments to the LDCad Lua script?

Not at the moment, but I really like the idea.

But I'm thinking to do it in the form of a variable declaration using a new meta, e.g.

Code:

0 !LDCAD SCRIPTPARAMS a='hello world'

or

Code:

0 !LDCAD SCRIPTPARAMS params={a='hello world', b=true, c=123.23}