Page 2 of 16 FirstFirst 123412 ... LastLast
Results 16 to 30 of 239

Thread: LScript "Wish List"

  1. #16
    Newbie Member
    Join Date
    Oct 2003
    Location
    Santa Cruz, CA
    Posts
    8

    What I'd Want In LScript

    Hi -- I am *SO* glad you asked.

    I'm a mostly nonprofessional user, software engineer by day, pixels for my art wank friends at night.

    I would love to be in your beta list for reviewing changes and doc. API's and languages are my favorite things. -- [email protected] .
    ---------
    Ok.

    I like to use LScript to build complicated models algorithmically, and I'd *like* to use it to build complicated scenes and animations algorithmically as well.

    So what gets in my way?

    1. I've found quirks -- probably bugs -- when trying to create geometry from nothing. I had to start with a "stockpile" of quads and my Modeler script manipulated those. It just seems like LScript is pretty loose.

    2. Documentation. I couldn't find a list of all the available commands, sorted out in any complete fashion. If I remember rightly, I somehow guessed the command "imageload" or "loadimage", to build up a lot surfaces programmatically.

    3. Yes, anything you can do from the GUI should be scriptable. (It seems like Maya has this story architecturally pretty tight.) In Modeler, would be nice to have that command-execution view like in Layout, so you can see what the LScript would be.

    And, since you said Shoot for the Sky here, I'll go ahead and say it:

    JavaScript would be a nice scripting language for LightWave. It's the language that Adobe has standardized on for their applications, and that alone makes it worth considering. But, really, it is well suited for application scripting. And you can buy a book about the language from the corner bookshop, which can save you some work.

    Hey, you said shoot for the sky!

    -- David Van Brink / [email protected]
    -------------------
    Its origin, and
    purpose, still,
    a total mystery.

  2. #17
    Greets,

    Lately I've been doing a lot of UI programming. Hopefully from that point of view, you can understand why I'd want these features:

    • Some sort of Timer function.
    • Keyboard up event. (right now, it's just keydown as near as I can tell.
    • Mouse Wheel Access
    • Forward a keypress on to Layout. (The interface I've made stays open and active all the time, preventing keys from making it to layout. I'd like to be able to forward them on in case somebody has a different kb layout than I do.)
    • Double buffered graphics. A bunch of 'drawline' commands takes way too long.
    • Change mouse cursor
    • Mouse Hover event (for creating tooltips, etc...)
    • Master Class support in Modeler for non-modal plugins


    Cheers, and thanks for listening.
    Go TEAM VAD!! \/

  3. #18
    Lsid wish list

    Iíd used Lsid heavily last week. So Iíd like to post some of my notes on the limitation I came across. Most of these are more of an issue simple because we canít edit the interface in Lsid after we have exported. The interface I made had 115 buttons in 7 tabs, just to give you an idea what I mean by heavily. Itís pretty frustrating that I canít go back to Lsid and make changes. But oh well on to the notes.

    Requester type:
    You can not specify what type of requester you are making. IE: non model master interfaces

    You should also be able to specify what is resizable.

    Variable name and Saveing order:
    You also have no control over what variable is assigned to a button for export. IE: They are all numbers c01, c02 ,c03.
    You can not reorder the buttons. You can in Lsid but itís not saved and itís not exported in that order.

    So on top of no way to reorder them for export we canít name them the way we want.

    Missing components:

    Ctlstate
    Ctlmenu
    Ctlsurface,ctlfont
    Ctllistbox

    Control mangagment:
    Ctlgroup: We can parent items to others but they do not save or export as groups.
    Ctlposition: Resizing buttons is really bad because the button height is so easy to adjust at the same time. Restrict height editing in some way and allow us to edit ctlposition directly.

    And of course please can we have sliders and minisliders that is not limited to just integers.


    I hope these notes are useful. 8)

    Scott Lange
    www.steelronin.com

  4. #19
    Code Muppet evenflcw's Avatar
    Join Date
    Feb 2003
    Location
    Stockholm, Sweden
    Posts
    2,642
    Snapping inside LSID would be very welcome too. And in addition to that it would be cool if their were some templates so you could make your plugins/scripts conform to the same standards as the native panels do. Because of the lack of snapping, the last time I used LSID (some time ago) I prefered to just dot out the controllers I needed and then fixed all positioning in the texteditor. Not the way it was meant to be, I hope. An alternative to LSID would perhaps be a WYSIWYG Lscript editor/debugger combo run directly from inside LW (with crash and loop protection ).

  5. #20
    I am Jack's cold sweat Karmacop's Avatar
    Join Date
    Feb 2003
    Location
    Bathurst, NSW, Australia
    Posts
    2,117
    I think this has already been said but I'd love to see java working as lscript does now. Much less work than implementing your own language/interpreter/IDE etc.

  6. #21
    Valiant NewTeKnight Matt's Avatar
    Join Date
    Feb 2003
    Location
    San Antonio, Texas, USA
    Posts
    13,055
    Quote Originally Posted by evenflcw
    Snapping inside LSID would be very welcome too
    Something like the editor in RealBasic would be nice!
    UI / UX Designer @ NewTek
    __________________________________________________
    www.pixsim.co.uk : LightWave Video Tutorials & Tools


  7. #22
    Newbie Member
    Join Date
    Oct 2003
    Location
    Santa Cruz, CA
    Posts
    8

    quad stockpiling

    Here is an excerpt of comment from a script, supporting the reiterated request:
    "We want to be able to script everything that Modeler can do, please."

    This is either a documentation issue or a functionality issue, either way...

    // |
    // | Turns out we cannot, in LScript, create a point and
    // | add it to the TEXTURE map. This is tragic! So we rely
    // | on having a stockpile of quads already in the map.
    // | We can change their UV values, and will. But they
    // | have to already exist.
    // |
    // | So, before running script, you must have bunches
    // | of unconnected quads sitting around, all TEXTURE
    // | mapped.
    // |

    --> david
    -------------------
    Its origin, and
    purpose, still,
    a total mystery.

  8. #23
    Once again, I would like to thank everyone for the continued feedback and let you know that we're still reading them!

    Art
    H2MW Consultants, LLC
    e-mail: [email protected]
    http://www.h2mw.com

  9. #24
    well i was going to add to this list but everyone else has covered my request

  10. #25
    Registered User carllooper's Avatar
    Join Date
    Apr 2004
    Location
    Australia
    Posts
    79

    LScript 2 C

    Why can't a plugin written in LScript be machine translated into C?

    In principle, a plugin written in lscript could be machine translated into one written in C, but the result wouldn't be any more efficient. The speed benefits associated with C have more to do with the greater set of choices that C makes available to the programmer. But once a program is written those choices are no longer available. It is the programmer that produces optimised code through the choices he or she makes. All the language does is provide more or less choices. And relative to LScript, C provides more choices.

    So a machine that takes a plugin written in LScript and trys to optimise it through rewriting it in C would have to decide what sort of choices could be made had the plugin been written in C instead of the choices that were made having been written in LScript. And it would have to make the right choices, ie. those that lead to more efficient code rather than less.

    In other words the machine would need to possess the same cunning and ingenuity we otherwise associate with programmers.

    Carl

  11. #26
    This is my understanding.

    LScript is an interpreted language, even when you compile it.
    The bottom line is that a compiled C plugin runs about 10 times faster than LScript.

    If someone could somehow translate it, it would run faster.
    I just think there isn't enough interest by programmers to do it.
    Those with C plugin skills don't need the translation.
    But it's an interesting idea.

    just my two cents.

    And I'm sure that Art of H2MW will correct me if I'm totally mistaken.

    Somewhere, over the rainbow....

  12. #27
    Registered User spud_q's Avatar
    Join Date
    Jun 2003
    Location
    Wellington, New Zealand
    Posts
    77
    I'm not sure as I understand why you want LScript to use C. Am I wrong in understanding that Lightwave plug-ins are written in C? Since you have a lot more power and options when using the SDK and you know C, why use LScript. I'm dying to get started writing plug-ins but I use LScript because I don't know C and have no C compiler. Am I wrong about all of this?

  13. #28
    I interpreted the discussion to be about having a utility that could translate LScript (which is just text) to C which you could then compile (free C compilers are available). Once you got the LScript working, you use the utility which would make a new source file and when compiled it would run 10 times faster.

    Not a bad idea.
    Not sure it can be done.

    It would definitely have to be a little smart to detect the type of architecture and then use the appropriate structure.

    Somewhere, over the rainbow....

  14. #29
    Registered User carllooper's Avatar
    Join Date
    Apr 2004
    Location
    Australia
    Posts
    79
    > If someone could somehow translate it, it would run faster.

    By way of analogy - one can shoot a video of something and shoot a 35mm film of the same thing. Certainly the 35mm film will exhibit higher resolution than the video. But this does not mean translating the video to film will result in a higher definition image.

    On the otherhand, working with video is a lot simpler than working with film.

    Carl

  15. #30

    Talking

    I ask for:
    Non-modal panels in generic Layout LScripts. (or please tell me how to do this)

    I'm also seeing new plugins (like joytrol and that new painting program) that should be able to join the view port list (at least in layout). These new views could be added at the end of the list and would be locked in place, and have the maximize and other controls (zoom/move/rotate) the normal views have. The LScipt or plugin could then disable view controls that do not make sense for that script/plugin.

    As already requested, knowing the X/Y X/Z XYZ Y/Z etc coordinates of the mouse in a viewport is important. Also the mouse press event that occured (Layout & Modeler) i.e. LMB-down, keyDown, keyUp, MMB-up etc. Along the same lines increase the combinations of hot keys. i.e.ctl-shift-a ctl-alt-a etc But at least give LScript that capability to intercept the keys.

    Somewhere, over the rainbow....

Page 2 of 16 FirstFirst 123412 ... LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •