Wire: holograms_model_any isn't working as intended

[ctrl-data]

Supposedly according to a mate at discord this "fix" broke it.

https://github.com/wiremod/wire/commit/03e1ffb24d2b0d527e062ad31ef22c5ce60f85ef

If we can get a fix, it'd be appreciated.

If you don't know what the command does, it just allows people to use models not on the server for holograms. Which helps a lot for builders who use models as guides, people who don't have half life content on servers etc.

[shadowscion]

any word on this?

[TomyLobo]

You should not be able to use models the server doesn't have.
If that ever worked, it was a bug.
If you depend on bugs, your code is going to break.
Don't blame it on us, we're not going to reintroduce bugs.

[bigdogmat]

@TomyLobo It was not a bug, it was intentionally added here as a second option.

You should not be able to use models the server doesn't have.

As started in the first comment here, there are many reasons to allow models the server doesn't have.

[ctrl-data]

I'm sorry what? Nebual added the command in 2013 to allow people to use holograms of any model regardless of whether the server had it or not. This is a bug, it is a bug that was created by a broken code contribution.

https://github.com/wiremod/wire/issues/261

A source right to where he added it.

"This is actually kind of troublesome, because even though most people have all of the source games, most servers do not, so we can't use a lot of the models. If this line was removed we could spawn holograms using models the server doesn't have. I can't really think of any downsides to removing this, currently if a person doesn't have a model, they will see an error anyways, so this doesn't change anything." - shadowscion

[TomyLobo]

oh god, you're right, I'm gonna have to talk to @AbigailBuccaneer about not introducing bugs.
This is horrible!

We don't know anything about models not on the server.
Who knows what kinds of bugs we drag in by just spawning them without being able to do a sanity check on their dimensions and flags and such...

If we're not even asking gmod about whether a model is ok to use, how can we expect that not to crash clients?

[ctrl-data]

You've been able to use any model for the past 3 years. No one said anything about it. No one has had issues. Then a contribution comes up and breaks it all ruining so much code.

Fun fact, holograms_model_any 1 doesn't even work. Stopping you from even using TF2 models, DoD models, CSS models.

[TomyLobo]

Solution: install the models on the server.

[bigdogmat]

If we're not even asking gmod about whether a model is ok to use, how can we expect that not to crash clients?

If the client doesn't have the model, they won't crash. Doing sanity checks in this case would require a lot more work for what ever useful information you could get, which I don't think there would be any.

Solution: install the models on the server.

That was the entire reason this was added...

[ctrl-data]

Its been like this for 3 years with no issues, and a "fix" comes along and ruins it.

It needs to be resolved.

[TomyLobo]

@bigdogmat Yeah if the client doesn't have the model, they're fine.
The problem is if the client has the model and the server doesn't.

@DatAmazingCheese #1080

[ctrl-data]

I don't think you realize what this command does. It allows people to change the model of holograms to whatever they want. This is used for detail work on tanks, cars, to building guides with specialty models the server would never have simply because of their niche purpose.

The holograms have 0 physics they are just meshes with textures, if the client doesn't have them they're errors. I've used models my server doesn't have all the time and I've never had ANY issues.

[TomyLobo]

You're not thinking this through. Read #1080, the person who reported it summed up the ramifications nicely.

[bigdogmat]

@bigdogmat Yeah if the client doesn't have the model, they're fine.
The problem is if the client has the model and the server doesn't.

The server won't crash either as holograms have no physics, the server will have no problems with this.

Only issue I can see coming with this would be where a client has a model that's able to crash other clients, and those clients have them as well. Considering the server owner has to actually change it to this option, we can only assume they'll take the risk.

You're not thinking this through. Read #1080, the person who reported it summed up the ramifications nicely.

Like I stated above this requires the server owner to actually enable it, #1080 was something that was allowed no matter what.

[ctrl-data]

Either way, even the setting 1 doesn't work. Which allows people to use the models on the server.

The issue needs to be fixed and returned back to how it was because many people are downgrading to workshop wiremod because of this.

[TomyLobo]

@bigdogmat Yes, the client has the problem, not the server. This is what this issue is about, the client.

[TomyLobo]

@DatAmazingCheese "Does not work" is not an adequate problem description. Can you describe in detail what you did, what you expected to happen and what happened instead?

[ctrl-data]

Setting is on 2, allows any model. Change holo model to a tf2 ammo box, I get a white cube. Change setting to 1 and repeat, white cube. Try model server doesn't have with either setting, white cube.

Downgrade to workshop and it all works with 0 issues, go figure.

[bigdogmat]

@bigdogmat Yes, the client has the problem, not the server. This is what this issue is about, the client.

I know, and like I've said, we can only assume the server owner is willing to take that risk considering they have to explicitly change the setting.

There isn't any easy way to go about validating models on the client as a _sanity_ check. Only way I could see doing it without slowing down the runtime of creating holograms would be to make the client send a list of models they're planing to use that the server may not have.

E.g. client has a convar of all models they're planing to use set, they join a server and the server checks said models and then tells the server whether or not they're fine to use for any future requests to use this model.

[bigdogmat]

You're not thinking this through. Read #1080, the person who reported it summed up the ramifications nicely.

To add on what I said about this a few comments up. I imagine many of the issues with #1080 had to do with the fact those models had to use physics, and they weren't checked at all server side even though they were available.

[TomyLobo]

@bigdogmat ok so you think that the server owner can make that decision for the people connecting to their server?

EDIT:
Btw, #1080 does not mention physics, where did you read that?

[ctrl-data]

Doesn't matter what the decision is, because there is no negative effect.

[TomyLobo]

@DatAmazingCheese #1080 !!!

[bigdogmat]

@bigdogmat ok so you think that the server owner can make that decision for the people connecting to their server?

Yes considering they're connecting to said person's server. The server owner can already crash their game through many other means, even accidentally.

Edit: I get where you're coming from about the server owner shouldn't decide whether your game should close or not, but it's already a dead horse.

[ctrl-data]

Yea, so he added a can model with 0 way for us to whitelist. Fucking us over in every way. Return it back to how it was. Server owners set it to 1, or 2. Simple as fuck.

And yes, server owners do make the decision, it's their server, they can do as they please. As mat said, theres plenty of other ways an owner could crash a game or anyone else.

[bigdogmat]

EDIT:
Btw, #1080 does not mention physics, where did you read that?

It didn't need to, it's talking about gates and other entities using those models. Those entities have physics.

[Bubbus]

DatCheese has been keeping me in the loop about this, I've tested @bigdogmat's fix on a popular build server and got the guys there to hammer it a bit - works nicely, no issues uncovered.
Obviously this is not proof of the absence of issues regarding sanity checks etc. but I hope this is helpful and pushes the issue forward.

[oldmud0]

@TomyLobo Check your ego. They're asking for something completely legitimate, as long as it does not present problems for other people. @bigdogmat's solution is effective and works for both cases. Those admins who only want standard hologram models choose 0, those admins who want any model on the server choose 1, and those admins who will allow any model, even those that the clients have but the server doesn't, choose 2. So, there is an option for "literally any model". It's not the default option, no, nor is it recommended - but if admins don't have a problem with it and it is not a painful section of code to maintain, I don't see how that cannot be a choice. That's it, end of story, just add option 2, the admins are happy, the users are happy, and we can move on with our lives.

[AbigailBuccaneer]

I agree with @TomyLobo that this has security implications and was an ill-thought-out feature-verging-on-bug in the first place. But this has also seemingly affected a lot of people (does anybody ever do anything with Wiremod other than render holograms that the server doesn't have these days?), and the security implications are fairly limited and it's a server-side opt-in. I'm happy for the old behaviour to be restored, but I do think once that's done we should have a discussion around how this can be managed in a non-crashy and non-hacky way (potentially revolving around clientside whitelisting).