A possibly stupid idea

[Pxtl]

The "morph" command seems like the most powerful, but simultaneously most backwards-compatible approach. The only problem with "morph" is that it may seriously bork some pathfinding if the unit morphs mid-path. Still, it would be the ideal approach for Siege Tanks, deployable buildings, veritechs, etc. There is an endless list of games that would require such transforming units.

Personally, I think there are 3 big new features needed for support of just about any unit people can think of. First is morphing. Second is sub-objects stuck to other units - zwzsg has done impressive stuff with this already. Third is "spells" in the build menu. Combine this stuff together and you could make all the units from any RTS that I can think of.

[Sean Mirrsen]

Heh. The last would require something like a "buildfire" weapon tag, and a buildpic tag. Then a certain weapon could be forced to fire only after its button is pressed. A new tag is also needed for those, instanthit, to let the spells immediately activate at target location without checking for obstacles. Not a five-minute work, but probably doable.

edit: can you clarify the second? sub-objects stuck to other units?

[AF]

Gabbas research and the use of voronoi diagrams could eb extended easily into 3 dimensions, it would take a little logner generatign teh data structrues but they'd get cached and they'd solve the problem.

[Pxtl]

Heh. The last would require something like a "buildfire" weapon tag, and a buildpic tag. Then a certain weapon could be forced to fire only after its button is pressed. A new tag is also needed for those, instanthit, to let the spells immediately activate at target location without checking for obstacles. Not a five-minute work, but probably doable.

edit: can you clarify the second? sub-objects stuck to other units?

If "buildfire" was simply a weapon, then that might not be powerful enough - ideally, it would also need to be able to spawn units at longer range than the normal building distance. For example, say you had a spell where you wanted to be able to spawn crawling bombs at a distance. There are numerous alternate possibilities - could a weapon be linked to a morph? One could easily concieve of a multifunction crawling bomb where the "spell" menu would have it self-destruct as a large stun-bomb, a normal bomb, or spawning a mess of mines.

As I said, the "spell" system would have to be carefully considered. While mainstream TA games would be wise to avoid it like the plague (spells are totally opposite to the anti-micro TA ideology), more conventional RTS mods frequently require spells. Likely the system will have to hook into a LUA script embedded within the unit. Fundamentally, the difference between scripts would be the selection interface, and the result of the actions could be just about anything that can be scripted. So what you would configure on the unit would be (a) what inputs the spell takes (select targets, friendly/enemy, location, nothing - what armour classes are acceptable targets, etc) (b) the icon, (c) the worker time, and (d) the script it fires. Considering (c), there are also nasty resource considerations - if you want people to assist, where do they assist? At the target? Or the source? If the spell takes some new "mana" concept instead of metal/energy, how does that work?

A spell system would have to be carefully designed - about the only thing I'm sure of is that the build menu is probably the right place to put it.

The sub-object thing was the result of a discussion elsewhere - the fact is that the only way to make a mobile factory or a mobile nuclear launcher is to attach an immobile unit to a mobile one. Zswgzwzws?? has already had some success with such an approach, but better native support for this feature would make it more effective. It would also allow commanders to have more granular control over superscalar units - if you have some sort of megaunit that has both regular close-combat capabilites and an LRPC, it makes sense to order the main body to move+attack one target while ordering it's LRPC sub-object to attack another.

[GrOuNd_ZeRo]

Meh, I always liked the tags in TA my self, they are simple and understandable, I don't care if we need a 100 more tags to get all the features we want, we can just make a library of tags and their function in the wiki.

as for scripting weapons, we could do it like this for clusterbombs:

[weapon1] //kept short and only displays main features.

dropped=1;
Twophase=1;
Weapon2=bomblet;
Weapontimer=1; //1 second until it goes to phase2

[weapon2]

dropped=1;
sprayangle=3000;
burst=15;

kinda like that, just with the 2 phase we could do a LOT of stuff, we also need more comprehensive support for weapons I.E. lasers that follow a ballistic path rather than a linear path or linear paths for ballistic weapons like a Gauss gun.

[Sean Mirrsen]

I'd say another tag, spawnweapon, to define what weapon it spawns when explodes, and maybe spawntarget that's set to either 0 - no target, shoot down, 1 - no target, shoot up, 2 - parent weapon's target, 3 - random target in range of the new spawned weapon.

[jcnossen]

Meh, I always liked the tags in TA my self, they are simple and understandable, I don't care if we need a 100 more tags to get all the features we want, we can just make a library of tags and their function in the wiki.

Developers care, and modders eventually too. Development will simply go faster if mods are not constrained by tags.

[GrOuNd_ZeRo]

It makes it easier on you but harder on us right?

[Pxtl]

Meh, I always liked the tags in TA my self, they are simple and understandable, I don't care if we need a 100 more tags to get all the features we want, we can just make a library of tags and their function in the wiki.

Developers care, and modders eventually too. Development will simply go faster if mods are not constrained by tags.

I still think that the best way to beef up the scripting/modding concept would be to have the system that reads and applies data created based on the old tag/script system be moddable, and re-implement the existing gameplay within said system. Thus, programmer-modders could extend the existing tag structure as they need for their mods, and unit-modders could apply those extended tag structures as needed for their units.

Either way, zswsg isn't the one to discuss this with, as he seems to be the only one to actually understand the current system anyways.

[Sean Mirrsen]

In the end, this'll boil down to using LUA scripts for both defining and running units. Script section Init: setmodel "armpw.s3o"; setmaxspeed 5; setwhatever true;. Then goes Create, and the rest of the script horde. It'll be very useful, keeping the entire unit, except for its model, in one file. Oh, and weapons could also be unit-specific! So that weapon power, weapon range, and other stuff, would also be part of the unit definition, and as such subject to change through the scripts!
But, actually, this thread is about unified unit class, which would also benefit from such a system, bringing Spring ever closer to the title of "the ultimate rts game shell".

[zwzsg]

Meh, I always liked the tags in TA my self, they are simple and understandable, I don't care if we need a 100 more tags to get all the features we want, we can just make a library of tags and their function in the wiki.

I agree. Tags are simple to use, easy to change. Not every modder has a degree in programming! What would be the point in having a powerful possibility, if it's so complex no modder can use it? In TA, modding unit could be as simple as editing text files in notepad.

[SwiftSpear]

I still think I prefer a direct engine referancing system for modding. Tags work well for simple thigns, but they break so increadibly fast when you have complex ideas or systems you want to impliment. Modders have no control at all over very simple game mechanic systems like the nuclear weapons war.