Wire: holoModel(N,S,N) fails to set the model

[sammyt291]

Hello,
I have just recently updated our rev of wiremod on our servers and have noticed that players that previously had holograms working now all show as the default hq_cube.

holoCreate(1,entity():pos()+entity():up()*20)
holoModel(1,"models/sprops/misc/alphanum/alphanum_s.mdl")
holoColor(1,vec(255,0,0))

holoCreate(2,entity():pos()+entity():up()*40)
holoModel(2,"models/sprops/misc/alphanum/alphanum_s.mdl",1)
holoColor(2,vec(255,255,0))

If you test this code with S-Props installed:
The Red S spawns correctly however the Yellow one spawns as the default cube.

With the older wiremod rev we were using this did not occur and both would spawn as the correct model.

Any help would be appreciated!
Best regards,
Sam.

[bigdogmat]

That model only has one skin correct? Anyway I fixed the logic in WireLib.CanModel and so that shouldn't make it a white cube anymore.

[sammyt291]

Yes it only has the one skin, but I would assume it would continue the old logic of use the default if the skin specified does not exist,

If this is what you changed @bigdogmat then that should be perfect

[bigdogmat]

This will return it to the old behavior, however now it does a skin check and so if the skin is invalid it won't change anything. Issue in this case was the fact it was using the wrong logic which I fixed in my pr.

[bigdogmat]

Actually looking back and testing this, skins start from 0, not 1, so the logic was correct, it just means anyone that thought it started at 1 it would now break for.

@AbigailBuccaneer Any opinions on this? If we leave it, people E2s will break, if we change it, people can put on invalid skins (this doesn't have a negative effect afaik).

[TomyLobo]

negative numbers for the skin are not a problem?

[bigdogmat]

negative numbers for the skin are not a problem?

They are, and I was gonna update my pr to check that after I got a response for other thing.

[sammyt291]

The current CanModel check uses:

if skin ~= nil then
    local count = WireLib.NumModelSkins(model)
    if count and count <= skin then return false end
end

If the user uses a skin that doesn't exist then the whole holoModel is cancelled,
Would it not be better to have a CanSkin check which returns the input if its a valid skin or 0 if its an invalid skin?

That way even if the user inputs a skin that is under or over the skin count for that model there shouldn't be an issue, the holoModel will still successfully set the model, which is its primary job in the first place.

Edit:
Out of interest is the skin check needed at all? if the model is set to an invalid skin does the engine not just default to the models default one?

[bigdogmat]

After testing all it does is change the skin to 0 if it's out of range. Guess easiest way to fix this would be to remove the skin check in holoModel.

[TomyLobo]

@Divran @AbigailBuccaneer @Nebual opinions about removing the skin range check?

[Divran]

If setting the skin to an invalid skin causes no lag or whatever, then I don't see why not

[andreblue]

It should not, its exactly like if your missing a texture, it can show the black and purple ness.

[bigdogmat]

It doesn't even do that, it just sets the skin to 0 (default)

[andreblue]

I have had it with things like cars, where if you set the worng skin it shows the purple and black squares. It may depend on the video settings maybe?

[bigdogmat]

Maybe, if you could send me something you know does I could see

[andreblue]

So it happens to some vehicles but props seem mainly to stick with skin 0 if its not valid. In the past i swore it also showed black and purple missing texture squares

[sammyt291]

I have had the skin check removed from CanModel for three days now on our servers, no issues have came around at all so far.

[bigdogmat]

Once #1324 is merged I can open a new pr to remove the skin check, I'd rather not put it in with that one.