InvNix: Inventory Shell/Bash
Talia Tokugawa
A simple scripting system within a users inventory for better inventory management.
Nb. just for a person's own inventory NOT for anything else.
LUA scripting might provide some/all of these functionalities, if so then this could be a checklist for LUA implementation features?
Main Aspect: To have inventory "shell scripts".
These would be a new inventory type that allowed inventory manipulation.
Triggered through specific events to cause various actions to happen.
### Script Variables:
Variables available to the script..
* Path - (String) folder location.
* Folder Contents - (list/array/object) list of folders contents.
* Date/Time - (string/number) either a timestamp or unix timecode..
* etc....
### Triggers:
Potential examples.
* Manual triggering - Right click context menu "Run" Command.
* Called - Called from other inventory shell scripts.
* Timed triggers - whilst online the viewer could have a crontab like system.
* Change detection - fired on changes within folder.
### Actions:
Potential examples, I am obviously drawing from *nix shell commands here.
* mv/cp - Move or copy item. e.g.
mv "New Object" "New Object {date}"
rename the item "New Object" to "New Object 2024/11/13"* touch - create a new object. e.g.
touch -nc "Foldercontents"
Make a new notecard called "Foldercontents"* mkdir - create a directory e.g.
mkdir "SNH Halloween 24"
* rm/rmdir - remove/remove folder..
* ls/tree - List folder contents.
* >/>>/| - chaining/piping
* cat - Get details of an object e.g.
``` json
{
"name": "new notecard",
"type": "notecard",
"contents": "This is a test notecard",
"created": "(timestamp)",
etc.
```
* extract/compress - Object/groups as zip/rar/etc. allow for the extraction or compressing of a item/list of items into an archive object.
* booleans/loops - for the doing of stuff.
### Terminal
As an additional idea, You could have a terminal window attached to the inventory to allow for command line access to the inventories.
### Alternatives to Inv Scripts
Rather than having and entirely new inventory type this might work if:
* Executable Notecards - Notecards could be used as the scripts if they had a specific flag or naming system.. e.g. "./foldersort"
* Additional variant to scripts - Scripts already can be switched between lsl and mono.. could there be a 3rd type for "inv Shell"?
### Why this system
There are three main reasons that I have suggested this particular method to achieve this:
* Familiarity - For those of a more geeky nature, near fluency is already there. They getting to start at a near sprint.
Battle Hardened - Why reinvent the wheel?
nix cli is very very well tested so why not borrow from it.* Education - This could help a great many in terms of dipping their toes into CLI usage.
* Additionally :
- By mirroring the *nix systems there is a huge head start in docu.
- Likewise the potential shell scripts that people would have access to that with minor tweaks should work again would be massive.
- Ai Support/training. A lot of people are likely to just ask chatgpt for scripts. Closer to *nix we get the better in terms of training LLM.
### Future possibilities
* At the current community meets there is a lot of discussion over the implementation of a giveinventory function that would goto a specific folder. The best solution for this would obviously be different for each creator and each customer. There is not going to be one solution. The best solution is going to be one that is customizable.
* There would be numerous other things I'd love to see as well.
-For example external sources:
+ obviously text files, feeds etc. would be an easy first. (wget Or curl > nc)
+ If shellscripts were notecard based then you could grab external files to increase functionality.
+ Alternate method of file uploads with wget for textures, ani, sounds, mesh etc. (wget)
+ API Access (Curl)
+ version control (git)
- And Image Resize!! + ability to assign thumbs.
### Conclusions
I know, not the smallest of requests.. as long as I've played Sl inventories have been a "mines worse that yours." discussion point.
Automation for item givers is improving yet there is little improvement to users capabilities to sort. New windows and image thumbs kind of cancel each other out.
Log In
Gwyneth Llewelyn
I'd say that all the above should, at the very least, be
part
of the (allegedly) upcoming client-side Lua-scripting modules...But you should also take a look at the fantastic Lua scripting support on the Cool VL Viewer! Henri has done an outstanding job not only in implementing all the above (and 100x more), but of actually having done that quite a long time ago, and therefore having had months (years?) of testing since then.
You can get the 78-page Reference Manual from the official Cool VL Viewer website: http://sldev.free.fr/CoolVLViewerLuaManual.pdf
Look for page 18 or thereabouts for the section that starts with
Agent inventory related functions
.Henri went further on with his inventory-related functions, of course — you don't need merely to manipulate the assets across folders, you also need the ability to
use
them :) This is provided, to a degree, thanks to the Viewer URIs which can be directly called from within Henri's Lua implementation (e.g. secondlife:///app/wear_folder/?folder_name=<library_folder_name>
to replace whatever the avatar is wearing with the contents in that folder). In other words, his implementation relies on already-existing functionality, and just adds more (much
more...) on top of what the viewer currently does not return. Some
functionality, instead of being "hacked into" the viewer code, is provided through the RLV API (a clever way of isolating potentially "dangerous" code, which might
be the reason why LL is considering
to implement RLV in the official viewer as well).Gwyneth Llewelyn
We already have some information from LL explaining that, unlike what would be obvious, Henri's Lua viewer-side scripting will
not
be used. LL wants instead to use the slightly-stronger-typed Luau dialect developed by Roblox (and which would therefore be slightly more familiar to the massive 600-million-user-base of Roblox). Strongly-typed languages additionally provide another degree of syntax checking at the cost at some more typing, as well as a much faster and optimised compilation step, since the compiler does not need to figure out, on its own, what type a certain variable is supposed to contain; this also avoids hard-to-debug run-time errors (they become compile-time errors instead). Henri's Lua implementation is much closer to "pure" Lua 5.4, where some of the most dangerous ibrary calls have been (deliberately) suppressed. At the end of the day, whatever LL's approach might be, we have no idea
when
or how
this will be implemented, beyond what is already in Canny and on scattered pages on the community forums, so it makes sense (for me, at least) to continue to propose ideas and use-cases for automating viewer-related functionality — and the inventory management is most certainly an area that definitely requires a lot
of improvement!!Talia Tokugawa
(( sory for the formating I was MD but canny doesn't seem to appreciate it.. ))
Gwyneth Llewelyn
Talia Tokugawa, Canny's idea of Markdown is absolutely atrocious!
It's possibly one of the very few Markdown engines I know which doesn't recognise the usage of single underscores for
italics
... :P