Lua basics

heyvern · Post by **heyvern** » Tue Jul 29, 2008 4:39 am

Idea: The lua console can at least access relative paths when printing lua errors. If I could figure out how to access these, like make each cause an error and somehow return those paths to an index Razz , then I could automatically find all of the script names in the 'Tools' folder.

Interesting idea... I don't know how this might work... I don't know if you can trap the errors to the lua console in AS so there might be errors popping up in the lua console in AS.... I've never tried it so you're on your own there.

.

Works good so far, but if I uncomment the io.lines bit at the end, I lose the 'path' and first two lines of the 'read all'. I'm guessing that this is running into the automatic garbage collection of lua. But I may be missing something else.

No, the lua console has a text limit. It can only display a certain number of lines when using the "print()" function. When it goes past that amount those first lines printed get erased. It is working properly.

On a side note... you will have the same problem I had with line enders. I'm getting unrecognized characters printing at the end of the lines. You may have to "reprocess" tha the _tool_list.txt file to a string for the script to work crossplatform. I had this annoying problem with my save animation scripts.

Best bet would be to extract the paths and names of the tools from each line and build a table then the the line enders won't be an issue until you need to write the file back.

-vern

synthsin75 · Post by **synthsin75** » Tue Jul 29, 2008 12:37 pm

I haven't noticed those line enders on my PC, so I'm sure I'll need someone on a Mac test things out. I figured I'd need to process it anyway for the UI dialog I have in mind.

I have no idea how to get a script's path, just sort of brainstorming there. I guess I'll end up having to have the user select each individually. I was hoping there might be a 'open next dir file' function so I could find unknown scripts, but I never found anything along those lines.

heyvern · Post by **heyvern** » Tue Jul 29, 2008 8:00 pm

Getting the path is very simple.

A path is just a simple text string. That's it. Nothing special at all. You have the names and initial path of the tools from the _too_list.txt file. To find the path to a specific tool just use regex to strip off the _tool_list.txt name on the path and add on the name of the tool from the tool list file (plus the .lua extension).

You can find any other path the same way by removing and adding bits on to the end of the initial path.

Easiest thing to do would be to take that original path from the _tool_list and strip it down to the root "scripts" path, the path to the scripts folder, and then keep that as your base "path" and just add on what you need to get to other folders, tools, menu, utility etc etc.

-vern

synthsin75 · Post by **synthsin75** » Tue Jul 29, 2008 10:20 pm

Yeah I understand that much. What I mean is getting paths for scripts that I don't know are in the 'Tool' folder. Any new scripts dropped in there won't always be on the '_tool_list.txt'. If I could somehow find those, I could automatically add them to the tool list.

If I had a function that could open files with a 'wildcard' segment, I could get these. What I mean by 'wildcard' is that the path "...\AS\scripts\tool\*.lua" would try to return any path that fit those parameters. So far no luck.

I'll probably resort to just having the user select the new scripts from an 'open' dialog. It's just that relying on them already being on the tool list kind of defeats the purpose of this script since you could just do the changes while you're in there.

-------------------------------

On another matter, I'm having a little trouble figuring out the tables. I'm thinking I kind of need to work backwards, from the lowest child table up. So:

Code: Select all

line={type, name, key}   --numbered lines
group={line a, line b,...line n}   --numbered lines indexed by number
tooldata={group, color}   --group color indexed by group name

I don't know yet if I'd be better off rewriting the whole tool list or doing replacements. Depending on how much the user wants to change (group names, resorting, etc) it may be more efficient to just write the whole thing over.

Also I'm not sure if there is any way to make a dynamic dialog UI. If the dialog can't be updated as the user selects and inputs stuff, then I'll have to set some definite number of fields. May have to have a pretty large dialog to enough entries.

Just some thoughts, I'm no where near needing most of this yet. For now I'm just working on how to read all of this into usable variables/tables, and then I'll work on the method of writing to the file.

Thanks for all the pointers.

heyvern · Post by **heyvern** » Tue Jul 29, 2008 11:28 pm

synthsin75 wrote:If I had a function that could open files with a 'wildcard' segment, I could get these. What I mean by 'wildcard' is that the path "...\AS\scripts\tool\*.lua" would try to return any path that fit those parameters. So far no luck.

I'll probably resort to just having the user select the new scripts from an 'open' dialog. It's just that relying on them already being on the tool list kind of defeats the purpose of this script since you could just do the changes while you're in there.

I still don't see this as a problem. Don't try to do everything in this script to start with. If the script file is not in the _tool_list.txt then don't even bother with it.

If the user has files in the script folder that are NOT in the tool list file then they should drag them out (easy enough) and INSTALL them using your script. Problem solved. Later if you figure out a better way you could add it in.

On another matter, I'm having a little trouble figuring out the tables. I'm thinking I kind of need to work backwards, from the lowest child table up...

Tables are very tricky and complex. Study tables first. Play with very very simple examples in a test script. There are bunches of ways to populate tables in lua. You are going to be much better off if you understand how tables work BEFORE trying to use them with your script. Start small. When it works with something simple and you understand why and how it's working it's much easier to expand that knowledge to something larger.

Table order does not exist in lua. Tables are unsorted. The order that you create a table is not going to be in that order when you access it later (unless you use numbered IDs for accessing the table fields).

You have to come up with ways to sort the order of the table either by the ID or alphabetically or by some other means. I can't go into the description of that here, besides there are many better tutorials for that on the web. that mushclient site has an excellent tutorials for tables and table sorting.

Also I'm not sure if there is any way to make a dynamic dialog UI. If the dialog can't be updated as the user selects and inputs stuff, then I'll have to set some definite number of fields. May have to have a pretty large dialog to enough entries.

The dialog us "updateable". but don't try to do too much all at once on the first version. Keep it simple. Just start with adding say one single new tool. That would mean opening the tool to install and writing it to the _tool_list.txt file.

The key to this is to start simple. If it works simple, then you can add features. If you can get the script to open a tool file somewhere on the hard drive, write the name of the tool to the tool list and save it... that's a huge success. You can build on that simple starting point. Plus even at that point it is useful.

-vern

synthsin75 · Post by **synthsin75** » Tue Jul 29, 2008 11:39 pm

Yeah, I always have trouble trying to think five steps ahead. Thanks for helping me stay one step at a time.

heyvern · Post by **heyvern** » Tue Jul 29, 2008 11:54 pm

synthsin75 wrote:Yeah, I always have trouble trying to think five steps ahead. Thanks for helping me stay one step at a time.

I have the same trouble. I want ALL the features I have in my head. The trouble comes later when you have like 50 bazillion things that COULD go wrong it's hard to tell which error is caused by what part of the code. Work in small chunks then link them together.

-vern

synthsin75 · Post by **synthsin75** » Wed Jul 30, 2008 12:53 am

I had found out by accident that a script can run automatically at startup, but just figured out how to duplicate it. I guess this would do much the same as the ToolPrefs huh?

I could have my script check for the tool list path on startup, and if not found, ask for it. But I may need an auxillary script to do this as I'm not sure if this autorun and normal use can be done in the same script.

I keep getting sidetracked by these oddities. Hopefully I'm learning something useful on the way.

synthsin75 · Post by **synthsin75** » Wed Jul 30, 2008 3:00 am

I'm pretty sure you can grey out unused buttons, so if I have the chain: type>name>key, I can use tool, button, or spacer as the type. Choosing 'spacer' would grey out the 'name' and ' key' entries.

I'm thinking I could simplify it more by not having a special 'group' entry, but just add it as another 'type'. In this case I would use the 'name' field but grey out the 'key' field.

The question is, how would I incorporate a color picker for the 'group' type? I'm thinking that the easiest way would be to just have a picker on each line that is only utilized with the 'group' selection. Or preferably, I'd rather the color picker just 'appear' when the group type is chosen.

Or if I could grey out a color picker for the other selections, that would work as well.

I intend to test all this, so only a yes or no answer is plenty. This will help me figure out how I want to set up my tables.

Thanks.

heyvern · Post by **heyvern** » Wed Jul 30, 2008 4:46 am

I'm pretty sure you can grey out unused buttons, so if I have the chain: type>name>key, I can use tool, button, or spacer as the type. Choosing 'spacer' would grey out the 'name' and ' key' entries.

I don't know if you are talking about buttons in the pop up for the script or the buttons in the tool palette.

Graying out buttons is done in the TOOL script itself. The button or tool is active or enabled based on the "IsEnabled" function before a tool is selected. For instance a layer tool always works because EVERYTHING is a layer. But a "flip points" tool would be "disabled" on a bone layer, no points. It's not a vector layer. Don't worry about that. I wouldn't worry about picking group colors either. That can be done later. Working with the color object in AS is tricky and hardly worth worrying about at this stage. Just use the defaults already in the _tool_list file. This is just my opinion but I think maybe you're thinking too far ahead.

I would like to see a simple very simple, working prototype that can write out a "demo" _tool_list.txt file, even if it's just a copy of the one in the tool folder... then you can let me test on the mac for any line enders problems.

I had found out by accident that a script can run automatically at startup, but just figured out how to duplicate it. I guess this would do much the same as the ToolPrefs huh?

What kind of script? A tool script?
All tool scripts run automatically at startup. That is how the scriptprefs work. They are built in to the AS script interface. As soon as AS launches all the utility scripts, tool scripts, buttons... they all get "loaded" or initialized. This is why if you have bad code in a tool script, you will get a lua console error launching AS. The tool is loaded and AS didn't like what it saw. This happens even before anything else happens like picking a tool or opening a file.

I could have my script check for the tool list path on startup, and if not found, ask for it. But I may need an auxillary script to do this as I'm not sure if this autorun and normal use can be done in the same script.

Once again I would not bother with this. Don't have it do anything until the user makes the request. Don't get too far out ahead of the BASIIC functionality of the script. If you try to do too much on the first go you get bogged down, overwhelmed. Keep it really really simple.

You should be able to do a prototype without anything fancy. No color pickers, no lists of tools etc etc. Just a simple dialog to open a tool somewhere on the hard drive, radio buttons to choose if it is a vector, bone or layer tool and then an OK button that backs up the tool list file, and writes the new tool into the existing tool list file. Simple.

Even if that seems simple it is still going to take some effort.

-vern

synthsin75 · Post by **synthsin75** » Thu Jul 31, 2008 2:37 am

I know. I spend all day at work away from my computer with time to think up this stuff, but I only have a little time in the evening to try it out. Too much time to think, not enough time to do.

Just tested whether lua could read/write png's, and it's a no go. Scripts and icons will still have to be dropped into the 'Tool' folder like always. Oh well, one less thing.

Edit: Wooohoooo!! I can move PNG's after all!!

This also means that I can move scripts into the 'Tool' folder without having to read them in. I can just get the script names from the path, since this is the name the tool list matches anyway.

So the user will be able to select a script from another location on the hard-drive (and this can be stored as the default unzipped scripts location). This will be automatically moved to the 'tool' folder and added to the tool list. At least this part is easier than I'd imagined.

Now I can do that simple add-on management script you suggested. No hotkey changes yet, just automatically adding it to the tool list. I just need to figure out the UI dialog now. I'll go with your idea of having just check boxes for 'button' or 'tool' and others for group ('draw', 'bone', 'fill', 'layer', 'camera', or 'workspace'). May not need 'camera', but i know there are some workspace buttons out there.

This'll still take me awhile, but I'm always thrilled to find out I can actually make a script do what I thunk up.

Any idea if C API functions are available in AS?

heyvern · Post by **heyvern** » Thu Jul 31, 2008 4:29 am

can you tell me how you moved the files? What code did you use? I just want to make sure it's cross platform.

-vern

synthsin75 · Post by **synthsin75** » Thu Jul 31, 2008 5:12 am

Oh sorry, in my excitement I forgot to mention it. I used 'os.rename(old path, new path)'. Using this it copies to the new location. If I also used 'os.remove' it would actually be 'moved'.

If C API were available, I could read all the file names in the 'tool' folder, but this will let me just require the user to add using my script if they want the future hotkey support.

heyvern · Post by **heyvern** » Thu Jul 31, 2008 6:57 am

Holy cow! os.rename...

I remember trying to use the "os.diffTime" to create a "double click" but never got it too work. I never realized there were such cool functions in that area. That is handy.

-vern

heyvern · Post by **heyvern** » Thu Jul 31, 2008 7:02 am

I have no idea about C API. All I know about that is that lua is integrated into applications using C "hooks" or compiled libraries somehow. I don't think once it is compiled in the application (AS in this case) you have access to C libraries... just a guess. It's out of my realm of knowledge.

From what I've learned there are many other libraries or add ons that could be added to lua and be part of AS but it's up to the developer to do this. I don't think there is any way to build on that once it is compiled into AS.

-vern