[Addons Application] SinningSaint's Second Developer Application

[Alex 'Sinner' Saint]

In-game name: Alex 'Sinner' Saint/Saint 'Peccatum'/SinningSaint/ Asmund Oddrun
Steam ID: STEAM_0:0:442142081
Age: 18
For how long have you played on our servers?:
2021-2022 around 2500 hours +
What country are you from?:
Iraq
Time Zone:
GMT+3
Do you have a mic?:
Yes.
Is this your first application for Developer? If not, link previous ones:

Thread '[Addons Application] SinningSaint's Developer Application'

Jun 17, 2026

In-game name: Alex 'Sinner' Saint/Saint 'Peccatum'/SinningSaint
Steam ID: STEAM_0:0:442142081
Age: 18
For how long have you played on our servers?:
2021-2022 around 2500 hours +
What country are you from?:
Iraq
Time Zone:
GMT+3
Do you have a mic?:
Yes.
Is this your first application for Developer? If not, link previous ones:
First App.

Have you received any bans?:
No bans, only warns all older than two years.

How confident are you with GLua? (Rate yourself 1-10 using rating guide):
Using the guide I'd say I am 5-6, I am able to make...​

• Alex 'Sinner' Saint
• Replies: 1
• Forum: Denied

Have you received any bans?:
No bans, only warns all older than two years.

How confident are you with GLua? (Rate yourself 1-10 using rating guide):
Five to Six.

Do you have any experience with Git?:
I am much better at it than I was when I submitted my first application, but still a beginner.

Do you have previous experience as a Developer for GMod?:​

Since my last app I've worked on improving my skills by mainly making the cooking addon something that could be used on its own.
Github link
I now understand how to properly contact the client when it comes to net messages and I've fixed the net expolit.
I've ensured that the addon checks the player is an admin first, and aswell that the entity the player is requesting is an ingerdiant/fooditem, if the player is requesting something else, the addon will simply not spawn anything in.

The reason I kept the spawn menu(but redesigned it) is due to how the addon is made, the good part of this addon is its ease to edit, being able to add any model as a food item (while ofc prop verisons of the model can still be used), and have it be useable, instead of needing to make more files for each food item.

How do I do this? by using the model itself, the entity fooditem_saintscooking by default has a prop burger model that does nothing and only uses the backup eating effect, but when given a model that has been placed in the sh_saintscooking file in the ingeridants table, it will act as a completlty diffirent entity, and get its own effect.

This is something which can be changed easily by any dev to add or remove or change the effects of any item, to add recipes as well and to remove them if need be.

I'd like to note, I am aware that my graphic design choices are questionable, I am not very good at design but I try to improve.

I have removed some features, I've removed the ability to spawn in the stove/pan/cuttingboard ect from the f4 menu due to the security risk it presents, as its easier to check if something is a fooditem since its going to be forced into the fooditem entity, i cannot ensure the same will happen with the stove/pan ect due to them having their own classes.

I've removed the recipe menu part due to it often breaking, I wasn't able to fully grasp why as it would work at times but stop at others.
I do hope if I spend time as a programmer in CN I'd be able to hone my skills and be able to understand bugs much better, but that bug for now has stumped me.

last but not least, I've spent a good chunk of time reworking the code so it can make sense, adding comment lines, making var names reasonable and removing timers and replacing them with functions, I've also made it so the pan doesn't auto eject, you can pause the cooking and resume it and the stove would remeber the progress, but taking the pan out early could result in raw food.

and here is the showcase!​

---

So.. is this the only addon? Yes, I spent most of my coding time on this addon, I attempted to make it useable as much as possible, but recently I've noticed what am attmpting to do is recreating a system(cooking) within a giant system(Vcraft), this is simply not something that would be fessiable by me, as what the addon is missing is a hunger bar, scavanging, scavnging levels and cooking levels ect. and if I attempted to recreate that, It wouldn't be as high quality as the current VCraft is.

But that does not mean my addon is "bad" or not useable, the idea is there and I could change my code to be usable within VCraft, and I feel like I would be able to do so.

Should I have spent the past month making smaller addons? probs, I got carried away, but since I am stopping my insane overscope on this addon, I thought I might aswell submit an application and see if this addon can show my improvement.

In the case it is denied, I would spend my coding time on making smaller addons instead of a large addon.

How many hours can you commit to developing per week?:
8-10 hours.

Why do you want to be a Developer? What can you help us with?:
I am a first year second year in computer engineering and due to the very lackluster curriculum colleges have here, I wouldn't be able to learn much, they have only really taught us basic C++ and purely console programs, I wish to use this as a learning experince of what it is to be a dev in a real enviorment and how to work alongside other devs.

I do plan to tackle the devtracker for S65 mostly to fix the bugs that are affecting RP and to add the small things that massivly make RP better.
I am looking for all sorts of feedback regarding these addons and how I write code in general as I was unsure where to attain said feedback so I applied abit earlier than I had wanted but I had reached abit of a roadblock so I am unsure if I am making mistakes or not.

Last thing I'd like to note is that I am a very fast learner.​

 

[Auburn]

Some things I notice in your food repo

• In autorun/sh_saintcooking.lua you repeat a lot of code for handling health alteration and player messages. You could set the stats as attributes and generalise the behaviour to reduce code repetition and make it easier to add said behaviour to other food items
• The recipes look up the ingredients display names and not their internal identifiers (keys). This makes it hard to change things down the line and makes lookups more complex and intensive. This should be changed.
• The naming scheme is inconsistent. Some instances use camelCase, some use all lowercase, and some use PascalCase. Try to aim for consistency in your repo to avoid syntax errors. Also you typo cooking as cookin a lot.
• Giving recipes and ingredients numerical IDs isn’t very intuitive. It’s hard to know what gets used where. It would be better to give them descriptive names for readibilities sake.

I may have misread some things or misunderstood some behaviour, as I am out drinking at the moment. It’s just some things I noticed at a brief glance.

I do like how you used custom functions in the food code. It’s a good way of enabling custom behaviour for specific food types (as long as proper validation is done to ensure the function exists and is valid before execution).

 

[Alex 'Sinner' Saint]

In autorun/sh_saintcooking.lua you repeat a lot of code for handling health alteration and player messages. You could set the stats as attributes and generalise the behaviour to reduce code repetition and make it easier to add said behaviour to other food items

I hadn't thought of this, and I attempted to do it but I noticed something.
Since I'll replace the normal ply:ChatPrint() with another function like toChatPrint() I'll still be using a line of code and it wouldn't reduce it, but I get the fact that generalising it might be better, but then there would be more vars than needed, as for the eating function
I'd have to add another line for the sake of a clarity var, so there isn't just a random five in a function being called.

I might of misunderstood what you meant, and if I did do tell me as I'd love to improve this part of the code, I've found it abit weird myself.

The recipes look up the ingredients display names and not their internal identifiers (keys). This makes it hard to change things down the line and makes lookups more complex and intensive. This should be changed.

This is a very good point I didn't think about, I attempted to use their keys but saving that inside the pan then inside the stove proved to be very difficult, instead, I moved down the cookinrecipes table, and did it like so:

Meaning even if the name was changed it wouldn't break anything. it can be seen here.

The naming scheme is inconsistent. Some instances use camelCase, some use all lowercase, and some use PascalCase. Try to aim for consistency in your repo to avoid syntax errors. Also you typo cooking as cookin a lot.

That I am guilty of, I am trying to go towards camelCase, but when I started coding I used PascalCase and I sometimes do Pascal without intending to, I have tried to fix some of that when I applied this time around. and regarding the cookin and cooking, cookin refers to file level/gobal things, while cooking is used for any function or local things, thats what I aimed to do, but I get that, that would only make sense to me but I'll refrain from doing stuff like that in the future.

Giving recipes and ingredients numerical IDs isn’t very intuitive. It’s hard to know what gets used where. It would be better to give them descriptive names for readibilities sake.

Only ingredients have IDs, and they have them so it can be lined up with the foodeffects table, I could make them strings, but I perfered numbers as it can be searched up easier

by just searching up the id of the ingeridant, I can find its food effect much easier.

Thank you for the feedback!