A game shouldn't be centered around use of the console for anything, it's an optional thing for advanced users. Of course, a mod may differ from this at the expense of playability...
My intention was to give suggestions, not help design or implement them. However, since you're actually considering it instead of insulting everyone, here's an opinion on how the multi-tool could work:
Secondary fire would open the menu (entirely possible as explained on IRC) to change which building is set, this menu could be off to the side a bit (not sure how this would be done) with a live preview in front of the player (or just those barebones previews normally shown).
Primary would continue to be placement option, though perhaps it should have a "build" delay or something so it doesn't feel instant and cheap/unnatural. One would need to hold in the button while it builds.
I would also suggest moving the buildings into a buffer (like the player model selection menu) and pulling their information from text files, so you don't need to add new ones to the code.
This doesn't really speed things up, but it does greatly clean up a massive code file, and maybe leads to more fancy things in the future (building categories, an easy way for someone to add or remove buildings they want or don't want, etc), minor things that would otherwise take modifying thousands of lines of code.
The gamemode your mod still uses is really bad, and was removed for good reasons.
Also keep in mind, we can take anything you boast to us about; I've already taken a modified version of the day-night cycles, a couple of weapons and vehicles, but they're limited to servers like Jeff's, due to the quality of their assets.
I only mentioned a few features I know would be a nightmare to port, the rest are hidden gems you'll have to dig for.
Xonotic has dual-wielding weapons, mini powerups (buffs), Quake mode, side-scrolling maps, minigames, mounting creatures, in-game radio and a whole bunch more stuff since 0.6, your mod just has a few features you've been boasting about for years.
You seem to forget you're talking to someone who is also a "do-er", but I like to focus on making my features work well as well as being enjoyable, and I don't need thousands of lines of duplicated code to do it either.
I did say after being parsed. There's more lines of code in the Xonotic codebase, but we parse it into a single smaller file with macros and such removed to speed up compiling and allow more advanced scripts.
Besides, most of what you've added is unnecessary extras that don't really complement the core gameplay, and often disrupt it.
I haven't bothered to implement most of the stuff from your mod, because the assets are extremely unfitting, to the point of looking like toy figurines.
Most of those buildings look like they were made in SketchUp...
Spells would be a really fun aspect if done well, but from what I've seen in your mod, they most certainly are not. Maybe I'll take a crack at a good version eventually, not everyone has all day to dedicate to "extra" stuff though.
Oh, and for the record, your code quality is the reason you can't use GMQCC (even the version included) for everything.
It should be possible even with your code scale to clean it up a bit (and probably fix the use of -std=fteqcc), but it wasn't a minor tweak, so I'm not sure what it requires entirely.
If you're going to boast about your mod being superior, you should at least expect some nitpicking and criticism...
While it doesn't crash to the best of your knowledge, it most certainly does waste resources. Even the best computers run extremely slowly, not just because of QC or the high poly models.
This is a product of poor implementation, and a prime of example of why "just doing it" without planning for such crazy expansion is bound to fail (not in the exploding kind of way, but in a way that every new thing you add to it requires doubling the overhead).
Not to mention the code duplication beyond imagination... I mean, come on, 35 thousand line code files? That's bigger than the entirety of vanilla Xonotic's codebase after it's been parsed, and a subject of horrible code duplication, all of which adds up to a huge progs file, surprised you haven't already reached GMQCC's limits...
A game shouldn't be centered around use of the console for anything, it's an optional thing for advanced users. Of course, a mod may differ from this at the expense of playability...
My intention was to give suggestions, not help design or implement them. However, since you're actually considering it instead of insulting everyone, here's an opinion on how the multi-tool could work:
Secondary fire would open the menu (entirely possible as explained on IRC) to change which building is set, this menu could be off to the side a bit (not sure how this would be done) with a live preview in front of the player (or just those barebones previews normally shown).
Primary would continue to be placement option, though perhaps it should have a "build" delay or something so it doesn't feel instant and cheap/unnatural. One would need to hold in the button while it builds.
I would also suggest moving the buildings into a buffer (like the player model selection menu) and pulling their information from text files, so you don't need to add new ones to the code.
This doesn't really speed things up, but it does greatly clean up a massive code file, and maybe leads to more fancy things in the future (building categories, an easy way for someone to add or remove buildings they want or don't want, etc), minor things that would otherwise take modifying thousands of lines of code.
I forgot the most important feature of all...
Hats. We have hats.
The gamemode your mod still uses is really bad, and was removed for good reasons.
Also keep in mind, we can take anything you boast to us about; I've already taken a modified version of the day-night cycles, a couple of weapons and vehicles, but they're limited to servers like Jeff's, due to the quality of their assets.
I only mentioned a few features I know would be a nightmare to port, the rest are hidden gems you'll have to dig for.
Xonotic has dual-wielding weapons, mini powerups (buffs), Quake mode, side-scrolling maps, minigames, mounting creatures, in-game radio and a whole bunch more stuff since 0.6, your mod just has a few features you've been boasting about for years.
You seem to forget you're talking to someone who is also a "do-er", but I like to focus on making my features work well as well as being enjoyable, and I don't need thousands of lines of duplicated code to do it either.
Such childish behaviour is why nobody takes you or your work seriously... What's the point applying reason and logic to someone who lacks them?
For what it's worth, monsters took 4 years to reach a mature enough stage to be included in the game.
I did say after being parsed. There's more lines of code in the Xonotic codebase, but we parse it into a single smaller file with macros and such removed to speed up compiling and allow more advanced scripts.
Besides, most of what you've added is unnecessary extras that don't really complement the core gameplay, and often disrupt it.
I haven't bothered to implement most of the stuff from your mod, because the assets are extremely unfitting, to the point of looking like toy figurines.
Most of those buildings look like they were made in SketchUp...
Spells would be a really fun aspect if done well, but from what I've seen in your mod, they most certainly are not. Maybe I'll take a crack at a good version eventually, not everyone has all day to dedicate to "extra" stuff though.
A single file being bigger than the codebase just shows how unoptimized your code is, not how superior it is.
And last time I checked, you still need FTEQCC for your menu code.
Oh, and for the record, your code quality is the reason you can't use GMQCC (even the version included) for everything.
It should be possible even with your code scale to clean it up a bit (and probably fix the use of -std=fteqcc), but it wasn't a minor tweak, so I'm not sure what it requires entirely.
If you're going to boast about your mod being superior, you should at least expect some nitpicking and criticism...
While it doesn't crash to the best of your knowledge, it most certainly does waste resources. Even the best computers run extremely slowly, not just because of QC or the high poly models.
This is a product of poor implementation, and a prime of example of why "just doing it" without planning for such crazy expansion is bound to fail (not in the exploding kind of way, but in a way that every new thing you add to it requires doubling the overhead).
Not to mention the code duplication beyond imagination... I mean, come on, 35 thousand line code files? That's bigger than the entirety of vanilla Xonotic's codebase after it's been parsed, and a subject of horrible code duplication, all of which adds up to a huge progs file, surprised you haven't already reached GMQCC's limits...
Integers don't exist in QuakeC (we fake it in newer Xonotic releases).
Pages