EMG and Gauss cannons should gain a new rendertype graphic

[jerebaldo1]

Ever since the release of TA I've always been dismayed at the lack of graphical flair when it comes to most of the gun type weapons.

Lasers have different colors, alphas, and thickness, missiles have multiple models, bombs have their own model, flames and lightning guns too are unique. But EMG, gauss, and plasma cannons are all lumped into the same rendertype=4 graphical effect: the ubiquitous and boring yellow ball. I do believe it's high time we spruced up that area of spring: it would make battles look much more interesting. So I'm proposing a rendertype 7 and 8 for these types of weapons as an option.

Seem feasible?

[Argh]

Where JC is currently taking that area of Spring is very exiting- we will, very likely, have access to all of the projectile classes, with the ability to tweak them. This is going to lead to a lot've new graphical effects.

[Neuralize]

AND FREEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEDOM

[Argh]

I dunno about "freedom". But it sure would allow us to make things a lot prettier.

[Sean Mirrsen]

Unified weapon classes ftw!

Seriously, why do we stick to this age-old separated weaponclass system, when we could integrate all individual Projectiles into one CWeaponProjectile, and all weapon launchers into one CWeaponLauncher.

I know it's a lot more work than it sounds, because I've tried already, but the benefits of this system are immense, they are even worth the changing of all existing mods that will undoubtedly be necessary when the system is introduced, since the nature of it doesn't allow backwards compatibility. It will also allow to introduce makeshift weapon scripts, consisting of simple tags like "transformTo", "transformDelay", "spawnWeapon", "spawnDelay", "spawnRate", that will allow a near-limitless variety of weapon effects.

[Argh]

I agree with you. Personally, I think that maybe you should try writing up the unified weapon class specifications working "to the side" of the current ones. I strongly suspect that just ignoring the current system and starting over again from scratch will be faster than the current route of trying to gradually unwind the current code and unify it. Just a thought.

[Tobi]

Merging all projectile code together in one class only makes the code less maintainable IMHO. Now every projectile is a simple piece of code which does just what is has to do. So it's easy to maintain, change, debug, etc. It's also really easy to add new projectiles.

Unifying everything in one big projectile class has only disadvantages:
1) Code is unmaintainable, you get if () {} else {} hell just like with units currently.
2) You spill a lot of memory because every projectile uses same amount of memory (unless you start allocating separate memory per projectile, thus increasing chances for memory leaks/bugs. So if there's one advanced projectile which uses lots of mem every tiny particle will use same amount.
3) It's freaking hard to add new projectiles. You have to add more if and else clauses at random places, make tags and other hackish stuff.

So better not do that.

Better design a _good_ way to merge projectiles into eachother, like specifying an alpha parameter on CProjectile::Draw and making a new CMergeProjectile which handles two CProjectiles and slowly morphs one into the other by decreasing alpha for one and increasing it for the other.

Only way I'd approve a unified projectile is if it was fully scriptable / generic without fugly hacks. And note that this can easily be added to the current system.

[AF]

Merging say two projectile classes together so that they're more generic and can take properties of eachother would be a start, focusing on genericly applying attributes.

That way it can be a gradual process making it easier to jump to a generic scripted unified class.

[Theotherguy]

I think it would be a nicer model to have a base projectile class, and then have all of the normal weapons classes extend from that class. That way, it would be much easier to make changes to the entire weapons class, and maintain weapons as a whole. I would disagree that having seperate classes makes it easier to add new weapons, since you have to rewrite alot of code that would already exist in the base class. With a standardized weapons class, adding a new weapon would be as simple as putting in an extends statement, calling the superclass constructor, and then adding in the special attributes for the weapon (for instance, a laser could be represented as a superfast projectile, and have special attributes such as thickness and alpha, etc.)

[jerebaldo1]

yes, like if I could specify the color, length, width, alpha, size of those little plasma balls I think even that would be enough to make a distinguished emg weapon. I could flatten out and recolor the existing yellow balls to make them look more like bolts as opposed to shells.

With respect to the gauss, I think it would require scripting to get the railgun-like effect that I want to see on those weapons.

[Tobi]

I think it would be a nicer model to have a base projectile class, and then have all of the normal weapons classes extend from that class. That way, it would be much easier to make changes to the entire weapons class, and maintain weapons as a whole. I would disagree that having seperate classes makes it easier to add new weapons, since you have to rewrite alot of code that would already exist in the base class. With a standardized weapons class, adding a new weapon would be as simple as putting in an extends statement, calling the superclass constructor, and then adding in the special attributes for the weapon (for instance, a laser could be represented as a superfast projectile, and have special attributes such as thickness and alpha, etc.)

that's how it works now (and that's what I said in my prev post)

[AF]

Then perhaps a lua binding put in as another class deriving from the abse class would be useful.

[Sean Mirrsen]

Actually, the only way to make truly omnipotent projectiles really is the "tags and IF clauses" hell of a thing you're talking about. HOWEVER. The projectile's interaction with the world consists of a rather limited amount of events, so for example why have different classes for similar weapon types? A depthcharge and a cannon, the only difference is that a depthcharge does not explode on contact with water and sinks. Similarly, a torpedo is different from a missile in the way that it can only selfpropel underwater. A laser is not a cannon shot only because it flies straight and has a different graphic. A bomb is not a missile because it cannot selfpropel, and not a cannon shot because it doesn't receive an impulse at launch. There are loads of similarities, why separate them? You'll have a lot more trouble accounting for different modder ideas in different projectiles and launchers, than if you were to implement those unified weaponclasses.

As for memory - in what way are projectiles different in this area currently? They either have a model, or not. Either emit smoke, or not. I think a lot of these things can be accounted for easily, but the system needs to be implemented first. Tobi, you already assigned me "a perfect junior task", can it be you're overestimating the tasks, or underestimating yourself?

[Tobi]

Tobi, you already assigned me "a perfect junior task", can it be you're overestimating the tasks, or underestimating yourself?

I don't really see your point with this. I assigned you the junior task because you yourself thought it was "like 5 minutes work" or words like that.

For the rest I'm trying to be realistic and try to think a bit longer term then "hey nice feature it works lets get it included, shame the code is unmaintainable but nevermind that".

To quote some person (dunno who, just remembered it): "Novice programmers think programming is hard, average programmers think programming is easy, experienced programmers know programming is hard."

I consider myself part of the last group (what did you say about underestimating myself? )

If I want to, I can probably convert the projectile system to a mess with ifs and else clauses in just one day, but it will inevitably introduce a whole load of bugs which take at least days to get rid off. Many probably undiscovered before release. Also you can't deny that a good abstracted system is easier to maintain then a whole if else mess. Look at the current projectile code: if I find a bug which happens with smoke projectiles only, I look in SmokeProjectile.{cpp,h}. That's a hell of a lot easier then browsing through at least 500 lines of if-else cluttered code which you need to have written to understand it (ie. is unmaintainable).
Note that some scripted system could be even better, but unless it's a really fast executing scripting language (compiled to machine code at runtime for example) you risk severe performance issues when thousands of particles are in the game world.

About overestimating the tasks, I don't think so either - you managed to get buildings rotated, but it took you several days. Also, at this moment it's still pretty hackish and can be abstracted much better (as JC explained), even tho it may work perfectly fine (haven't tested it myself yet). Sorry I still didn't get to explaining better what he means btw, I don't have that much time and I don't feel like doing nothing but forum posting.

E: of course there are even better solutions but I don't feel like making this post any longer

[Sean Mirrsen]

Heh. Ok, ok I get it. Yes, there probably would be a lot of bugs, but I still like the idea of the whole ifclaused mess as the basis for this... If(anything), this would be a nice step forward to some more advanced system, though I can't say I see what it could be.
The primary reason to me being so "insistive" is curiosity, as in "how bad could it be". And more importantly, since the idea is bugging me, I can't stop thinking about it, ending up bugging everyone else in the process. :) This probably isn't a perfect junior task, even with me being a moderately-experienced rookie (as in - I know making it is hard, but I think the idea in itself is rather easy), but will anyone mind me taking a stab at it?

[mongus]

Ever since the release of TA I've always been dismayed at the lack of graphical flair when it comes to most of the gun type weapons.

+1

weapon graphics in spring are sad. (inherithed).
only weapon that amuses me is the AA raven, xta pyros fire.. mavs fast rounds, ee laser tanks..
and the (now dissapeared?) original plasma shield. (current ones.. i pass).