Research?

[Argh]

... and then make "research items" "units" that were non-blocking (this is possible) with a limit of 1... problem solved

[Ling_Lover]

Alternately, instead of a building, use an invisible, invincible, flying unit.

Like that?

[KDR_11k]

Of course you have to play on Com Ends Game, then.

[MadRat]

The reason I like prerequisite is because it means with the addition of said technology unit (i.e. a STEALTH TECHNOLOGY LAB) you can produce the advanced units. Without the advancements, you still have a plant that builds not as advanced units. Would add massive depth in the build trees to the plants.

[zwzsg]

Just to make it sure all are aware, but upgrading units, such as new weapon, or stealth (actually null range jamming, but it's the same), is already possible with scripts.

The Talon race, (for the TA engine), already implement that, with four commander upgrades
(aa missiles, shields, drone thing, and radar/sonar/jammer): http://www.tauniverse.com/forum/showthread.php?t=36206 (credits to TheRegisteredOne)

Of course it doesn't solve the issue of how to add new units to the tech tree, or change stuff that can't be changed by script. And some will complain that they don't like such script based solution and prefer more TDF or FBI tags, and more hard coded functionnalities of the engine.

[KDR_11k]

How do you trigger those upgrades?

[zwzsg]

Have you followed link?

Well Tro explained it to me last night on MSN, so here is what I managed to get from the conversation.

You build an upgrade module which is really expensive. Once built, it is able to build several kinds of units (but only one, I persume). These units are commander upgrades which are very cheap to build. If you build the shield one, once built it is attached to the upgrade module, and can't move.

The commander detects that a shield upgrade exists and activates the necessary shield feature. If the shield module dies, then the commander looses that feature.

If you're asking for what's the actual code, my guess is there's a commander script that goes like:

Code: Select all

piece ...,aamissile_backpack,...;

#define AAMISSILE_UPGRADE_HEIGHT 4654654
// measure the height of the unit providing the "aa missile upgrade"
// with a caliper from http://www.unituniverse.com/?p=u&v=5468

static-var ..,aamissile,..;

UpgradeCheck()
{
	var u,nbr_aamu;
	sleep rand(0,500);
	while(1)
	{
		nbr_aamu=0;
		for(u=1;u<=(get MAX_ID);++u)//For all units
		{
			if( (get UNIT_HEIGHT(u))==(AAMISSILE_UPGRADE_HEIGHT))// Is it a missile upgrade?
			{
				if((get UNIT_TEAM(u))==(get UNIT_TEAM(get SELF_ID)))// Does it belong to player?
				{
					++nbr_aaamu;// Count one more missile upgrade
				}
			}
		}
		if((aamu>=1) && (aamissile==FALSE))//If at least one upgrade present and the comm isn't upgraded yet
		{// Add missile backpack
			aamissile=TRUE;
			show aamissile_backpack;
		}
		if((aamu==0) && (aamissile==TRUE))//If no more upgrade yet the comm still has it
		{// Remove missile backpack
			aamissile=FALSE;
			hide aamissile_backpack;
		}
		sleep 2100;// 2.1 seconds between each check
	}
}


Create()
{
	aamissile=FALSE;
	...
	start-script UpgradeCheck();
}


AimTertiary(heading,pitch)
{
	signal ...
	set-signal-mask ...
	while(!aamissile)
	{
		sleep 250;
	}
	turn ...
	wait-for ..
	return(1);	
}

Well, I haven't looked at what code TheRegisteredOne actually used, but that's how I'd do it if I had to anyway. Minus all the typos and stupid errors I probably introduced by typing that into notepad on the fly, instead of copying a real tested script.


Loosely related, but while we're at it, here's excerpts from TAU > TAWP > Evolving commanderss:

All right, let's take a step back and look at the merits of both suggestions.

*Puts on his unit analysis (moose) hat.*

We want to make the Commander upgradable, so that they can serve a greater use as the game commences. There are currently two major suggestions on how to get this to work.

The first one will be called the "evolution theory."

In this theory, the Commander receives promotions based on number of kills the Commander has. The more kills the Commander has, the higher the upgrade.

Benefits:

1.This has been proven to work in TA: Devolution.

2. Commanders can become more useful as the game goes on.

Problems:

[...]

2. Attacking with a Commander, or having a Commander in an enemy base is highly taboo.

The second theory is what I'll call "addition theory."

In this theory, the Commander may build "shells" which, when loaded with the Commander, would become an upgrade for the Commander. The more costly the shell, the more powerful it becomes.

Benefits:

1. A variety of shells could be constructed. One shell might give a Commander Adv. Nanolathing ability, while another might make the Commander into a certifiable Assault Mech.

2. If you aren't happy with the upgrade, the Commander can be unloaded, and be reloaded into another shell, or the Commander could stay in it's default form.

3. Other units (possibly mercenaries?) could be constructed that would get in these shells as well.

4. It would make the Commander increasingly useful as the game progresses.

Problems:

1. This has never been done before to my knowledge.

2. The shell has to be useless without the Commander, so this means that some special scripting will need to be done.

3. The shell can only load the Commander, no other units.

If there is anything I missed, please say so.

I think we should at least pursue addition theory to see if it is at least feasible. I think that by making upgrades available to Commanders before they go into battle, you will give them a better chance at surviving.

By all means, if evolution theory is ready and working, keep it. It will still be useful, even after addition theory is working.

My enthusiasm for addition theory is because of how much it can offer. This would be it's specs.

Shells would have a mobile chassis, which makes the unit able to move without anything loaded on it.

The shells special abilities (nanolathing, weapons, etc,) would be inactive as long as the unit was unloaded.

These shells would have the same abilities as the Commander (in order to maintain the illusion that the Commander has the shell attached, when in reality, the unit you see is really going to be a transport that looks like the Commander with a certain shell on.

Each shell will have a model of the Commander, which will be hidden until the Commander was loaded, at which point it would be unhidden. Connected to the Commander model would be the "shell" part of the model. It would display the cosmetic changes to the Commander model.

Unit would have to be able to load the Commander and the Commander alone. (Other units could be added to this list later).

The unit would be buildable and many configurations could be available, depending on the Commander's mission.

Some configurations that come to mind.

Armored Configuration. The Commander would be loaded into this configuration, and would be able to withstand a nuclear attack. The downside is that it would carry no nanolathe, build menu, or weapons to counter enemy forces. Think of it as a bomb shelter.

AA Configuration: This shell would have the normal nanolathing, build menu, and D-gun, but it would also feature an anti-air missile. This config would be best for when you're expanding your over a large area with your Commander.

Heavy Hitter Config: This shell would have normal Commander abilities, but instead of having an light laser, it has a heavy laser, along with better armor. Think L2 upgrade.

Defense Config: This would switch, making the Commander able to build defensive structures (but no factories, alas!) This is good for when you need to build a firebase quickly.

FARK Config: Normal Commander abilities, but the nanolathing capability is doubled, good when you're commander is assisting build projects. In addition to this, the shell would have an air repair pad that would service injured aircraft. (Note, you wouldn't need to give the shell a D-gun or a normal Com laser, as the airbase=1; tag allows transported units to fire from inside a transport (in this case, the Commander.)

Mech Config: The Commander loses his build menu and nanolathing, but in return he gains assault armor, an Annihlator laser and the D-gun.

AMD Config: The Commander loses his ability to build factories, but in return he can build and launch Anti-Nukes.

Nuke Config: The Commander loses his ability to build factories, but in return he can build and launch anti-nukes.

Supreme Commander Config: A combination of an advanced build menu, air repair pads, and a nuke launcher. Ultimate upgrade.

Flying Config: The Commander has his own personal jetpack in this upgrade. Better armored then a normal transport, allowing fast and safe transportation for the Commander.

Advanced Commander Config: Heavy laser and L2 build menu make the Commander more powerful.

So, for even a couple of these configs to work, we'll need a transportation script, an enabler script, along with the normal scripting needed to produce a normal commander. Using the Commander script and model will make things simpler, all that would really need to be added to the individual models would be the cosmetic (or not) changes.

Of course, an unload script would be needed, as with any other animations.

So yes, it is complex and yes, it is time consuming, but it probably isn't outside the realm of possibility. If it pursued, it would be worth the work.

Artalion forgot the third theory, which I'll call the "structure theory"

A variety of upgrade center could be constructed. The commander detect the presence of such structure, and upgrade accordingly.

Benefits:
- It is the only theory which allow players to combine upgrades. (ie, I take Armor + Super laser but not Radar, while someone else take better dgun + radar but no armor, while the next player is so rich he takes all three.)

Problems:
- Xon's recorder becomes compulsory to detect that the building is entirely constructed, and not under construction.


Oh, and in the evolution theory, the commander can upgrade more than twice. Just it's hard to find three things that can be changed independantly.

And imo the shell method is the simplest to implement: You take any level 3 grade unit, add a regular OTA loading script, with the addition of if(get UNIT_HEIGHT(id)==ARMCOM) (where ARMCOM is a constant representing the height of the commander, already defined in some .h that Wotan has). Ok you must also put store 1 in a static-var in the loading process, and store 0 during the unloading, and jam building, weapons, and everything else useful when it is at 0. Hmm ok after all it's like an evolving script. Save that you work on two units, with two 3do and two scripts, which makes it much more clear and straighforward than when everything has to be mixed on the same unit

the unit you see is really going to be a transport that looks like the Commander with a certain shell on. [...]Each shell will have a model of the Commander, which will be hidden until the Commander was loaded, at which point it would be unhidden.

I was more thinking about leaving the loaded commander visible, by attaching it to an external piece rather than to 0 - 1. Some shell would even be isairbase=1; to let the comm use his regular weapons.

[KDR_11k]

We all know that units can be upgraded through script but we'd like to see being able to trigger these upgrades through research instead of building units.

[zwzsg]

Lessee:

Triggering upgrade through research:
- You select the research center building, and click the "research" icon in its menu.
- There's some progression bar, ressource being consummed, etc..
- Once the research is complete, some unit gain new weapons/armor/ability


Triggering upgrade through: script + building unit:
- You select the research center building, and click the "research" icon in its menu.
- The research center start buildings a special beacon unit, with some progression bar, ressource being consummed, etc..
- Once the special beacon unit is complete, some unit gain new weapons/armor/ability

What's the difference?

[KDR_11k]

You end up with a beacon unit.

[zwzsg]

So what? It's not like the player has to notice. "Unit" does not imply "a tank or kbot the player can select and drive around". For instance if it's auto-grabbed by the research center, no one but modders would know an unit was actually created.

[KDR_11k]

It'd still die with the research center and the research would be lost.

Of course if global variables were implemented we could just build an invisible unit, make it set a variable and make it destroy itself again with all further attempts to build the unit leading to it self-destructing the moment it's created.

[manored]

In fact there is no diference... except that the button to research that thing wouldnt vanish (even if it didnt worked anymore) and some anyoing people could get anyoned with that.

[Pxtl]

Actually, just for graphical prettyness, I'd have the upgrade as a physical model - an untargetable, invincible, unarmed gunship that flys off into the maximum cruisealt and hovers there for eternity. So when the upgrade is complete, something flies away from the research lab, and you can see it being built, and assist on it.

Hell, you could even give the upgrade a limited lifetime if you wanted by using the unit's health as a countdown timer (if there is a way to self-destruct a unit) - in that case I'd keep it visible instead of flying it off to the stratosphere.

[Guessmyname]

Except that that unit would count towards the player's unit limit, and would have to be destroyed in a com ends game, which is hard when it's in the stratosphere.

That's a stupidly hacky workaround...

[manored]

I think you could give the unit negative regeneration to make it die after some time... But in fact it would be a problem to end games in no com ends games...

[smoth]

I would be fond of a more traditional upgrade system ala warcraft and/or build requirements for certain units ala starcraft. All this other stuff is not so apealing to me.

[MadRat]

One problem with my idea - I've just thought about after reading the previous handful of posts - is that the gui wouldn't hide the button for the modder. You'd need a smart shuffling of the buildpics in reaction to the tech tree/buildtable prereqs.

[Peet]

I would be fond of a more traditional upgrade system ala warcraft and/or build requirements for certain units ala starcraft. All this other stuff is not so apealing to me.

Both do both. O_o

[Neddie]

I'm looking into some pseudo code, but zwzsg gave you the easiest method I can see from where the engine is now.