architecture

how lcs is structured internally.

system overview

lcs uses a modular architecture where each feature is an independent module that can be loaded, enabled, and disabled dynamically.

main.lua
    │
    ├─→ loads config.lua
    │
    ├─→ loads feature modules
    │
    ├─→ manages feature state
    │
    └─→ handles user input

file structure

LogansCameraSuite/
├── main.lua
├── config.lua
└── features/
    ├── freecam.lua
    ├── hideUI.lua
    ├── hidePlayers.lua
    ├── hideBillboards.lua
    ├── hideChatBubbles.lua
    └── ignoreGuiInset.lua

main.lua

responsibilities:

• load configuration
• load feature modules
• create notification system
• handle z key input
• track feature state
• coordinate enable/disable

key functions:

loadFeature(featurePath)  -- loads module via httpget
toggleSuite()             -- toggles all features
showNotification(text)    -- displays notification

loading sequence:

1. wait for localplayer and playergui
2. load config.lua
3. for each feature:
   • show loading notification
   • httpget the module
   • store in loadedfeatures table
4. show loaded notification
5. bind z key

config.lua

responsibilities:

• define available features
• specify feature metadata
• set default enabled state
• define keybinds

structure:

{
    version = "b0.1",
    categories = {
        {
            id = "category_name",
            name = "display name",
            features = {
                {
                    id = "feature_id",
                    name = "feature name",
                    description = "what it does",
                    path = "features/file.lua",
                    enabled = true/false
                }
            }
        }
    },
    keybinds = {
        toggle = Enum.KeyCode.Z
    }
}

feature modules

each feature exports:

return {
    enable = function()
        -- activate feature
    end,
    
    disable = function()
        -- deactivate and cleanup
    end
}

feature responsibilities:

• manage own state
• clean up resources on disable
• handle errors gracefully
• disconnect event connections

data flow

suite activation

user presses z
    ↓
toggleSuite() called
    ↓
suiteActive = true
    ↓
for each enabled feature:
    call feature.enable()
    mark as active

suite deactivation

user presses z
    ↓
toggleSuite() called
    ↓
suiteActive = false
    ↓
for each active feature:
    call feature.disable()
    mark as inactive

notification system

components:

• single screengui (lcsNotifs)
• multiple textlabels (notifications)
• stacking system (push up)
• auto-dismiss (2 seconds)

flow:

1. create textlabel
2. add to activeNotifications array
3. push older notifications up
4. fade in new notification
5. after 2s, fade out
6. remove from array
7. push remaining down

state management

**loadedf

eatures table**:

loadedFeatures = {
    feature_id = {
        module = {...},      -- the loaded module
        config = {...},      -- feature config
        active = false       -- current state
    }
}

tracks:

• which features are loaded
• their configuration
• whether they're currently active

error handling

loading errors:

• wrapped in pcall
• failures warned to console
• suite continues loading other features

runtime errors:

• features should handle own errors
• main.lua doesn't catch feature errors
• allows features to fail independently

extensibility

adding new features

1. create feature file in /features/
2. export enable/disable functions
3. add to config.lua
4. reload lcs

modifying features

1. fork repository
2. edit feature file
3. host modified version
4. load from your fork

creating categories

1. add category to config.lua
2. add features to category
3. categories are cosmetic (for future ui)

future architecture

planned improvements:

• feature dependencies
• feature priorities
• async feature loading
• feature hot-reloading
• feature marketplace