Weapons defined in text files / de-harding weapons [feature debate]

Aside from the implementation issue, not making it "cost" more then the current way, i see a problem with this when it comes to stats. basically as soon as a server is not 100% pure any weapon id could do anything (technical they already can, i guess, but the chase is far less atm) thus making stats per id useless. please consider how to solve that in your planning.

Xonotic is customizable already, so having modified servers is already easy. I think the server list indicates those, so people can see them and know the balance is modified. I think it needs a list of cvar defaults to indicate unpure servers... not sure

Modded is one thing, but when you are talking abt a system that allow anyone to turn the laser into a flametrower-minstanex-roketlaunhcer, you are bound to get a whole lot more 'bad data'. Server list does not enter into it, im talking abt how to make the stats system aware of "incompatible configurations", such as turning a splash wep into a hitscan or vice versa.

Shouldn't the stats system discard stats from such non-vanilla servers altogether anyway?

maybe, but it does not as this moment. all im saying here is that needs sorting out, somehow.

I admit I'm not familiar with this stats system, so I'm not sure what to say here. The same way, you could set the damage of a weapon to 999 and then the UZI would act like a MinstaNex, which would also wrong the stats. But if this proves to be a problem, maybe someone more familiar with the system can tell me how to prevent it, or maybe help with code on this part.

Nor am i, but i imagine getting "splash damage stats" on sth that used to be hittscan (for example) would confuse the hell out of the current system.

Ok, I am back. Who's willing to help out with this in any way?

Poke-poke. I'm still planning on coding this feature and quite excited about it, but waiting on more input so far. The latest plans for my approach are as follows:

1 - Make a new qc file and move all attack functions and projectile code there, from all weapon files (simply relocate the code without modifying it). eg: If the shotgun's primary attack is located in w_shotgun.qc in a function called Attack1() which is called when you press fire1, move that to projectiles.qc as Shotgun_Attack1, and have the code in w_shotgun.qc call that function when primary fire is pressed.

2 - Once that's done for all weapons, I'll merge all attacks that can be combined into single functions with neutral names that take parameters. eg: If the crylink primary and hagar secondary use the same projectile pattern to spawn projectiles, combine the code that spawns both. While the laser primary and electro primary should be able to use the same function with different effects. The end point is any projectile logic being customizable and reusable.

3 - Turn how each weapon spawns and uses projectiles into cvars, which define what function they address and how. This adds additional cvars to all weapons in balance.cfg specifying hitscan or splash damage, the projectile pattern, the projectile model and sounds to use, etc.

I'd like to hear more about what others think of this approach and if I should use a different method here. But please refrain from comments such as "It won't happen because it's too much work and it will be hard for us to maintain". If no one else volunteers, I'll be doing all the work. As for it being hard to maintain, quite the contrary... there will be less code in one file instead of each weapon's file containing those logics (some repetitive), while it should not require any special maintenance once it's ready. The feature won't affect those who don't care about it, just help a huge amount with modding and custom configurations.

Please don't do this, massive waste of time... We're really never going to merge this.

Please don't do this, massive waste of time... We're really never going to merge this.

Any better reason than just "don't do it cuz we won't merge"? Like I explained, I'll be doing all the work on this part if no one else volunteers, and I'm making this in a way that will be easy to maintain (if maintenance will even be needed on such code), not affect performance, and not change existing functionality. If you won't use it that's fine, but I see no reason to cut it off for people that could make good use of this feature. Also, I'm open to modifications on how to implement this in case I missed anything and my approach is bad... just not blindly saying "don't do it".

We've explained this several times before to you... We DO NOT want this, it WILL create a LOT of overhead and it WILL make maintenance MORE DIFFICULT for us... It's already really easy to make a mod of weapons, this is just a completely pointless idea. Additionally, this will CERTAINLY create MANY bugs (which may be very hard to find) due to the nature of the change, and your track record for development of such things (example, global reloading) makes us incredibly reluctant to merge it...

Regardless of the fact that we do not want this, you are not the person who should implement it in the first place. I am telling you right now Taoki, you will be wasting your time by coding this, as we WILL NOT accept this.

Those are vague reasons or at least expressed vaguely. It sounds more like "I don't want it so it won't happen" (I'm not sure who 'we' is supposed to be, I saw people that do). If you're set on not wanting it just because you don't want it, there's not much I can say to change this. I will code it soon, and decide with divVerent and other developers (who actually listen and are open to larger new features) whether or not it can be merged and how it would need to be done. divVerent already suggested how I should do this if he is to approve it... I think my idea is fairly similar to what we last spoke.

I've already discussed it with the core team, i'm telling you this right now: WE WILL NOT MERGE IT TAOKI! It WILL NOT be approved, it will automatically be rejected. I don't know how to make this any more clear to you.

I see contradictory information between these two last posts. Could somebody from the core team who was part of this discussion Samual mentions expose the team's opinion in a slightly less subjective way?

After an hour of drama on IRC two days ago, me and Samual got to an understanding. I will not be touching the code for the core weapons, and instead will create customizable weapons as a mutator with separate settings. If some months or years from now Samual and other devs find that my code is good enough to replace the existing weapon code, maybe it will become a default... if not it can stay a mutator for all I care. Re-implementing it from a scratch also feels like an easier approach than modifying existing weapon code piece by piece... there's also no hurry to replicate the existing core weapons at once. When I have the time and mood to get working on this, I will.

Good news. I was hoping this would be allowed in some form.

I would love to help with this in any way possible ...

I cannot code for xonotic at the moment, but I plan on getting involved in (code based) xonotic development in the next few months ...