A Week's Worth of Work

2026-07-24 - Peter

It has been a little over a week with the new vault

with the new vault and there has already been so many changes and improvements that I can barely remember them all.

Everything has been migrated into the new vault structure and all the old migration data has been verified and then summarily removed from the project.

The website has been vastly updated

Just today we added a feedback form top right on the menu, allowing you to both like/dislike pages/notes and leave private comments for me regarding specific pages and/or topics on that page.

The questionnaire

The past couple of days we have been refining all the micro-interactions there will be between all the multitudes of functionalities in the framework. I have no clue how far into that part of the project we have come, but I just started out joking that we should do 10.000 questions to the professor. We are around 1800 questions in by now. I think this is actually a very important part of the project, because it reveals all the micro-issues that needs to be made decisions on and we also find new ways to do thing too. Every day we work on the project, something takes a new direction.

The powershell script

and all functions within are now autonomously run and managed by Codex (ChatGPT's local client) and it manages all updates to files and scripts and data in general. I do put my grubby hands into things every now and again, but it is mostly managed by Codex now.

One of the more exciting work processes

We have also made a night-time run of various tasks for Codex to handle, which can take time.

Some tasks run often, others less so. Tasks can be:

It only fixes spelling errors or such directly, but any other changes/suggestions are readable in a report

After it completes for the night, it shuts down the computer automatically. We tried hibernation at first, but for some reason that only kept the computer hibernated for about an hour, before it woke up on its own, so now it just forces a shutdown instead. The reason for this is, of course, to save money, but also because it usually only takes Codex about half an hour to do its various night-time tasks.

As we continually make these micro-changes, small things keep cropping up, so it is nice that Codex this way keeps everything more or less on track and cleaned up while we are running.

Split-personality Pinky-shim

We also decided to split the Pinky-shim in two. Some logic just need to be running in the Pinky-shim, because it needs to run at the games cadence and might not need to reach into the brain for simple decisions or data. Running anything through the Brain will require a lot of extra steps before an answer comes back, so having some data and decisions closer to the game engine, which does not need complex logic or need to be passed by any plugins, is just faster and more effective. It also allows the Pinky-logic (e.g. converting data to the game's data format) to run much faster as .net 10+ and affects the game engine much less, so the in-session Pinky-shim basically just gets and puts data between the game engine and the external Pinky-shim; aka Pinky-companion.

Reducing any processing power usage inside the game engine session is critical to reduce the pressure on the game engine itself. Oxide and Carbon both run inside the game-server process and thus directly impacts the performance and cadence of the game engine.

In a rough mock-up test back in March, more than 600 item exchanges were performed across over 100 spawned player inventories. That narrow test ran at roughly 1,000 times the speed of comparable Oxide logic. Of course I no longer have the results or tests, because I was just playing around back then, not really thinking about documenting progress. That concept (actually documenting progress) came months later.

More logic than ever

We have however since then filled in about so much overhead logic, that I suspect that 1.000x speed increase will be heavily reduced, but as long as it is more than 2x faster, it will still be significantly faster and so much more capable than Oxide and Carbon; AND will have a significant reduction on the game engine pressure! I hope this will help to reduce much of the stuttering, that so many current modded game servers are suffering under. The overhead logic is however very important, since that is what will help make the framework more secure and much less error-prone as well as perform many of the automatics that is supposed to make life for devs much easier. The hope is that the framework will handle basically all the low level functionality and decision making, so devs "just" need to make simple plugins with declarations for what they need of information and want it to do and how the plugin should be triggered, and the framework does the rest.

Triggers

Plugins need a trigger, because they will only need to run, if their trigger is, well, triggered. Triggers will need to be as specific as possible, so they dont just run when anyone's health is changed. This is one of the inefficiencies of Carbon and Oxide; that plugins run on basically any subscribed hook; and then the plugin evaluates whether it needs to run. Forcing 50 plugins to run on any hooks is just not exactly the epitome of efficiency. Having the plugins define better triggers (multiple triggers is possible) and in some cases they can actually define triggers that also performs a very simple action, so they dont have to actually run the plugin code, if it is only that trigger. E.g. a trigger that responds to players going below 50 health with a specific warning message. There should be no reason to trigger a full plugin's logic just to send a simple message, if no other actions need to be taken, so just add that simple action in the trigger instead! Everything is still logged and because the framework knows the trigger belongs to your plugin, it will log the execution of that trigger under your plugins log.

The logic is simple

Plugin code could be expressed very simply. E.g. a minigame where you just have to survive till the end inside a shrinking zone:

Minigame.create("Last Circle")
  .players(2..20)
  .arena("Circle Arena")
  .eliminate(Player.outsideZone)
  .zone(Shrink.to(2m).over(180s))
  .win(LastPlayerStanding)

That is the intended beauty of ADK: the plugin declares the game; the framework owns joining, countdowns, UI, boundaries, elimination, cleanup, rewards, and awkward cases involving someone disconnecting at precisely the funniest possible moment.

You can choose to add custom loot as reward for survival, maybe define it for last three players and many other things too, with just a few lines of declarations/code. All the other logic regarding where to place the minigame arena and other relevant information; that is handled automatically by the framework by simple inference, like the arena size based on a randomly selected arena from predetermined locations; since none was defined.

Well.. that is a long enough blog post. I'll end it here for now. I could go on for many hours talking about in how many ways this project is shaping itself together into something beautiful.