Biggest Annoyances - June 2021

[garrynewman]

What's fucking you up the most right now?

Is there a bug you're constantly having to work around?
Is something breaking your flow?
Do you wish you had access to something you don't have access to?
Do you hate the way something currently works and think it should work different?

[thegrb93]

A sandbox 'mods' folder or some way to combine addons.
A 'data' folder that allows saving/loading files. I saw there's a FileSystem class but I'm not entirely sure how it works yet.
Lack of client to server RCP

And these blockers:
#321
#287
#275

[garrynewman]

Gamemode addons isn't something we're concentrating on right now, that's something that'll come later once everything is a bit more established.

You should be able to write to a data folder now using FileSystem.Data and FileSystem.OrganizationData. These should give you write access to data/<org> and data/<org>/<game>

[Nebual]

#287 is definitely a blocker for larger projects, 200kb of zipped .cs (including comments) adds up fast. facepunch/sandbox is already almost half that limit.

[ogniK5377]

One thing which is a little annoying is the disconnect with the naming scheme for Particles. Very small but should probably be named to Particle to match the other naming conventions. One more annoyance is the inability to just set a single component on a particles control point. Quite a few times when wanting to control specific particle settings from the c# side and I only want to modify one component of the control point, i have to create a new vector 3 and set all 3 components

[garrynewman]

I'll look at Particles.

Can you show me what you mean about setting one component? Anything taking a Vector3 can take a float too, which sets all 3 components.

[ogniK5377]

There are a few instances where you don't want to set the remaining components of the particles. You're able to set single components to do specific actions in the particle editor, as seen here with the emission rate:

Having the ability just to set one single component instead of having to set all 3 just makes it overall easier to read and nicer to play with. If I wanted to set say component Y but leave component X as is, I'd need to keep track of component X and set it again.

Tldr:

Particle particle = new("particles/my_particle.vpcf");
particle.SetSingleComponent(2, 0, 10.0f); // Sets control point 2.x to 10.0f
// or for something more expressive
particle.SetComponent(2, Compoent.X, 10.0f);

[m0uka]

Not really a huge issue, but it would be a nice QoL change:
Make the Log methods accept other types than string, similarly how Console.WriteLine or Unity's Debug.Log does it (accept an object).
Sometimes I want to quickly print out a value without attaching a debugger or having to type .ToString / having to use string interpolation for every non-string variable. Would be useful for printing out numbers, entities, panels, etc..

[garrynewman]

Consider it done

[DoctorGurke]

Content downloading when joining each other. Right now it seems to always download and cache everything, regardless of if you already have it in your addons folder. We had to split up our projects into separate repos, just to not have to download all the content when joining. ogniK made a python script that would cache all the files in the specified addon folder, which we greatly appreciate, but even this only seems to work with like 70% of files.

[garrynewman]

Content downloading is a HUGE pain in the ass right now. So slow and horrible. I will see what I can do about it.

[R4K0]

It's not a major blocker, but I still wish we'd be able to send over NetworkClass in a list.
#241

Right now we have to change them into Entities, make it always network and accept the overhead that come with it, not to mention wasting some of the Entity limits.

Take this theoretical example:
We have a classic grid inventory with items inside not necessarily being "instantiated" as an entity until they need to be.
Each player has 60 unique, non-stacked items in its inventory
We have 60 players. That'd be 3.6k wasted dormant entities at this moment just to network data structs that aren't really physical entities.
The entity limit, as far as I know, is 16k. We used up 20% of the limit just for that.

Bonus Point: People looping over Entities.All will suddenly have to loop through all of that garbage, which isn't ideal and can add a bit of overhead - Bit of a strawman argument, but yeah.

My gamemode will NEVER reach this limit, but I still hate making my data structs inherit from entity because at the back of my mind I know how much useless stuff I inherit with it, that I won't have an use for.

You could argue that we could use structs, but then we have to tip-toe around using unmanaged types only, and that in itself is an annoyance. (No strings in those!)

[garrynewman]

I need to think around this. I'd like to let you do what you want to do, and I know a lot of people would like to do that too.. I just need to work out a non shitty way to do it on the backend.

[TankNut]

Probably less of an annoyance and more of a nice to have would be a 'default' UI style that people can use for placeholders/prototyping similar to what you were able to accomplish with derma in Garry's Mod.

I've actually found myself being put off from working on some ideas I have because of how daunting the idea of having to design the entire UI from scratch is.

[garrynewman]

You mean like, a Button should have a style by default etc? Are we talking about regular UI, Panels and Buttons, or HUD?

I can see that this could be a barrier for a lot of people, it makes sense to have a bunch of base styles so everything isn't just invisible.

[TankNut]

Mostly talking about regular UI but I guess it could apply to both.

The way I envisioned it working is that the current behavior stays as-is (elements don't have a style by default, for people that want to do things themselves) and that the game ships with one (or multiple) scss files that provide a base style that people can use as-is or @include into their own stylesheets as a starting point.

[louiefox]

Not something massive but having the default css display properties would be nicer, I know flex can still be used in place of them however its annoying when you just want something to go onto the next line and you need to specify display flex and the flex direction. Would just be easier if we had the normal display options and block as default. Just making the UI system behave more like html/css would be a lot better as nothing really needs to be documented about it as it would be mostly like normal web development.

[garrynewman]

Flex is standard web stuff. I don't really agree that having display: inline and display: block would make things any simpler for people.

[ogniK5377]

Another annoying thing was the removal of NetRead and NetWrite. The ability to have fine control over the networking was quite nice and it allowed for serialization of any type we have manually, bit packing & also the ability to detect network state changes with ease. It's something I'd love to see make a return.
This also brings up the ability to craft network messages in general. Similar to how net.Read/Write worked on Garry's Mod. The ability to just send network messages to client/server and parse them ourselves allows for huge amounts of flexibility and control.

[R4K0]

Very much this, the NetworkClass change wouldn't sting as much if we still had an option of serializing our own types with Readers and Writers.

[ogniK5377]

One more big annoyance actually which I'm surprised hasn't been brought up here yet. A way to hide the error dialogue sooner. Whether it be a nice x button if you just click it and it fades. It's nice to have the dialogue up but an ability to close it will be nice as it can get a little annoying if it's on the screen for a really long period of time

[notcat]

Not to mention it doesn't scale appropriately and runs all the way off the screen for me and others so its actually more of a hinderance than a help.

[Alf21]

A more stable / reliable networking system would be great, as lot of add-ons gonna build on multiplayer stuff. I personally like syncing data manually to have the control about which player should know what.

Currently, the networking system is unreliable in these cases:

• Network disconnects for a short time (RPCs won't resend)
• RPCs that are send while hotloading won't be received by clients
• RPCs are not always received by a client that is currently connected to a server

[garrynewman]

I haven't had any of these issues with RPCs, but what I would say is that RPCs are what they are. You wouldn't update an entity's health using an RPC because clients joining would have to get that RPC too, so it'd be stupid to be managing stuff manually like that instead of using a variable.

I feel like a lot of the RPC issues people are getting are from a misunderstanding of how they work. If you send an RPC to an entity - the receiving client needs to know about that entity. If that entity isn't in the client's PVS yet of course they're not going to receive that message - because what would it go to?

For things that you want to always go through we have global RPCs. If you make your RPC function static and it won't be tied to an entity or the PVS system.