Author Topic: Replacment decision?  (Read 427 times)

What decides what an undownloaded weapon will look like. Example: combat rifle looks like a sword, TF2 minigun looks like a slow loading gun. What decides this?

The .melee value being true on a weapon will make it look like a sword.
The .melee value being false on a weapon will make it look like a gun.
If it's a tool or item, or anything else that isn't a weapon, it's a printer.

Intresting. But what about the Old School Rifle? It turned into a printer on Bushi's server

My post was only a theory. Forgot to mention that.

I read something posted by badspot that said it brown townyzes the name of the add-on, and uses a list of common names to determine it.

Badspot

  • Administrator
What decides what an undownloaded weapon will look like. Example: combat rifle looks like a sword, TF2 minigun looks like a slow loading gun. What decides this?

It checks if the name contains common weapon names like "knife" or "sword" and tries to use an appropriate model.  The tf2 minigun uses the gun model because it contains the word "gun".  If it can't find a match, it picks either the gun or printer based on a hash of the item name (basically random, but the same every time). 

It's basically all piece meal.  Anything with "launcher" in the name uses the rocket launcher model.  The HE grenade will use the hammer.

The combat rifle is a sword because it picks up on the "bat" in "combat" and thinks it's a melee weapon.  I believe I fixed this in v14. 

Why can't we have a variable to override that system?

Badspot

  • Administrator
Why can't we have a variable to override that system?

If you mean a server side setting for alternate models that would involve changing the network protocol to send more than one value for every shape file.  Old add-ons would have to be updated to work with this system.  A lot of effort for not much reward.

If you mean a client side setting for alternate models then if you're going to go through that much trouble to make an alternate model look-up table, you might as well just download the actual model.

If you mean a server side setting for alternate models that would involve changing the network protocol to send more than one value for every shape file.  Old add-ons would have to be updated to work with this system.  A lot of effort for not much reward.
Well, add-ons without it set could default to using the current detection system. As for the shape file, I was just thinking of a variable in the item and image datablocks to be sent to the client with all the other properties, but if that was what you were saying, and it's not as easy as it sounds, I guess the current system will be fine.