Taxonomy/Site structure

[Martin-Pitt]

Here is a proposal for how the site could be structured:

• Scripting Portal
  • Getting Started
    • Quick introduction for beginners
    • How to create and write scripts
    • Development environment with VS Code Extension
    • Link directly into tutorial in SLua/LSL Language section
  • Features
    • Avatar
    • Communications
    • Combat
    • … and more
  • Guides
    • How to script a Car/Boat, Strategies for dealing with multiple llHTTPRequests, etc. Long form guides/tutorials
  • Recipes
    • How to script a Chair, How to script a Door, llHTTPRequest integration to external API via Vercel proxy, etc. Short, usecase specific step-by-step guides
  • SLua/LSL Language (below is for SLua; Somewhat based on Suzanna’s guide)
    • Getting Started
    • Tutorials
    • SLua vs LSL
    • Types and variables
    • Operators
    • Flow Control: if, while, for, repeat
    • Functions
    • Tables
    • Metatables and metamethods
    • Objects
    • Error handling
    • Libraries
    • Event Handling
    • Timers
    • …?
  • Standard Library (or Scripting Reference)
    • Categories
    • LLEvents
    • LLTimers
    • ll* Functions
    • Luau Libraries
    • Events
    • Constants

The idea is to also have a site-wide toggle (or limited within the Scripting Portal) where the user can switch between SLua and LSL. With something like <If> components in the mdx files to show conditional content, such as for code examples. Likewise the site navigation would also flip based on the toggle, for example the SLua Language menu would flip to LSL Language and show relevant links to how LSL works, like states and stuff. The Standard Library would also be able to flip, for example not showing any of the libraries that are specific to SLua/Luau etc. I'm not sure how to do approach this yet but maybe we could fill the site navigation and then use JS/CSS to update the navigation based on the toggle.

Now you might be wondering why Scripting Portal is at the top, for the SL Create site we should expand it to cover the whole sphere of Content Creation eventually, such as Building, Meshes, Textures, Fashion, Architecture / Level Design, etc. But for now we should focus on Scripting.

Features are high level articles that explain a feature as well as act as a mini-portal by sending the user to a relevant sub article or collating standard library functions, events and constants together for quick access. The Combat2 article on the wiki is a good example of how to do this. Vague on the details above the fold but rich with links for more detailed information.

Guides are long form articles that help you do or understand something. Such as the complexities in scripting an SL vehicle (which can take different creative forms, from the humble Physical Linden Vehicles, Advanced Linden Vehicles with Raycasting, Custom Physics (not using the Linden vehicle functions), Non-Physics (like my mech walker), Wearable Vehicle (pure attachment based vehicles that manipulate avatar movement), …)

Recipes are short, focused how-to guides that walk a reader through completing a working example of a specific task. This should be particularly great for beginners or any scripter that wants to tackle something very specific.

SLua Language/LSL Language will be swapped based on the site-wide SLua/LSL toggle. This contains the tutorials and guides specific to the language itself.

Standard Library (or Scripting Reference or Reference?) would be a reference to all the libraries, functions, events, constants etc.

What do you think? Does this proposal make sense?

[WolfGangS]

Maybe a section for caveats and footguns? And or a section for incompatibilities between slua and lsl

[Martin-Pitt]

Have started work on the restructure. Tweaking sidebar and changing folders with placeholder/stub pages.

Re: incompatibilities, might be able to cover that in the LSL vs SLua article or a sub-page.
I'd prob need more details about caveats/footguns that wouldn't be covered by that.

[Martin-Pitt]

I've pushed to github pages with a preview branch at: https://martin-pitt.github.io/create/script/
so that you can see what the draft PR #19 of my nexii/site-structure feature branch looks like currently

I've updated the entire site structure and navigation with a new taxonomy. It's slightly tweaked from the list as I started implementing it.

There are many new stub pages created in place.

I've fleshed out the features list more, I don't think it is quite complete yet. Sorta want to re-order/cluster features in a way that makes more sense, mostly move all the object-related features together, but not sure yet on this.

The LSL Language nav is barebones, just pointing to the LSL Portal for now since that's going to be more comprehensive. Can look into fleshing this out as well once we implement a Scripting Portal-wide SLua/LSL toggle/dropdown.

Speaking of, I'll need to figure out a way to dynamically swap the navigation — I think I can give navigation items custom properties and then just use some CSS to show/hide them. Then customise the sidebar with a toggle that saves into sessionStorage.

I've tried to fill out some pages with comments/directions for anyone who wants to flesh out a stub page and also popped basic lists into the reference for the libraries

Sidebar autocollapse defaults has been tweaked to meet needs of newbies vs. veteran scripters. So have opened the starter folders and the later reference sections so they are easily scrollable and accessible on a single click.

Guides/Recipes has been swapped out for single pages, which could link to hidden pages. This is because these pages could have way too many pages to list out. Features could also get the same treatment unless we work down to a smaller list.

I've disabled the generation of pages for SLua functions/events/constants for now, this is because we don't actually have SLua definitions file to generate pages with and SLua doesn't quite have the same approach to it as the functions exist in the ll and llcompat, and the events through LLEvents. The definitions from LSL don't map quite the same way, at most llcompat is the closest 1:1 match. Another approach we can take is to load definitions data dynamically onto pages or into components to render them server side or client side.

---

We could also try out sidebar groups like on docs.astro.build:

• …?
• Language
• Reference

I'm not sure what to name the first group, but it would have: Getting Started, Features, Guides, Recipes

Could split them out into their own sidebar groups though:

• Introduction
• Features
• Guides
• Recipes
• Language
• Reference

But feel like 3-4 sidebar groups what you want at most.