Create an account


Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Weapons defined in text files / de-harding weapons [feature debate]

#1
Brick 
I partly discussed this in another thread, but want to bring more attention to the matter and discuss it properly. I started thinking a few months ago about removing all weapons from the code and defining them into text files (without changing any functionality by default). Although this is not an impossible task, it will be quite difficult to do, and needs some planning first. To begin, there are several reasons why I want this:

________________
- Allowing separate games and single player stories with Xonotic:

As some of you may have read, I have a set of features planned to allow creating single player games with Xonotic. Text weapons would allow each story to use guns that fit it instead of the default ones in Xon. Say you're making an urban-oriented story like I am. You might want weapons like a pistol, but the default Xonotic has no business to include such a thing in its code. Or maybe you wanna go further and make a medieval story with swords and bows. This will allow you to define those weapons without any code changes, by including the text file and the weapon model / sounds in your package.

Even on the arena component (non-single-player) the Xonotic code could be used as a framework for other mods, games, and mini-games. You could create another arena-type game within Xonotic which would not be Xonotic (a separate data folder with different graphics, maps, textures, player models, weapon models, and now weapons). The server list would even allow you to play any of those FPS games. If it actually happens, this ability might be a small revolution in open-source FPS gaming, making Xonotic the only project which is both a standalone game and usable as a Software Development Kit. This is a dream I've had for some months, and really wish to put it in practice.

- Great for modding Xonotic:

This would be a great features for modders and creators, even if they're not making an entirely different game. Anyone who runs a server can remove or add any weapon they want, and admins can easily show off their ideas to the public. Being both open-source and very flexible, Xonotic is a larger attraction to modding than other shooters. And if you think closely about it, hard-coded weapons are actually a limit, and removing this limit might open Xon's boundaries to much more fun stuff.

My code will allow guns to do anything... even crazy stuff beyond the purposes of a weapon. For example, you could make a grenade that spawns other items when it explodes, or even triggers server-side cvar aliases or responds to keys other than just attack and attack2 (which would be secondary and non-priority features). Most importantly, by defining the behavior of each firing type, you could create projectiles that look any way you want and do anything you want, as well as the defining exactly how the weapon shoots them.

One example: Some might have tried Morphed's server ([MoN] Overkill [MOD]). It runs a Xonotic mod with a different set of player models, a different balance, and most of all custom weapons (a shotgun, a machinegun, and a minstanex, but different than ours). For those weapons, he probably needs to maintain a separate code, because their firing modes are different. Text weapons would let modders like him run custom guns without needing any code changes.

- Allow full weapon balancing:

This might calm down both the "balance wars" as well as the weapon refactoring wars (removal / addition of certain weapons). A good example is something that's been happening in the last days. Samual wants to remove the shotgun and merge it with the laser, then remove bullet weapons entirely (replacing the UZI with the lightning gun). It's not decided if this will happen yet, but I went super-sayan when I even heard the possibility. Although old weapons would be kept as a mutator (which sounds like a bad way to me) I want to be able to play with the existing guns normally, in case Samual's changes are approved. If Samual's changes don't get approved instead, he would be able to keep his merged weapons as part of his balance and others could still play with them, anyone easily able to choose which weapon set to use.
________________

Those are the main reasons why I want this feature. I believe it will open Xonotic's horizons to a lot of awesome possibilities, and it's something anyone who's even slightly into modding can benefit from (which by itself might also help an increase in popularity). Rest assured, this change will not modify how weapons work by default once if's finished (at worst just some unnoticeable details), so there should be no worry of negative effects.

Problem is that this will take a lot of work, and I don't know how much I can do by myself. A main purpose of this topic is to present my idea and ask who's feeling up for helping me implement it. Here are the technical details of what I want to do exactly:

________________

At this moment, each weapon and its functionality is wrote in a code file (eg: qcsrc\server\w_electro.qc). The number of total weapons and their definitions are also hard coded. What I want is entirely removing weapons from the code, and all words such as Shotgun, Crylink, Electro, Nex, etc. Instead, the code will only contain a single file for weapon functions, consisting of all projectile types and their possibilities. This code then reads weapons defined in one text file, to understand which weapon can be selected and what it does. The text file would contain information on how the weapon is called and what its firing modes will do.

In other words: I defined a weapon called MyGun. Now, does its primary spawn a hitscan projectile, or a rocket / grenade? What model does that projectile, use, and what sounds and particles does it play / spawn? Also, what pattern are the projectiles spawned in, and how many? Does the weapon charge its shot (like the Nex) and can you hold to load multiple projectiles (like the Hagar's secondary)? And of course, what is the model of this weapon and its firing sounds, and what ammo does it take?

The aim is to allow any weapon to define those characteristics. And best of all, to do it without having them conflict each other whenever possible. For instance, if you enable a spread pattern and also a fast firing rate, you get both the Shotgun primary and UZI primary types. Or if you enable both shot charging and loading of multiple projectiles, your shot will do more damage with charge like the Nex, while you can load multiple shots and release them by holding the fire button (like the Hagar).

The format of the text file is undecided. However, I wrote a quick example just to show the basic idea:

Code:
// cvar implementation, weapon example
item_1_name Shotgun // how the item is called
item_1_model models/weapons/shotgun.md3 // model of the item
item_1_sprite gfx/weapons/shotgun_icon.tga // sprite of the item
item_1_type weapon // is this item a weapon, health, or armor?
item_1_dropable 1 // this item can be dropped
item_1_intenvory_size 1 2 // the size of blocks this item takes in the inventory
item_1_held 1 // this item can be held by the player, and is activated with the fire button (otherwise instant on pickup)

//type specific settings for "weapon":
item_1_primary_type bullet // primary fire spawns a bullet, or a splash projectile?
item_1_primary_pattern spread // fire the bullets spread (shotgun), continuous (machinegun), or what pattern?
item_1_primary_ammo_type shells // which ammo definition to use
item_1_primary_ammo_amount 1 // how much a shot costs
item_1_primary_damage 5 // damage dealt
item_1_primary_force 10 // push force
item_1_primary_model models/weapons/bullet.md3 // projectile model to use
item_1_primary_sound_fire sounds/weapons/shotgun_fire.ogg // sound when firing
item_1_primary_sound_impact sounds/weapons/bullet_impact.ogg // projectile impact sound
item_1_primary_particles_impact smoke // particle to play when the bullet hits a surface
... etc ...

// cvar implementation, item example
item_2_name "Health 25" // how the item is called
item_2_model models/items/health_25.md3 // model of the item
item_2_sprite gfx/items/health_25_icon.tga // sprite of the item
item_2_type item // is this item a weapon, health, or armor?
item_2_dropable // this item can be dropped
item_2_intenvory_size 1 2 // the size of blocks this item takes in the inventory
item_2_held 1 // this item can be held by the player, and is activated with the fire button (otherwise instant on pickup)

//type specific settings for "item":
item_2_primary_type health // does this increase health or armor?
item_2_primary_amount 25 // how much to heal / boost the stat
item_2_primary_sound_fire sounds/item/heal.ogg // sound
... etc ...

And yes, I also plan to make items part of my code (and as a separate project later on, turrets and vehicles). If I go this way, all items are defined as entries in the text file, and only type "weapon" are weapons, ammo / health / armor being "items". The best approach is to define shot types separately, and only parse the name of a shot to the weapon definition (so crylink primary is a group called plasma_spread, and the Crylink weapon just references that). This allows firing types to be used for other things than just weapons, like the turrets.

Another concern is how weapons will be placed on maps. I'm planning to leave that as it is, since new weapons would require new map entities. The weapon definition will probably specify the entity name... so for the Nex, this property will be wep_nex, which is the classname of the weapon placed by the mapper (spawnfunc_weapon_nex). Only alternative is using numbers (wep_1, wep_2, and so on up to the maximum of 24, with the existing entities kept for compatibility), but I don't see a point in doing this and editing all existing maps.

Anyway, this should give a basic idea of what I'm trying to do. I already spoke with divVerent and Samual so far. Although they didn't wanna hear about it at first (because of the high amount of work), div suggested how I should go about this at a first stage. The first thing will be to remove projectile think functions which relate to the player (eg: What RL rockets use for detonation). The weapon code would have to handle any action by the player, not projectiles directly. Then, once projectiles can be spawned from anywhere inside the code (such as a turret being able to use them) code can be put in place to take the properties from text files. Lastly, the way weapons themselves work will need to change, since they aren't defined in the code any more. For instance, the panel HUD must see the text file as well for the slot of each weapon definition to know what it will print and where.

What's your take on this? Who else that wants this feature wishes to help implement it, or can even provide some code advice and input? Also suggestions on what to do and / or not do would help, so this idea matches what everyone agrees with. I strongly wish to make this happen in some way, and maybe we can get it done in a few months at most if enough developers help.
Reply

#2
FYI this requires entire weapon system re-write... it's basically totally not feasible.
Reply

#3
(05-23-2012, 11:40 AM)Samual Wrote: FYI this requires entire weapon system re-write... it's basically totally not feasible.

Wow, you really cut him up there Samual! Confused
Reply

#4
You know, the idea is awesome in itself, but there is at least one consequence outside your scope right now.

I mentioned this on IRC to a select few people, but basically right now on Xonotic there are a bunch of different servers running their own physics, their own weapon balances, and all sorts of crazy customization. In all honestly, one person may look at having each server play differently as "variety" and a good thing, but to me it just makes things inconsistent and discourages me from trying any servers outside of the ones I've already approved.

You introduce a weapon/item system that allows everyone and their mother to create their own weapons with enough work and this is just going to get worse. Everyone will want to create their own weapons and put up their own server to showcase them. I can see the forums being attacked week by week (long time in the future, of course) with people wanting their weapons certified for competition games... because they're better and more balanced. The whole idea gives me a headache.
[Image: optsig.png]
Reply

#5
Perhaps, but its true.

Its also very likely that such system would limit weapon options and incur a large processing overhead. Since Xonotic is a game, not a game engine, features like this are not, imo, to useful in the bigger picture. Its not like its difficult or time consuming to add/change a weapon as it is.

That said, IF this was done with little to no functionality and performance loss it would certainly be a nice thing - but until i see code doing that, i doubt it will happen.
Reply

#6
(05-23-2012, 11:40 AM)Samual Wrote: FYI this requires entire weapon system re-write... it's basically totally not feasible.

I know about the rewrite. Like I said it will take quite some effort, but I think the results will be very worth it, and it's an idea I believe a lot in. I believe this is overall less hard than the panel hud probably was, as one example.

(05-23-2012, 01:29 PM)Chryyz Wrote: You know, the idea is awesome in itself, but there is at least one consequence outside your scope right now.

I mentioned this on IRC to a select few people, but basically right now on Xonotic there are a bunch of different servers running their own physics, their own weapon balances, and all sorts of crazy customization. In all honestly, one person may look at having each server play differently as "variety" and a good thing, but to me it just makes things inconsistent and discourages me from trying any servers outside of the ones I've already approved.

You introduce a weapon/item system that allows everyone and their mother to create their own weapons with enough work and this is just going to get worse. Everyone will want to create their own weapons and put up their own server to showcase them. I can see the forums being attacked week by week (long time in the future, of course) with people wanting their weapons certified for competition games... because they're better and more balanced. The whole idea gives me a headache.

I don't think the fear of different mods should make us want to limit the abilities of the code rather than expand them. What I support for this purpose is adding better server list indicators as to which server is running a mod and which is running a default. There already are icons, but some filters would be nice as well, so that people who don't want to run into mods don't.

That said, there already are several known servers which are permanently decided as to what they are running. The DCC servers for instance will likely never use mods. Also, a modded server is usually marked accordingly, and I don't think Xonotic will ever be in a crisis of finding an unmodded server. So I don't think this could ever become a problem.

(05-23-2012, 01:31 PM)tZork Wrote: Perhaps, but its true.

Its also very likely that such system would limit weapon options and incur a large processing overhead. Since Xonotic is a game, not a game engine, features like this are not, imo, to useful in the bigger picture. Its not like its difficult or time consuming to add/change a weapon as it is.

That said, IF this was done with little to no functionality and performance loss it would certainly be a nice thing - but until i see code doing that, i doubt it will happen.

It's not just about it being difficult to edit weapons in the code. Like I said, one reason is to make modding easier overall, as well as allowing the usage of multiple weapon sets throughout the same installation of Xonotic. For example, "special maps" could even come with their own invented weapons by using a settemp_for_gametype_all on a separate weapon list. In my view this will only remove a big limit in terms of modding.

Otherwise, my architecture aims at not causing either of those problems (decreasing performance or the abilities of weapons). The existing abilities of weapons will all be ported to the text architecture, and not in any way reduced. Once someone wants to create new weapon abilities, then they edit the weapon code and make a new hook. Performance drop is likely not a possibility, because the text file will only be read once at map startup (I'll think of some way to persist them in the code so the files aren't read with each shot, but memory isn't increased a lot either). At worst it could increase loading times with 0.1 seconds on old machines, but I doubt even that much will happen.
Reply

#7
(05-23-2012, 01:31 PM)tZork Wrote: Since Xonotic is a game, not a game engine, features like this are not, imo, to useful in the bigger picture. Its not like its difficult or time consuming to add/change a weapon as it is.
This is what I was thinking. It would be nice if modders were to develop mods that add to the existing game, rather than create a new game. This whole debate has already happened before with OK so i don't want to dive deep into it.
Reply

#8
(05-23-2012, 01:59 PM)W4RP1G Wrote: This is what I was thinking. It would be nice if modders were to develop mods that add to the existing game, rather than create a new game. This whole debate has already happened before with OK so i don't want to dive deep into it.

People would still add to the game, even if they make mods or other games built from it (mods / games will still work in Xonotic, like Nexuiz had Default Mode and Havoc Mode, which are just different data folders). This just expands the area of possibilities... people choose what to do with that.

I can already create almost anything I want from Xonotic since I know the game code very well (even had my Nexuiz-based pet project for years). But I still contribute to Xonotic and will continue to. If someone knows how to mod Xonotic but don't contribute to it, they probably wouldn't have either way... and it's everyone's free choice.

But like I said, part of my plan is making the Xonotic game code have the features of an engine, and see what I come up with. I think this would be quite interesting, and not have any side effects on Xonotic as an arena FPS. I initially wanted to create my own Xonotic fork for this and many other changes (which I felt are too different), but now I'm pondering to add them in default, given they shouldn't affect or ruin anything existent.
Reply

#9
(05-23-2012, 02:13 PM)MirceaKitsune Wrote: and not have any side effects on Xonotic as an arena FPS.

except for inconsistencies from server to server, and even more splits in the community.

I get what you're saying. You want to make the game easier to mod. I just don't agree with it. I haven't agreed with it since UT99.
Reply

#10
A while back there was some discussion for a Xonotic fork called, I think Vengeance but it may have Vigilante or something else. At the time my thought was along the lines of using it as experimental branch, that is released often. Use the idea (whatever it was) behind Vagrant and add lots of new ideas. Some of these ideas won't be popular or well coded but they will let the greater community see what could happen and what might be Xonotic features in the future.

The "Weapons defined in text files" concept is suited to an experimental area. Go for it.

Sadly another version of Xonotic may split the small community of players.
Reply

#11
(05-23-2012, 04:30 PM)Spaceman Wrote: A while back there was some discussion for a Xonotic fork called, I think Vengeance but it may have Vigilante or something else. At the time my thought was along the lines of using it as experimental branch, that is released often. Use the idea (whatever it was) behind Vagrant and add lots of new ideas. Some of these ideas won't be popular or well coded but they will let the greater community see what could happen and what might be Xonotic features in the future.

The "Weapons defined in text files" concept is suited to an experimental area. Go for it.

Sadly another version of Xonotic may split the small community of players.

Never heard about that game, interesting to know. Is there more info about it, or any screenshots created of what was changed?

A split in the community is one reason I wanna avoid a fork. My fork was the long-discussed single player toolkit I posted about here, with which I want to make a framework for advanced single player games (with support for RPG components too). I initially wanted a fork because I thought some features couldn't fit Xonotic, but then considered adding them one by one and seeing what's ok and the developers approve of. This Single Player system is an idea I've been dreaming about for a bit and don't wanna give up on, but it requires some less popular features for an arena game (even if they don't affect or change it).

Like I said, ONE reason for the text weapons is the ability to have such single player missions use their own weapons, which suit their environment. Especially if Samual's changes get in, I won't even have a shotgun in my story, and the default Xon weapons aren't good for it (nor would weapons in my story belong in the Xonotic code the slightest). So to avoid a fork, I'm thinking of adding some of those features to Xon... also because they could benefit ideas other than my SP system. For the text weapons, that's just one reason I think they're very good... the others are described as well.
Reply

#12
Mircea, why limit yourself? If you have a vision that you want to bring to life, why change it to suit Xonotic? Why not just create a standalone game and see where it goes?

Just curious.
Reply

#13
(05-23-2012, 01:48 PM)MirceaKitsune Wrote:
(05-23-2012, 11:40 AM)Samual Wrote: FYI this requires entire weapon system re-write... it's basically totally not feasible.

I know about the rewrite. Like I said it will take quite some effort, but I think the results will be very worth it, and it's an idea I believe a lot in. I believe this is overall less hard than the panel hud probably was, as one example.

No, this is much MUCH larger and more difficult than the panel hud. This overall is probably about 10,000 lines of code to remove and re-write, plus you have to get the old functionality of all the weapons totally reimplemented... The benefits of this are minimal compared to the work required, I really don't think this is worth it at all. It's easy to make a mutator or new weapon anyway, and the balance is already very configurable.

Really, it would be a waste of time to do this. It's not relevant to default game design as tZork has pointed out, and it may be harmful overall due to the disparity between servers and mods as pointed out by Chryyz. This is the kind of thing which you only do at the start of a project, by now you're literally having to start from scratch and ditch 75% of the weapon system.



Another thing I should mention -- you could easily do the single player with whatever weapons you want ANYWAY, just like the mutators. I'm not removing the Shotgun from the game, for example, i'm simply stripping it out of core gameplay by default.
Reply

#14
(05-23-2012, 06:17 PM)Samual Wrote: No, this is much MUCH larger and more difficult than the panel hud. This overall is probably about 10,000 lines of code to remove and re-write, plus you have to get the old functionality of all the weapons totally reimplemented... The benefits of this are minimal compared to the work required, I really don't think this is worth it at all. It's easy to make a mutator or new weapon anyway, and the balance is already very configurable.

Really, it would be a waste of time to do this. It's not relevant to default game design as tZork has pointed out, and it may be harmful overall due to the disparity between servers and mods as pointed out by Chryyz. This is the kind of thing which you only do at the start of a project, by now you're literally having to start from scratch and ditch 75% of the weapon system.



Another thing I should mention -- you could easily do the single player with whatever weapons you want ANYWAY, just like the mutators. I'm not removing the Shotgun from the game, for example, i'm simply stripping it out of core gameplay by default.

I believe it's very much worth the effort. And like I said, it's not just the shotgun being removed, but also wanting to make Xonotic things with different weapons that never existed (or should exist by default) in Xonotic. Not just for single player, but even special maps and other uses.

Anyway, that's what you think and it's ok. All I ask though is that if I manage to get the code working bug-free (and without bad side effects), give it its chance and don't reject it. I'll try to do it by myself in some time if no one else joins in, since I'm confident it can be done and it's not that difficult (just a lot of work).
Reply

#15
Well ... I think that this is a great idea ....
may be difficult to implement ? idk ... I have never looked at the code

two suggestions
1 ... make it possible for maps to have custom weapons ... without making any balance changes or modding ... that was we can have more flavor (rainbow hlac's) but still be consistent (same map always has special weapon consistant)

2 ... make it possible to edit the txt "in game" (console) so that I don't have to restart xonotic for every tiny change
Reply

#16
A map with custom weapons will make the entire server unpure. Consider that. Maps with special configs have been a controversial topic before, too.

Also, you say there is zero performance overhead because everything is read into memory when the game starts... So what about all the branching points for each feature? if(hitscan), if(spread), if(headshots), if(guided), if(bounce),... I don't know what it adds up to, but that's not zero overhead.
Reply

#17
I just spoke with divVerent about the architecture of the text file. He agreed that doing everything with cvars (no text file) is best, and I feel the same way. This should not reduce performance, and at worst add some unnoticeable memory usage. Cvars are added all the time, and I'll try to use as little as possible.

(05-23-2012, 07:28 PM)hutty Wrote: Well ... I think that this is a great idea ....
may be difficult to implement ? idk ... I have never looked at the code

two suggestions
1 ... make it possible for maps to have custom weapons ... without making any balance changes or modding ... that was we can have more flavor (rainbow hlac's) but still be consistent (same map always has special weapon consistant)

2 ... make it possible to edit the txt "in game" (console) so that I don't have to restart xonotic for every tiny change

Maps will be able to have custom weapons by executing their custom balance file, just like any cfg. And since we're aiming on doing it with cvars, everything will be doable in realtime on the server (though if you add a new weapon, you must restart the map for it to update).

(05-24-2012, 01:01 AM)Mr. Bougo Wrote: A map with custom weapons will make the entire server unpure. Consider that. Maps with special configs have been a controversial topic before, too.

Also, you say there is zero performance overhead because everything is read into memory when the game starts... So what about all the branching points for each feature? if(hitscan), if(spread), if(headshots), if(guided), if(bounce),... I don't know what it adds up to, but that's not zero overhead.

People can already create maps with almost anything customized, and could since the first days of Nexuiz. If you have mymap.bsp and create a mymap.cfg file, you can basically change any functionality. Usually, maps like this are not accepted on any default server, and will certainly never "take over". They are for special servers that want to run weird experimental stuff, but the bounds between those servers and normal ones will always be well defined. I think mods are similar to game types in this sense... you want CTF you go to a CTF server, or if you want DM you go to a DM server, but most servers are decided on which they represent and there's plenty of each.
Reply

#18
In 9 days I'll be going to the seaside for approximately 3 weeks. I'll have my laptop with Xonotic on it, but am not planning to code there. I wish to begin work on this change when I return, and wanted to revive the topic until then and also to post an update.

Since the final decision is to do this with cvars and not a text file, I'm suggesting a two step solution. The first change can even be merged before the second one is ready. Those are:

First, turn projectiles into cvars while leaving weapons hard coded. This would basically complete the existing balance settings... since you can already tell a weapon the damage, speed, spread, etc. of its projectiles, but will also be able to specify what projectile is spawned. That means making the Rocket Launcher shoot bullets, the UZI to spawn grenades, or anything an admin wishes to do on their server.

The second step would be de-hardcoding weapon definitions so weapons themselves can be cvared, allowing admins to fully remove guns and create their own. There would no longer be a Rocket Launcher, Electro, Shotgun, etc. in the code, just a file which reads cvars and creates weapons when the server starts, assigning them to the chosen weapon slot and spawn entities of the map.

The first part will be easy, and mainly requires moving projectile logics to a common file then choosing which and how to use based on cvars. I think I can do this one on my own. The second part will be quite difficult, as weapons will need to be removed from the code and flexible removal / addition of new ones must be allowed.

I'd like to know who's willing to help with this part once it's time (probably some months from now). Also who else supports the feature or plans to use it, so I know if to get started sooner or later. Again, this is possible to do with a bit of work, and will not affect players or change anything by default (just make it possible for people who mod Xonotic to customize weapons without editing the code). Please post your thoughts in the meantime.
Reply

#19
Can't say if I gonna use it or not, but it sounds interesting.


Have a nice trip! Smile
Reply

#20
I am in full support of this ...
the possibilities are endless ...

:: hutty starts daydreaming about
::
:: factory levels with garbage bins of malfunctioning nexes
:: rainbow HLACs
:: experimental weapons in the testing facilities
:: and soo much more .....
Reply

#21
Please inform this uninformed soul:

- Won't the weapon creator basically be limited to all the things that the coder came up with beforehand? Could a weapon creator for example invent something totally new like a chainsaw or flamethrower without the code thinking of those options first and adding support for the needed characteristics?

Depending on the answer above, yes I would possibly use it. I have always wanted to make myself an arsenal of differently coloured spray paint cans to have fun with for example, but never had any clue on where to start :p
"Yes, there was a spambot some time ago on these forums." - aa
Reply

#22
(07-14-2012, 03:31 AM)PinkRobot Wrote: Please inform this uninformed soul:

- Won't the weapon creator basically be limited to all the things that the coder came up with beforehand? Could a weapon creator for example invent something totally new like a chainsaw or flamethrower without the code thinking of those options first and adding support for the needed characteristics?

Depending on the answer above, yes I would possibly use it. I have always wanted to make myself an arsenal of differently coloured spray paint cans to have fun with for example, but never had any clue on where to start :p

Projectile types need to be in the code, so the weapon creator can have what to hook and specify. However, one should be able to do most weapon ideas without needing code changes at any time.

For example, a chainsaw flame thrower should be possible. It would set a projectile similar to the fireball for flame throwing (but higher frequency, less lifetime, and no explosion) and the code of the shotgun's melee for the chainsaw (just triggered repeatedly and with a chainsaw sound).

However, if an idea ever comes up and the code doesn't allow, simply add a new projectile behavior to the code and wait for the devs to merge it to master. I plan to make sure any idea someone might imagine is doable with the projectile types available when I'll start working on this.

[EDIT] Oh, spray paints? Those would work too Smile You'd simply make a projectile with a particle effect that leaves decals (like blood) and possibly deals no damage... and there's your spray paint. So yeah, so far any idea can be done.
Reply

#23
Thanks for clearing that up. I am now slightly less uninformed Smile
"Yes, there was a spambot some time ago on these forums." - aa
Reply

#24
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.
Reply

#25
Why not do some sweet documentation how the weapon's code work?
Reply



Possibly Related Threads…
Thread Author Replies Views Last Post
  Speech to text, or almost voice chat oblector 0 937 06-30-2022, 06:29 PM
Last Post: oblector
  [Info] Fedora / Redhat / CentOS -- FirewallD and SystemD Service Files for dedicated TimelesslyPrecise 3 2,720 06-04-2020, 09:36 PM
Last Post: BuddyFriendGuy
  New feature review/test: Private Server List BuddyFriendGuy 17 17,381 01-07-2016, 08:05 AM
Last Post: BuddyFriendGuy
  missing shader files BuddyFriendGuy 0 2,677 07-05-2015, 07:19 PM
Last Post: BuddyFriendGuy
Question Text right to left (xonotic menu) kariminf 5 6,881 07-08-2013, 06:00 AM
Last Post: Mr. Bougo
  What is the general consensus on "dodging"? (UT's greatest feature IMO) ambition 7 6,867 01-26-2013, 02:42 PM
Last Post: lda17h
  Game key bindings working while typing text AviyaL 3 5,328 09-23-2012, 05:35 AM
Last Post: Mr. Bougo
  Bone based damage system (feature vote and debate) MirceaKitsune 42 45,199 05-17-2012, 01:29 AM
Last Post: CuBe0wL
Question media source files of vehicles? poVoq 13 10,497 02-21-2012, 06:16 PM
Last Post: tZork
  [SOLVED] How does the decompression of files within pk3s work? joshbeck 3 5,202 09-29-2011, 09:28 PM
Last Post: joshbeck

Forum Jump:


Users browsing this thread:
1 Guest(s)

Forum software by © MyBB original theme © iAndrew 2016, remixed by -z-