Sandbox Logo
27 August 2020

Lockdown Progress

Source 2 is still eluding us but here's some stuff I've managed to get done without it.
Garry Newman
I was hoping to have different stuff when I posted this blog. I didn't want it to be another UI and console post. But guess what, that's what you're getting. 

I'm still working on Source 1, trying to work on things that will transfer when/if we eventually get Source 2. I've done quite a bit over the last few months that should transfer pretty good.. gamemode, entity, console, ui, hud, code sandboxing, console commands, console variables, rpcs, properties etc.

I know Source 2 has a whole new asset loading system, so I've been apprehensive to start work on anything in that area just yet.
If there's one thing I miss from Unity, it's seeing a list of entities and being able to inspect them at runtime. Source 2 comes with an outside console but I think we can enhance that. 

So this is the console I've been messing with:
Here's some more in depth stuff on the usability of it.


You can select and copy from the main console bit. We have auto complete. You can filter by text or by severity, and ctrl + f works too.

Clicking on any line will give you a stack trace on the right. You can click on the filenames to jump to that file and line in the code.


Having a FPS counter in game is cool, but I wanted a bit more. So here we get a bit of a graph and it changes colour when the framerate suffers. 

It's also got lines on the bottom showing when garbage is collected. 

Lists Of Stuff

The left column is for lists of stuff. Right now we have Entities, UI, Library and Hot-loads.

Above shows how the UI list live refreshes. You can see as I open the chat UI off video and add a couple of lines, it adds the new chat entries. The yellow text are the css classes.


This all uses web sockets and you can use it to connect over the internet. So technically you could use this console to rcon servers. 

It's also very possible to write other clients for this too, so you could write your own clients for it.


My intention when/if we get Source 2 is to make it so the game runs inside the console. That is to mean, it will optionally appear in a window inside the console. That's what I'm designing for. You'll obviously be able to make it go full screen, or suck it out to a window etc.. but for me, the way I work, it'd be more comfortable in the console window most of the time.

I don't intend to turn the console into a Unity type game editor. It should be for diagnostics only. Any tools should run in a separate process so we don't run into the Unity problem of not being able to work on something else because an editor tool is doing something.
Like everything else, I've been working to push as much UI stuff into an addon. 

This has benefits:
  • If you get an error with a stack trace you can see the code.
  • More open code means more to learn from.
  • If you want to make a control you can copy/adapt/derive from an existing control.
  • Bugs are more easily recognised and reported by the community, instead of assuming it's a problem in their own code.

I made this particle test to test the performance of the UI system. As it says in the video, keep in mind that in a real UI environment you're not changing 1000's of panels and deleting/creating 100s of panels every frame. This is meant to see how much we can get away with.

Keep in mind, every frame it's
  • Changing every panel position
  • Setting its background-color
  • Setting its opacity
  • Deleting dead panels
  • Creating new panels to fill their space
I was pretty impressed with the performance I got out of it. Each panel is created like this:
So we're talking about thousands of panels with a border radius and a 3 pixel border.
I'm trying to project forward, what UI controls will we need if we're thinking about making a Garry's Mod sequel. A grid and a property sheet is obvious, so I've been working on that.

I've got the grid so you can choose between a fixed column count or a fixed cell width which automatically wraps. It's got options for cell spacing and filling the space, which avoids that horrible gap down the right.

The property sheet isn't done yet, I've only got text editing at the moment, so still need to add support for number editing, range sliders, checkboxes, lists, enums etc.

Here's the code that creates this test:
Another control I'll more than likely want, and relatively tricky to implement so I thought I'd put it near the top of the list. 

In the video above you can also see how the property sheet folds in if its width goes too small. Thanks to the style system in Panorama, this can be done without any super complicated code.
As you can see, we just set the class "horizontal" if the width is over 290. The rest is handled in the css.
A worry when implementing a UI system is whether it's possible to sync it with the in game stuff. What I mean is, if I draw a name tag above a player's head.. is it going to float behind him when he moves about.

So I made this quick test to try it out. [Ignore all the missing textures, I deleted them to save space and am only using this as a basic test map, I'm not interested in assets right now]

These UI elements aren't in world. They're still 2D, on the HUD, I'm just positioning them right and scaling based on distance and fov, so they seem like they're in the world.
Another test was the Chat UI. Can we take the focus from the game and put it on our text entry. Then when that's closed, can we return it to the game. 

This sounds like simple stuff, but it can be a pain in the ass. Like do binds still run in the game when we're chatting. If we press enter to send a chat message, which closes the text entry box, does the game then pick up the enter key and run the bind on it.

This also was an opportunity to work out the server/client architecture and how they interact. In Garry's Mod the server and client Lua states are separate. In Sandbox they're running in the same realm. 

So check this out, all this code is on the ChatUI control.

This gets called when you press enter on the text entry. It's easy enough to read, close the box, clear the text entry text, if the message they typed isn't bullshit we call the Say function.
But check that out, the Say function is a console command.. and it's server-side. 

There's some nice magic happening here in the background that you don't need to worry about. If you're a listen server or single player, it'll just call it. If not, it'll send a message to the server and call it there.

So the server just calls the function Chat_Add with a list of players, the calling player's name and the message they passed in.
Here's some more magic. This is a client command.

Something you'll notice is that it doesn't even take a list of players, that's just magic. That function is generated automatically. You don't get any compile errors or intellisense errors, we just done some magic for you.

So the chat_add command just get the Current ChatUI instance and adds the chat entry.

Give this section and thumbs up it that makes sense, or a thumbs down if you're really confused.