guthen / guthscpbase

Base framework for building SCP gmods

👋 Hey there, I am Vyrkx

Also known as Guthen, I'm a 19 year old french Game Developper.

I'm specializing myself in programming in various languages such as Lua, C# & C++.

I'm a garry's mod modder too, mainly ─ but not limited to ─ creating content for the SCP Foundation

🔗 You can find me on..

Steam

guthscpbase's Issues

Entity Breaking: add a configurable blacklist

Summary

Add ability to blacklist map entities from being breakable. Usefull to prevent SCP-096 from breaking SCP-106 containment cell or to avoid SCP-173 from escaping his containment.

Specificities

• Blacklist saved after a modification and loaded at server starting
• Map Entities saved using Entity:MapCreationID()
• Blacklist filename must use the map name : (e.g.: data/guthscpbase/breakable_blacklists/gm_site19.json)
• Superadmins will be able to add or to remove an entity from the blacklist (more likely with concommands)
• Optional: debug mode where the client could see the blacklisted entities with halos (need to send all the blacklisted entities to the client cuz Entity:MapCreationID() is only server)

Add a toggable workaround for `PlayerUse` hook of Playable Piano

Description

Since the original Playable Piano is conflicting with guthscpkeycard and is not maintained by his author since a decade, I should make a workaround script to fix it myself.

It will be toggable in the guthscpbase menu but will probably need server restart to apply properly (specially to disable a workaround).

I also want to make a simple system to eventually add more workarounds in the future (e.g. CPTBase)

Todo

• Workaround system
• Implement workaround for Playable Piano
• Implement workaround for CPTBase
• Add its own Configuration page
• Save & Load

New Config Type : Color

Description

Add a new config type for every module : the Color type.
When used, it will display a color palette for users to choose the color from.
Then, this type will return the color from the variable for each number types.
Here an example of how it would looks like in the config file:

			{
				type = "Color",
				name = "My awesome color",
				id = "beautifulcolor",
				desc = "Configure your own color! For HUDs, menus and more!",
				default = Color(255,255,255,0),
			},

Then, to get colors from this type, we would need to do that : guthscp.configs.{modulename}.beautifulcolor.r , g, b and a)

I'm not the best to explain things, so don't hesitate to ask me if you didn't understood something.

Remaster Branch: Add Reset configuration button for each modules

Description

This button when pressed, will show a modal to confirm if the superadmin player want to erase every configuration fields inside the module. When pressing the "OK" state button, the data configuration file from the module will be erased and every fields will be remplaced by their default values, available inside the main.lua of the module.

Custom Derma

maybe you could start using PixelUI or XeninUI so the Addons look more "Modern"
(could be a config option like you mentioned)

Team Configuration Saving Method

Description

Actually, the current saving method for Team Configuration is to write the IDs of the Teams, basically it's the values of the TEAM_ variables.

The problem which occurs in DarkRP, for instance, is that these values depend on the job creation order. So TEAM_A with a value of 1 could become a value of 2 if TEAM_B is now created above, resulting in swapping the values and our references, which is an unintended behaviour.

Solutions

• Saving by Team Name: not a big fan of this but a solution could be to rely on the Team's Name, the problem is that changing the name of your team would break the reference
• Saving by TEAM_ keynames: I might prefer this approach, this solution handle a direct reference to the TEAM_ variable instead of its value — by using its global name. For example, if we configure TEAM_A, we won't store its value (=1) but its name in the code : a string containing "TEAM_A". We won't have to care if TEAM_A is swapped with TEAM_B, because its keyname is the same as before. Even if we delete our TEAM_A, it shouldn't create so much trouble since _G["TEAM_A"] will return nil, we just have to skip this value in the code. The downside is that we have to loop over _G (which I believe contain at average ~5000 variables) to cache the keynames of all TEAM_ variables, but we just have to do it once at game's start, so shouldn't be a performance pitfall.

Document the Wiki

I have to finish the documentation of the system in the wiki.

Todo:

• Home
• How the Module Loader works?
• Create a Configuration
• Customize the Details Sidebar & Pages
• Creating custom workarounds