secondlife / secondlife/create

Taxonomy/Site structure

Open
#15 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
MDX
Stars
12
Forks
7
Avg merge
2h 53m
Merged PRs (30d)
1

Description

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?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No files or tests are named. Start by reviewing the current site structure and navigation, then compare it with this proposed taxonomy; done means the information architecture, SLua/LSL toggle behavior, and scope of the initial Scripting Portal are agreed.

Written by the indexing model from the issue text.

Assessment

Tech stack
markdown
Domain
documentation
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.