38 replies to this topic

[CodeCat]

Well since everything is new now, I figured this would be a nice place to organise all coding-related information. Please keep this topic clean, I intend it to be a reference point for those starting modding and not knowing where to start or what to do.


First of all, I get the impression that the days of 'put files in the right place' are over. Rather, I believe that mods will need to be compiled in a similar fashion to a C++ program, and then packed into a .big. After that, the original code will be unretrievable except for those who still have it. I foresee the emergence of open source modding...

Now, looking at the way models and stuff are made, it seems that using a model or any other asset in a file is merely a matter of <Include-ing it into the relevant file. In fact, I think that, in the end, the entire mod is composed of nothing more than a huge tree of files, one include-ing the other until everything is covered. So this would mean that there are NO SET FILENAMES and NO FIXED FOLDERS to put stuff in. As long as a file is included from another, it doesn't matter where it is. This gives modders an enormous freedom, but of course it comes at the price of no longer having a fixed structure that all modders can agree on. If I wanted to put all my GDI XML files in CnC3Xml/SomeStrangeFolderName rather than CnC3Xml/GDI, I could. I'd just have to make sure that all Include references are changed to reflect the new location.

The code itself seems easy enough, but I'm guessing most can be learned by looking at existing code. It also seems that apart from the XML structure, most of it actually looks pretty much like the INI files most of us here remember from Generals. Instead of having a list of INI declarations like so:

Object GDIPredator
  BuildCost = 1100
  BuildTime = 11
End

You just get a similar structure:

<GameObject
  id=&#34;GDIPredator&#34;
  BuildCost=&#34;1100&#34;
  BuildTime=&#34;11&#34;
  etc...
/>

So even if it's superficially different, I still believe that most of it is actually pretty much the same. Just a matter of getting used to. Also note the id= attribute. That's the one that actually gives things a name. It's therefore very important to give everything a unique id= tag! I'm not sure if the code has the concept of 'namespaces'. Namespaces would be a system where names can be grouped, and different units can share the same id= attributes. That would mean that if there were a separate namespace for Units, and another for Sounds for example, you could have both a Sound and a Unit with GDIPredator as the id= attribute. I'm just guessing here, but so far it doesn't look like the files have any id namespaces at all. So that means that id= attribute need to be unique across the entire mod/program. Keep this in mind!

[CodeCat]

I'm just going to post here as I find out more. Don't be afraid to comment or post your own findings, that's what this topic is meant for!

I've been looking at the weapon systems now, and it seems that weapons do not specify their own damage anymore. Here's a snippet from the Mammoth Tank weapon:

<WeaponTemplate
  id=&#34;GDIMammothTankGun&#34;
  ...
  />
  <Nuggets>
	<ProjectileNugget 
	  ProjectileTemplate=&#34;FXTankShell&#34;
	  WarheadTemplate=&#34;MammothTankShellWarhead&#34;>
	  <VeterancyProjectiles
		VeterancyLevel=&#34;HEROIC&#34;
		ProjectileTemplate=&#34;FXTankShell_Veteran&#34;/>
	</ProjectileNugget>
  </Nuggets>

Notice how it mentions a projectile object, and a 'warhead'. This system is new. Rather than setting the damage in the weapon itself, the 'warhead' is a separate weapon that gets used when the shell detonates. Here's its code:

<WeaponTemplate
  id=&#34;MammothTankShellWarhead&#34;
  />
  <Nuggets>
	<DamageNugget 
	  Damage=&#34;500.0&#34;
	  DelayTimeSeconds=&#34;0.0s&#34;
	  DamageType=&#34;CANNON&#34;
	  DamageFXType=&#34;GDI_CANNON&#34;
	  DeathType=&#34;NORMAL&#34; />
  </Nuggets>

I've also looked at the Armor.xml. And well, there are... five damage types in all. I'm not kidding, there's only 5 listed. I've no idea if it's possible to include more, but I'd say a lot of mods will be limited if 5 is all we can use. More info on this one would be nice...

[Vengence]

5!? Darn it. Hopefully I can add more. I am currently looking at animation coding. Big stuff, the animation modules alone makes the juggernaut XML over twice as large as a predator.

[CodeCat]

It seems my suspicions about the Include structure were correct. Here's what the documentation has to say:

Quote

MOD.XML:
Basic Explanation
This file is the main file that will be compiled by the BinaryAssetBuilderApplication. This file should include all files that you are MODding/editing. If it is not included in this file it will not be built.

This means that mod.xml is the 'master file' for any mod. This is the file you compile (using the BinaryAssetBuilder) and this is where your mod actually 'starts off'. Everything in your mod, from objects, models, weapons etc. etc. is all included from here one way or another. I've yet to find the mod.xml for C&C3 itself, but there's quite a chance that EA simply chose not to include it (to prevent people simply rebuilding the entire game and shipping it that way).


There's another thing I noticed. Ever so often you'll see a prefix before a filename that gets included from another. Like so:

<Include type=&#34;reference&#34; source=&#34;DATA&#58;static.xml&#34; />
<Include type=&#34;reference&#34; source=&#34;DATA&#58;global.xml&#34; />

<Include type=&#34;all&#34; source=&#34;ART&#58;Images/SampleUpdatedPackedImages.xml&#34; />

I'm referring to the DATA: and ART: things. The documentation helps us out here again:

Quote

BinaryAssetBuilder.exe.config
This file allows you to modify the behavior of the BinaryAssetBuilder program. What this section will cover however is only the search paths for the program. In the file you will find the section:

<assetbuilder
			serializedType=&#34;BinaryAssetBuilder.Settings,BinaryAssetBuilder.Core&#34;
		  schema=&#34;..\schemas\xsd\CnC3Types.xsd&#34;							
		  dataRoot=&#34;..&#34;
		  defaultArtPaths=&#34;.\Art&#34;
		  defaultAudioPaths=&#34;.\Audio;&#34;
		  defaultDataPaths=&#34;.;.\Cnc3Xml;.\Mods&#34;	 
	  >

dataRoot – Is the root folder for all data. This location is currently the main install directory of the MOD SDK.
defaulArtPaths – Default search path(s) prefixed with ART:. Please note that using this value will append a 2 letter subfolder consisting of the first two letters of your art asset.
defaultAudioPaths- Search path(s) for paths prefixed with AUDIO:.
defaultDataPaths- Default search path(s) for all data files included using the DATA: value. As currently setup it will search the current directory first, then the MODs folder, then the CnC3Xml folder.

BinaryAssetBuilder.exe.config is the configuration file for the BinaryAssetBuilder program, which builds (compiles) your mod. So all these DATA: and ART: prefixes specify where to look for a certain file, according to the config. This should make structuring and organising mod files a bit easier.

[CodeCat]

Ok, good news. No more FUD on the damage types, the XML Schemas provided very useful. The XML Schemas are basically files that say exactly which settings are permitted. Rather than describe the game or mod itself like the XML files do, the schema files describe the XML files. So there will be no more hidden INI settings that you have to discover through game.dat, because the Schemas will list every single setting that, for example, a weapon can have.

And of course, one schema file describes the armour types:

From MOD SDK\Schemas\xsd\Includes\DamageDef.xsd:

	<xs&#58;simpleType name=&#34;DamageType&#34;>
		<xs&#58;restriction base=&#34;xs&#58;string&#34;>

			<xs&#58;enumeration value=&#34;FORCE&#34; />
			<xs&#58;enumeration value=&#34;CRUSH&#34; />
			<xs&#58;enumeration value=&#34;SLASH&#34; />
			<xs&#58;enumeration value=&#34;PIERCE&#34; />
			<xs&#58;enumeration value=&#34;SIEGE&#34; />
			<xs&#58;enumeration value=&#34;STRUCTURAL&#34; />
			<xs&#58;enumeration value=&#34;FLAME&#34; />
			<xs&#58;enumeration value=&#34;HEALING&#34; />
			<xs&#58;enumeration value=&#34;UNRESISTABLE&#34; />
			<xs&#58;enumeration value=&#34;WATER&#34; />
			<xs&#58;enumeration value=&#34;PENALTY&#34; />
			<xs&#58;enumeration value=&#34;FALLING&#34; />
			<xs&#58;enumeration value=&#34;BLAST&#34; />
			<xs&#58;enumeration value=&#34;REFLECTED&#34; />
			<xs&#58;enumeration value=&#34;PASSENGER&#34; />
			<xs&#58;enumeration value=&#34;MAGIC&#34; />
			<xs&#58;enumeration value=&#34;CHOP&#34; />
			<xs&#58;enumeration value=&#34;HERO&#34; />
			<xs&#58;enumeration value=&#34;SPECIALIST&#34; />
			<xs&#58;enumeration value=&#34;FLY_INTO&#34; />
			<xs&#58;enumeration value=&#34;UNDEFINED&#34; />
			<xs&#58;enumeration value=&#34;LOGICAL_FIRE&#34; />
			<xs&#58;enumeration value=&#34;POISON&#34; />
			<xs&#58;enumeration value=&#34;LASER&#34; />
			<xs&#58;enumeration value=&#34;PLASMA&#34; />
			<xs&#58;enumeration value=&#34;FIRE&#34; />
			<xs&#58;enumeration value=&#34;ROCKET&#34; />
			<xs&#58;enumeration value=&#34;GUN&#34; />
			<xs&#58;enumeration value=&#34;CANNON&#34; />
			<xs&#58;enumeration value=&#34;GRENADE&#34; />
			<xs&#58;enumeration value=&#34;SNIPER&#34; />
			<xs&#58;enumeration value=&#34;MINE&#34; />
			<xs&#58;enumeration value=&#34;TIBERIUM&#34; />
			<xs&#58;enumeration value=&#34;STORM_SHIELD&#34; />
			
			<!-- Special case, understood by pipeline -->
			<xs&#58;enumeration value=&#34;ALL&#34; />

		</xs&#58;restriction>
	</xs&#58;simpleType>

Personally I doubt that the schema files can be changed to add new damage types. After all, the engine is coded around the schema files, and just changing the schemas would be like changing the engine. However, who knows what surprises there are still left for us...

[TankMaster]

Yeah, who knows. Guess we will all find out in time what the real limits of this engine are now. Hope we can change the XSD files, just will have to see.

[CodeCat]

I made another discovery that is going to make modders' lives very easy: inheritance. It is possible to base just about anything off another object. And with object I mean 'XML element' so not just actual ingame objects. It works for weapons, it works for armour types, etc.

Here's an example.

From MOD SDK\CnC3Xml\GDI\Structures\GDIConstructionYard.xml:

	<GameObject
		id=&#34;GDIConstructionYard&#34;
		inheritFrom=&#34;BaseStructure&#34;

Notice the inheritFrom= attribute. That points to the id of another object. BaseStructure is defined as such:

From MOD SDK\CnC3Xml\BaseObjects\BaseStructure.xml:

	<GameObject
		id=&#34;BaseStructure&#34;

It would be entirely possible to make BaseStructure inherit from something even more abstract, such as 'BaseGenericObject' if it existed. This makes it very easy to structure your code and make 'common denominator' objects based on what all units of a certain type have in common. You could also make a specific base type for shell-based weapons for example, or... well I'll let you do the thinking. Of course it's possible to override inherited values, so if you have one unit that fits the inherited 'template' except for one value, you could just override it and that was that. The possibilities are limitless!

[Kris]

CodeCat, on 24 Aug 2007, 21:18, said:

I'm just going to post here as I find out more. Don't be afraid to comment or post your own findings, that's what this topic is meant for!

I've been looking at the weapon systems now, and it seems that weapons do not specify their own damage anymore. Here's a snippet from the Mammoth Tank weapon:

<WeaponTemplate
  id=&#34;GDIMammothTankGun&#34;
  ...
  />
  <Nuggets>
	<ProjectileNugget 
	  ProjectileTemplate=&#34;FXTankShell&#34;
	  WarheadTemplate=&#34;MammothTankShellWarhead&#34;>
	  <VeterancyProjectiles
		VeterancyLevel=&#34;HEROIC&#34;
		ProjectileTemplate=&#34;FXTankShell_Veteran&#34;/>
	</ProjectileNugget>
  </Nuggets>

Notice how it mentions a projectile object, and a 'warhead'. This system is new. Rather than setting the damage in the weapon itself, the 'warhead' is a separate weapon that gets used when the shell detonates. Here's its code:

<WeaponTemplate
  id=&#34;MammothTankShellWarhead&#34;
  />
  <Nuggets>
	<DamageNugget 
	  Damage=&#34;500.0&#34;
	  DelayTimeSeconds=&#34;0.0s&#34;
	  DamageType=&#34;CANNON&#34;
	  DamageFXType=&#34;GDI_CANNON&#34;
	  DeathType=&#34;NORMAL&#34; />
  </Nuggets>

I've also looked at the Armor.xml. And well, there are... five damage types in all. I'm not kidding, there's only 5 listed. I've no idea if it's possible to include more, but I'd say a lot of mods will be limited if 5 is all we can use. More info on this one would be nice...

To be Honest, That Weapon system is not new. That weapon system was used in the Battle For middle Earth Series.
Example:

Weapon LegolasHawkStrike
	AttackRange = LEGOLAS_HAWKSTRIKE_RANGE
	WeaponSpeed = 321		&#59; dist/sec 
	MinWeaponSpeed = 241
	MaxWeaponSpeed = 481	 &#59; dist/sec Upper limit on scaling, when attacking past nominal "max" range
	FireFX = FX_RohanArcherBowWeapon
	ScaleWeaponSpeed = Yes&#59; Used for lob weapons, scales speed proportional to range
	HitPercentage	 = 100	&#59;When this weapon is used it will hit exactly 75% of the time.

&#59;All these delays are controlled by the special power. Basically the special power can
&#59;launch whenever it's ready.
	DelayBetweenShots		= 0										&#59; time between shots, msec
	PreAttackDelay			= 3000									&#59; we want isntant
	PreAttackType			= PER_POSITION
	FiringDuration			= 1000									&#59; Duration of the archer firing shot is 500ms.
	ClipSize = 1
	AutoReloadsClip = Yes
	AutoReloadWhenIdle = 1	
	ClipReloadTime = Min:1 Max:1
	AntiAirborneVehicle		= Yes
	AntiAirborneMonster		= Yes
	PreferredTargetBone = B_LLLID&#59; Likes to shoot things in their left eye.
	ProjectileNugget				   &#59; A Nugget that creates an Object and sends it to the target with a Warhead
	ProjectileTemplateName = LegolasSpecialArrow
	WarheadTemplateName = LegolasHawkStrikeWarhead
	End
	ProjectileNugget				   &#59; A Nugget that creates an Object and sends it to the target with a Warhead
	  ProjectileTemplateName = LegolasSpecialArrow2ndArrow
	WarheadTemplateName = LegolasHawkStrikeWarhead
	End
End

;------------------------------------------------------------------------------
Weapon HeroCrush &#59; Used when a hero runs someone over.  
  LeechRangeWeapon	  = Yes
  AttackRange		   = 9999999.0
  MeleeWeapon		   = No
  DelayBetweenShots	 = 0		   &#59; time between shots, msec
  PreAttackDelay		= 0&#59;PreAttackDelay+FiringDuration = UseWeaponTiming = Yes duration
  PreAttackType		 = PER_SHOT 
  FiringDuration		= 0 
  DamageNugget				 &#59; A basic Nugget that just does damage
	Damage		= 160	&#59; A whole lot of damage.
	Radius		= 0.0
	DelayTime	 = 0
	DamageType	= HERO
	DeathType	 = CRUSHED
  End
End

As you can see, They are the same system but thanks to the "XML" of C&C 3, Coding it is way harder.
Also, In the Armor types you posted Codecat. Why do i see a few damage types available that came from BFME 1 and 2?

Edited by Chris, 24 August 2007 - 15:33.

[Slye_Fox]

.ini files are stilled used in C&C3

They can be found in misc.big

notable files;
playertemplate.ini
science.ini
eva.ini

[CodeCat]

Figures EA wouldn't finish the job...

Mastermind wrote a bit of a tutorial to use the INI files, here: http://www.cnc3.net/item-142

[nova]

is it safe to asume ea planed an expansion all along because what usses plasma the only thing i know is a cyborg commando *scratches head* dang i wish i hade patch 1.07

[Sgt. Rho]

The Avatar actually uses 4 special abilitys for the comandeer ability. One To apreach the unit, one to paralize it, one to kill it and another one to take the weapon.

[TankMaster]

Ok, bear with me on this, thanks to JonWil & JeepRubi, I have made the walls work, and work right!

First off, there are only two files you need to change, SkirmishAI/Targets/AITargetHeuristics.xml & GlobalData/LogicCommandSet.xml in your Mod SDK folder (where the xml's are located).

Ok the AITargetHeuristics.xml file first:

All you need to do to it is remove the WALL_HUB and WALL_SEGMENT from the ForbiddenKindOf field. That's it.

Now for LogicCommandSet.xml:

In all the Conyards & and Cranes add the following:

<Cmd>Command_ConstructGDIWallHub</Cmd>

For example:

<LogicCommandSet
id="GDIConstructionYardCommandSet">
<Cmd>Command_ConstructGDIWallHub</Cmd>
</LogicCommandSet>

Now of course, that is for GDI, here is what you do for NOD and Scrin:

<Cmd>Command_NOD_BuildWallHub</Cmd> (NOD)

<Cmd>Command_ConstructAlienWallHub</Cmd> (Scrin)


Now onto what makes it span...

Just find "NODWallHubCommandSet" Or what ever side it is.

and add <Cmd>Command_NOD_BeginWallSpan</Cmd>

as the first item or anywhere, I don't think it matters.

And to make it work for GDI & Scrin just change the _NOD_ to _GDI_ and _Alien_ .


That should be it.

I am not good at explaining things, so let me know if you had issues following this. And again, thanks to jonwil who figured this out.

Edited by TankMaster, 25 August 2007 - 00:42.

[CodeCat]

Ok, more news from the research lab, and more good news!

Turrets are no longer limited to Turret and AltTurret. Instead, each turret is given an ID, which is a number. This means that there is no limit on the amount of turrets anymore! The schemas confirm this, too.

Secondly, weapon slots. I think this would be best explained using the schemas:

	<xs&#58;simpleType name=&#34;WeaponSlotType&#34;>
	  <xs&#58;restriction base=&#34;xs&#58;string&#34;>

		<xs&#58;enumeration value=&#34;PRIMARY_WEAPON&#34; />
		<xs&#58;enumeration value=&#34;SECONDARY_WEAPON&#34; />
		<xs&#58;enumeration value=&#34;TERTIARY_WEAPON&#34; />
		<xs&#58;enumeration value=&#34;QUATERNARY_WEAPON&#34; />
		<xs&#58;enumeration value=&#34;QUINARY_WEAPON&#34; />
		<xs&#58;enumeration value=&#34;NO_WEAPON&#34; />

	  </xs&#58;restriction>
	</xs&#58;simpleType>

This means that there are now FIVE weapon slots available for use!

[Jazzie Spurs]

Finnaly!!
Machine gun, cannon, missiles, ion cannon and plasma railgun can be attached in my tank
woo typos xD

Edited by HeartBreak1, 25 August 2007 - 13:51.

[CodeCat]

I've done more weapons research. Apparently, there exists the concept of independent 'hardpoints'. The best way to think of a hardpoint is a 'group of weapons that work together'. A turret counts as a hardpoint, but this is not necessary. As far as I've been able to see, the ID I mentioned earlier is not the turret ID, but the weapon hardpoint ID. Each hardpoint can act independently from the others and has its own set of rules. And I have reason to believe that the 5 weapon slots mentioned above are per hardpoint only. So for example, with 100 hardpoints on an object you can have 500 weapons! I'm not kidding! None of this is proven, but so far that's what it looks like.

Here's what the weaponset could look like:

			<WeaponSetUpdate
				id=&#34;ModuleTag_WeaponSetUpdate&#34;>
				
				<WeaponSlotHardpoint
					ID=&#34;1&#34;
					AllowInterleavedFiring=&#34;false&#34; or &#34;true&#34;
					InterleavedStyle=&#34;INTERLEAVE_RANDOM&#34; or &#34;INTERLEAVE_FIRST_AVAILABLE&#34;
					WeaponChoiceCriteria=&#34;PREFER_MOST_DAMAGE&#34; or &#34;PREFER_LONGEST_RANGE&#34; or &#34;PREFER_GRAB_OVER_DAMAGE&#34; or &#34;PREFER_LEAST_MOVEMENT&#34; or &#34;SELECT_AT_RANDOM&#34; or &#34;USE_WEAPONSET_DEFAULT_CRITERIA&#34; >
					<Weapon
						Ordering=&#34;PRIMARY_WEAPON&#34;
						Template=&#34;GDIAABattery&#34; &#91;this is the actual weapon name&#93;
						Upgrade=&#34;SomeUpgrade&#34;
						ObjectStatus=&#34;SomeStatusBits&#34;
						IsPlayerUpgradePermanent=&#34;false&#34; or &#34;true&#34; &#91;probably this controls whether this weapon can be disabled again if the upgrade is lost&#34;&#93; />
					<Weapon
						Ordering=&#34;SECONDARY_WEAPON&#34;
						Template=&#34;GDIHarvesterMachineGun&#34; &#91;this is the actual weapon name&#93;
						Upgrade=&#34;SomeOtherUpgrade&#34;
						ObjectStatus=&#34;SomeStatusBits&#34; />
					
					&#91;3 more weapons optionally...&#93;

				</WeaponSlotHardpoint>
				
				<WeaponSlotTurret
					ID=&#34;2&#34;
					&#91;otherwise the same as above&#93; >
					&#91;weapons, possibly 5 more on the same unit, but different hardpoint...&#93;
					<TurretSettings
						TurretTurnRate=&#34;0.0&#34;
						TurretPitchRate=&#34;0.0&#34;
						AllowsPitch=&#34;false&#34;
						MinimumPitch=&#34;0d&#34;
						PitchHeight=&#34;50%&#34;
						ControlledWeaponSlots=&#34;PRIMARY_WEAPON&#34;
						MinIdleScanTime=&#34;0.0s&#34;
						MaxIdleScanTime=&#34;0.0s&#34;
						MinIdleScanAngle=&#34;0.0&#34;
						MaxIdleScanAngle=&#34;0.0&#34;
						MaxDeflectionClockwise=&#34;180d&#34; &#91;This is another setting we&#39;ve been waiting for. This setting...&#93;
						MaxDeflectionAntiClockwise=&#34;180d&#34; &#91;...and this one control the maximum turn angle of the turret!&#93;
						NaturalTurretAngle=&#34;0d&#34;
						RecenterWhenOutOfTurnRange=&#34;true&#34; &#91;If target is further than the turret can turn, recenter the turret?&#93; />
						<TurretAITargetChooserData>
							&#91;lots more stuff...&#93;
						</TurretAITargetChooserData>
					</TurretSettings>
					
				</WeaponSlotTurret>
				
			</WeaponSetUpdate>

[CodeCat]

Locomotors work slightly different from Generals, but it's easy enough to get your head around. The biggest change is that locomotors no longer store the exact speed of the unit or anything related to it. Instead, the object specifies its own speed, and the locomotor adapts to it. For example, the acceleration and braking is not specified in speed units, but in time. I.e. the time for the object to accelerate to full speed. Turn rate is specified similarly, by entering the time it takes for it to rotate 360 degrees. A new addition is turn circle radius, both slow and fast settings. These set the radius that the unit has to drive around to turn. The bigger it is, the less tight the corners are that the unit is capable of turning, and therefore a setting of 0.0 will make it able to turn right on the spot, similar to Generals' handling.

One drastic change is the way veterancy and experience are handled. Units no longer set their own veterancy levels. Instead, there is one file, CnC3Xml\GlobalData/ExperienceLevels.xml, that contains a long list of all units and their veterancy-controlled settings. This sets the experience required, experience given when it's killed at that level, some decal settings, etc.

Veteran bonuses, along with any other bonuses, are controlled through CnC3Xml\GlobalData\AttributeModifier.xml. These list all possible bonuses, and it's possible to add new ones. Each AttributeModifier entry has a Category attribute associated with it. This tells the game how the bonus is applied and when, and how/whether it can be removed again. See Schemas\xsd\Include\AssetTypeAttributeModifier.xsd under the 'AttributeModifierCategoryType' heading for a list of possible values.
Another use for AttributeModifiers is to set object statuses. The ObjectStatusToSet= controls this. I'm not exactly sure if there is a way to clear statuses rather than set them, though. A list of all ObjectStatuses can be found in Schemas\xsd\Includes\ObjectStatus.xsd (along with a list of DeathTypes further down, too).
Of course, AttributeModifiers can set modifiers for attributes. These consist of a list of <Modifier> elements, having two XML attributes: a type and a percentage value. The type sets what to modify, and the percentage sets by how much to modify it. For a full list of attribute types, see CnC3Xml\GlobalData\AttributeModifier.xml.

Damn these schemas are handy!

[Ascendancy]

The thing about the ExperienceLevels I found out the hard way, but now my base defences gain veterancy. The only thing I can't properly code is the heroic tracers for the GDI AA Battery and the GDI Watch Tower. It gives me the dumb XML error at line 0, position 0.

[CodeCat]

Continuing on the AttributeModifier system, here's a short explanation of how upgrades work now.

The WeaponSetUpgrade module has been done away with altogether. What we have now is a system based around StatusBits. StatusBits are basically all kinds of on/off switches that are triggered by many things. And one of those triggers can be an upgrade, just like was already possible in Generals. The Mammoth Tank's railgun upgrade uses the C&C3 equivalent of a WeaponSetUpgrade. Let's take a look at CnC3Xml\GDI\Units\GDIZoneTrooper.xml, specifically the two weapons on its main turret (remember that turrets/hardpoints each have their own weaponsets):

					<Weapon
						Ordering=&#34;PRIMARY_WEAPON&#34;
						Template=&#34;GDIMammothTankGun&#34; />
					<Weapon
						Ordering=&#34;PRIMARY_WEAPON&#34;
						Template=&#34;MammothTankRailCannon&#34;
						ObjectStatus=&#34;WEAPON_UPGRADED_01&#34; />

The change here is obvious. Rather than setting conditions like in Generals, you can specify that a certain ObjectStatus should trigger a change of weaponset. The consequence of this is that a weaponset switch could be triggered by any status at all. And there's quite a bunch of them! Take a peek in Schemas\xsd\Includes\ObjectStatus.xsd if you want the whole list. Another interesting point is that the status name has a number attached to it. The schemas show that there are three possible weapon upgrade statuses available: WEAPON_UPGRADED_01, WEAPON_UPGRADED_02 and WEAPON_UPGRADED_03. So it's now possible to have 3 different weapon upgrades, rather than the single one that Generals allowed. It's a bit of an improvement.

Further down is the code that triggers the status itself:

			<StatusBitsUpgrade
				id=&#34;ModuleTag_UpgradeWeapon&#34;
				StatusToSet=&#34;WEAPON_UPGRADED_01&#34;>
				<TriggeredBy>Upgrade_GDIArmoryRailgunTech</TriggeredBy>
			</StatusBitsUpgrade>

For those that have modded Gen this is pretty self-explanatory. It sets a status when triggered by the specified upgrade.


Next we'll look at the Scanner Packs upgrade for the GDI zone troopers. Infantry upgrades are a bit different here, because some of them can apply to the squad while others apply to each unit individually. The scanner packs only apply model changes to the individuals, the actual effect goes to the squad (which is a separate object like how the angry mob works in Generals). So here's CnC3Xml\GDI\Units\GDIZoneTrooperSquad.xml:

			<StealthDetectorUpdate
				id=&#34;ModuleTag_ScannerPack_01&#34;
				DetectionRange=&#34;400&#34;
				InitiallyDisabled=&#34;true&#34;>
				<TriggeredBy>Upgrade_ZoneTrooperScannerPack</TriggeredBy>
			</StealthDetectorUpdate>

Again, this is pretty standard stuff when compared to Generals and the code above. But there's more. Just below that there's this:

			<AttributeModifierUpgrade
				id=&#34;Upgrade_ScannerPack_02&#34;
				AttributeModifier=&#34;ZoneTrooper_ScannerPack&#34;>
				<TriggeredBy>Upgrade_ZoneTrooperScannerPack</TriggeredBy>
			</AttributeModifierUpgrade>

Think of an attribute modifier as what used to be called a 'bonus' in Generals. They are sets of modifications that can be applied to things. I talked about them above, but here we actually see them in action. The main difference with Generals, as I've shown, is that attribute modifiers can be created new. The existing ones are in CnC3Xml\GlobalData\AttributeModifier.xml. Here's the one for the scanner packs:

	<AttributeModifier
		id=&#34;ZoneTrooper_ScannerPack&#34;
		Category=&#34;INNATE_VISION&#34;>
		<Modifier Type=&#34;RANGE&#34; Value=&#34;110&#34;/>
		<Modifier Type=&#34;VISION&#34; Value=&#34;120&#34;/>
		<Modifier Type=&#34;SHROUD_CLEARING&#34; Value=&#34;120&#34;/>
	</AttributeModifier>

I've explained this above a few posts, so read back a bit if you want to know what this means.

One use for this system of modifiers is stacked bonuses. You can pile the effect of several modifiers on top of each other. For example, Starcraft had a system of global unit upgrades for armour and damage, each of which had three levels. Using one modifier for each level, this same thing is now possible in C&C3. The only constraint is more of an interface one - you can't have the button for the next level replace the previous one, like in Starcraft, as far as I could see. So that would mean we'd have to work with commandset switches, which would be a pain to manage for large amounts of such upgrades and with many levels. To give you an idea: to achieve the effect of Starcrafts Armoury with its four three-level upgrades, you'd need 3x3x3x3 = 81 commandsets for that one building...

[tank50us]

Now here's a question, is it possible to to have multible weapons per squad (say, a Rifle, Grenade Launcher, SAW, and Rocket Launcher), and even better, how exactly does the squad systom work? and does the squad it self get a weapon, or does the object. Also, does anyone know if its posible to have a unit exposed like, a bunch of dudes sticking out of fox-holes that they dug and not all (insert number here) sticking out of the same hole. Keep in mind, I'm not on the computer that I'll be using to mod C&C3, but I can't wait for everything to be ready.

I also hope someone figures out how to make aircraft "Taxi and take off" like what was done with Generals, this way any and all WW2/Veitnam/modern-war mods can have full airforces, rather then just VTOLs. And I don't know about the rest of you, but true paratroopers JUMP from fixed-wing planes, and parachute down, what was done for GDI is actually "Air-Assault" (delivery by a VTOL/Rotory-Winged transport), if someone can figure out a 'parachute' code, taht'll help everyone.

I've said my Piece, Tank out

[CodeCat]

The way the Engineer capture/repair logic works is a bit strange at first. Rather than giving the Engineer the ability to enter a building, the building gives Engineers the ability to enter itself. This is achieved through a xi:include tag, which loads another file and sticks it contents where the tag is. The xi:include tag itself is placed within the Behavior tags, as if it were a behavior module itself. Essentially it is, indirectly, because it acts as if the contents of the file were placed where the tag is; so if the included file contains a module, all is well.

In the case of the Engineer capturing, the file included is DATA:Includes/GenericEngineerContain.xml. Every building that can be captured by Engineers xi:includes that file. Here's the contents of that file:

	<EngineerContain xmlns=&#34;uri&#58;ea.com&#58;eala&#58;asset&#34;
		id=&#34;ModuleTag_EngineerContain&#34;
		NameOfVoiceToUseForFriendlyEnter=&#34;VoiceEngineerRepair&#34;
		NameOfVoiceToUseForHostileEnter=&#34;VoiceCaptureBuilding&#34; 
		EvaEventForRepair=&#34;BuildingRepaired&#34;
		EvaEventForCapture=&#34;EnemyBuildingCaptured&#34;
		FXForRepair=&#34;FX_Building_Repaired&#34; 
		FXForCapture=&#34;FX_Building_Captured&#34;
		FXForCaptureAndReplace=&#34;FX_Building_Captured&#34;
		ImmediatelyEnabled=&#34;true&#34;>
		<CanEnterFilter Rule=&#34;NONE&#34;>
			<IncludeThing>GDIEngineer</IncludeThing>
			<IncludeThing>NODSaboteur</IncludeThing>
			<IncludeThing>AlienAssimilator</IncludeThing>
		</CanEnterFilter>
	</EngineerContain>

While most of that is for events, FX, audio etc. there are a few things to pay attention to. First of all, the CanEnterFilter tag. That controls what can actually capture this building. Rule="NONE" states that by default nothing can capture this building except the objects listed in IncludeThing tags. Secondly, this is a Contain-type module. That means that it lets other things enter this object and be contained by it. The special thing about EngineerContain in particular is that, not only will the object that enters it (the Engineer) disappear completely, but if the building does not belong to the same player as the entering object, the building will change ownership to the player that owned the object that entered it. And if the building IS owned by the player that owns entering object, the building will instead be repaired to full health.

Salvaging husks acts in a very similar way. However, there is one key difference: the EngineerContain on husks has an extra attribute set, like here on the GDI Juggernaut:

ReplaceWith="GDIJuggernaughtHuskReplace"

This is what sets the husk back on its feet when it's captured. It is the name of an OCL (Object Creation List, as found in CnC3Xml\GlobalData\ObjectCreationLists.xml) that is spawned to replace the captured husk. But it's not limited to husks of course; you could make anything get replaced by something else when it gets captured. For example, what about tech buildings that can be captured only once? Simply replace the building with an identical building when it is captured, except that it has no EngineerContain, so it will no longer be capturable.

[Rich19]

CodeCat, on 25 Aug 2007, 15:39, said:

I've done more weapons research. Apparently, there exists the concept of independent 'hardpoints'. The best way to think of a hardpoint is a 'group of weapons that work together'. A turret counts as a hardpoint, but this is not necessary. As far as I've been able to see, the ID I mentioned earlier is not the turret ID, but the weapon hardpoint ID. Each hardpoint can act independently from the others and has its own set of rules. And I have reason to believe that the 5 weapon slots mentioned above are per hardpoint only. So for example, with 100 hardpoints on an object you can have 500 weapons! I'm not kidding! None of this is proven, but so far that's what it looks like.

Here's what the weaponset could look like:

			<WeaponSetUpdate
				id=&#34;ModuleTag_WeaponSetUpdate&#34;>
				
				<WeaponSlotHardpoint
					ID=&#34;1&#34;
					AllowInterleavedFiring=&#34;false&#34; or &#34;true&#34;
					InterleavedStyle=&#34;INTERLEAVE_RANDOM&#34; or &#34;INTERLEAVE_FIRST_AVAILABLE&#34;
					WeaponChoiceCriteria=&#34;PREFER_MOST_DAMAGE&#34; or &#34;PREFER_LONGEST_RANGE&#34; or &#34;PREFER_GRAB_OVER_DAMAGE&#34; or &#34;PREFER_LEAST_MOVEMENT&#34; or &#34;SELECT_AT_RANDOM&#34; or &#34;USE_WEAPONSET_DEFAULT_CRITERIA&#34; >
					<Weapon
						Ordering=&#34;PRIMARY_WEAPON&#34;
						Template=&#34;GDIAABattery&#34; &#91;this is the actual weapon name&#93;
						Upgrade=&#34;SomeUpgrade&#34;
						ObjectStatus=&#34;SomeStatusBits&#34;
						IsPlayerUpgradePermanent=&#34;false&#34; or &#34;true&#34; &#91;probably this controls whether this weapon can be disabled again if the upgrade is lost&#34;&#93; />
					<Weapon
						Ordering=&#34;SECONDARY_WEAPON&#34;
						Template=&#34;GDIHarvesterMachineGun&#34; &#91;this is the actual weapon name&#93;
						Upgrade=&#34;SomeOtherUpgrade&#34;
						ObjectStatus=&#34;SomeStatusBits&#34; />
					
					&#91;3 more weapons optionally...&#93;

				</WeaponSlotHardpoint>
				
				<WeaponSlotTurret
					ID=&#34;2&#34;
					&#91;otherwise the same as above&#93; >
					&#91;weapons, possibly 5 more on the same unit, but different hardpoint...&#93;
					<TurretSettings
						TurretTurnRate=&#34;0.0&#34;
						TurretPitchRate=&#34;0.0&#34;
						AllowsPitch=&#34;false&#34;
						MinimumPitch=&#34;0d&#34;
						PitchHeight=&#34;50%&#34;
						ControlledWeaponSlots=&#34;PRIMARY_WEAPON&#34;
						MinIdleScanTime=&#34;0.0s&#34;
						MaxIdleScanTime=&#34;0.0s&#34;
						MinIdleScanAngle=&#34;0.0&#34;
						MaxIdleScanAngle=&#34;0.0&#34;
						MaxDeflectionClockwise=&#34;180d&#34; &#91;This is another setting we&#39;ve been waiting for. This setting...&#93;
						MaxDeflectionAntiClockwise=&#34;180d&#34; &#91;...and this one control the maximum turn angle of the turret!&#93;
						NaturalTurretAngle=&#34;0d&#34;
						RecenterWhenOutOfTurnRange=&#34;true&#34; &#91;If target is further than the turret can turn, recenter the turret?&#93; />
						<TurretAITargetChooserData>
							&#91;lots more stuff...&#93;
						</TurretAITargetChooserData>
					</TurretSettings>
					
				</WeaponSlotTurret>
				
			</WeaponSetUpdate>

Did you get that code for a schema file? It solved a problem I've been struggling with for a while. Thanks!

[Daz]

Runways works as in Generals (same bone names, but numbers should be 0 and 1 instead of 1 and 2). The below is taken straight from Generals factionbuilding.ini, the bones should be listed in the proper C&C3 manner but this is easier to read.

	ExtraPublicBone = Runway1Parking1 
	ExtraPublicBone = Runway1Parking2 
	ExtraPublicBone = Runway2Parking1 
	ExtraPublicBone = Runway2Parking2 
	ExtraPublicBone = Runway1Park1Han
	ExtraPublicBone = Runway1Park2Han
	ExtraPublicBone = Runway2Park1Han
	ExtraPublicBone = Runway2Park2Han 
	ExtraPublicBone = Runway1Prep1 
	ExtraPublicBone = Runway1Prep2 
	ExtraPublicBone = Runway2Prep1 
	ExtraPublicBone = Runway2Prep2 
	ExtraPublicBone = RunwayStart1 
	ExtraPublicBone = RunwayStart2 
	ExtraPublicBone = RunwayEnd1 
	ExtraPublicBone = RunwayEnd2
	ExtraPublicBone = HeliPark01

You set the unit to have NeedsRunway=True (set to false on every air unit in the game) and give it the BasicJetTaxi locomotor instead of BasicHeliTaxi.
It's a good idea to copy the pitching and rolling part from another aircraft locomotor and set it to stop the plane rolling or pitching whilst taxiing like the one below (which is BasicJetTaxiLocomotor with the extra bit added).

	<LocomotorTemplate
		id=&#34;TornadoTaxiLocomotor&#34;
		Name=&#34;TornadoTaxiLocomotor&#34;
		Surfaces=&#34;GROUND&#34; 
		TurnTimeSeconds=&#34;1.0s&#34; 
		AccelerationSeconds=&#34;0.1s&#34;
		BrakingSeconds=&#34;0.1s&#34;
		MinTurnSpeed=&#34;0%&#34; 
		BehaviorZ=&#34;NO_MOTIVE_FORCE&#34;	
		Appearance=&#34;TREADS&#34; 

		PitchByZVelCoef=&#34;0.0&#34;
		PitchStiffness=&#34;1.0&#34;
		RollStiffness=&#34;1.0&#34;
		PitchDamping=&#34;1.0&#34;
		RollDamping=&#34;1.0&#34;
		ForwardVelocityPitchFactor=&#34;0.0&#34;
		LateralVelocityRollFactor=&#34;0.0&#34; 

		/>

A good flight locomotor for "proper" planes is the Vertigo Bomber one, as this doesn't pitch forward when moving but does roll when turning. Or the one below.

	<LocomotorTemplate
		id=&#34;TornadoLocomotor&#34;
		Name=&#34;TornadoLocomotor&#34;
		Surfaces=&#34;AIR&#34; 
		MinSpeed=&#34;160%&#34;
		TurnTimeSeconds=&#34;2.0s&#34; 
		TurnTimeDamagedSeconds=&#34;2.0s&#34; 
		FastTurnRadius=&#34;50.0&#34; 
		SlowTurnRadius=&#34;50.0&#34; 
		AccelerationSeconds=&#34;1.0s&#34;
		Lift=&#34;120%&#34;
		LiftDamaged=&#34;80%&#34;
		BrakingSeconds=&#34;0.5s&#34;
		MinTurnSpeed=&#34;150%&#34;
		PreferredHeight=&#34;150&#34;
		PreferredHeightDamping=&#34;2.0&#34;
		AllowMotiveForceWhileAirborne=&#34;true&#34;
		BehaviorZ=&#34;SURFACE_RELATIVE_HEIGHT&#34;	
		CirclingRadius=&#34;60&#34;
		CirclingSpeed=&#34;50%&#34;
		Appearance=&#34;WINGS&#34; 
		TurnPivotOffset=&#34;-0.33&#34;

		PitchByZVelCoef=&#34;1.0&#34;
		PitchStiffness=&#34;1.0&#34;
		RollStiffness=&#34;0.1&#34;
		PitchDamping=&#34;1.0&#34;
		RollDamping=&#34;0.5&#34;
		ForwardVelocityPitchFactor=&#34;1.0&#34;
		LateralVelocityRollFactor=&#34;-0.5&#34; 
		Apply2DFrictionWhenAirborne=&#34;true&#34;
		AirborneTargetingHeight=&#34;30&#34;
		LocomotorWorksWhenDead=&#34;true&#34;
		ClampOrientationToPathTangent=&#34;true&#34;
		AttackPathTrailDistance=&#34;300&#34;

		TakeOffAndLandingSpeed=&#34;2.0&#34;
		TakeOffAndLandingSlowDownDelta=&#34;25.0&#34;
		TakeOffAndLandingSlowDownTime=&#34;1.5s&#34;
	/>

Unfortunately landing is buggy, the aircraft stop in mid air and queue up - then move to above the runway start bone and drop to the ground in the blink of an eye (I can't remember how this worked in Generals, but I certainly don't think it was like this).

I think there may be some new bones for landing, or the logic might just be broken.

Also the HeliPark bone used for building and repairing helicopters in Generals seems to act as the default build location for units, so units appear at this bone then jump to their hanger.

For some reason the Orca requires animations for pitching when moving and rolling while turning, while the Firehawk has it coded into it's locomotor (moving those parts of the Firehawk locomotor to the Orca has no effect).

Edited by Daz, 10 September 2007 - 10:36.

[tank50us]

Anyone know if that same code can be applied to something like say, a carrier plane (get it to "Approach" a carrier)?

[Daz]

If the carrier was a building.

I would imagine you can't have runways on units.