Recoil is the "kick" of a weapon when it is fired, causing the user's aim to drift off the target, thus limiting accuracy and forcing the user to compensate. This differs from spread, which is a random error that changes the intended trajectory of each fired projectile, while the weapon remains aimed at the same spot. By contrast, recoil changes the orientation of the weapon itself, so even a weapon with no spread will no longer be able to hit the same spot.

Recoil mechanics

Recoil strength

Each fired projectile creates an impulse that will throw the user's aim off-target. The strength of this impulse is determined by the recoil strength parameter. Each projectile will add a 2D (pitch and yaw) impulse to the weapon, rotating it away from the original orientation. The impulses from subsequent projectiles are added to the total recoil angular velocity, so sustained fire will continuously increase the recoil effect.

Recoil pattern

The recoil pattern determines the directions in which the recoil impulses described above take effect. Each time a projectile is fired, an impulse vector is calculated based on the recoil pattern. Most impulses will be directed toward a bias direction (typically in the direction upward from the barrel), and to simulate the pseudo-randomness of the recoil effect, some projectiles will create an impulse in a random direction within the set pattern. The per-shot probability of this random impulse can be adjusted using the random probability parameter.

Arc pattern

The arc pattern is the most conventional type of recoil pattern, which assumes a weapon that primarily "kicks upward". The green arrow shows the bias, which is the direction where normal recoil impulses will push the user's aim. The red arrows show possible directions for random recoil impulses, where the angles of all such impulses w.r.t the vertical direction are constrained to this arc. The pattern arc size parameter can widen the arc, allowing for greater horizontal deviations with each shot.

Circle pattern

The circle pattern behaves similarly to the arc pattern, except that it allows random impulses in the full 360° range (which means it does not need the arc size parameter). This is primarily useful for more wild recoil behavior, e.g a handheld machine gun during sustained fire.

Recoil resistance

In order to prevent the recoil impulses from making the weapon spiral out of control, weapons have recoil resistance, which is a constant force that acts opposite the recoil force while it is nonzero. After each recoil impulse is applied, this force will attempt to bring the recoil movement to a halt, thus it can be balanced with recoil strength to create the appropriate recoil behavior. For example, setting a high recoil strength and low resistance will allow a single shot to widely displace the user's aim, and the recoil effect will take longer to "decay".

The user's current state also affects their resistance. This is achieved using the resistance multipliers, e.g crouching can be expected to increase the user's ability to resist the recoil impulses, while jumping has the opposite effect.

NOTE: the recoil resistance parameter must be nonzero, otherwise the recoil impulse will never decay and will endlessly throw off the user's aim.

Recoil recovery

Recovery is an optional mechanic that allows for automatically correcting the user's aim. After the resistance has reduced the recoil angular velocity to zero, the recovery will take over and move the user's aim back toward the center of their recoil pattern. The recoil recovery parameter sets the speed of this effect, so an appropriate value must be found to make the transition look natural. The recovery also depends on the recoil pattern size, which sets a limit on how far the user's aim can deviate before it can no longer be returned to the original position. If the recoil impulses move the user's aim beyond the pattern radius, then the pattern itself will "drift" with the recoil, and the recovery will only restore the aim to the new center position of the pattern. However, there is a flag; Aimpoint Static that will disable the aim drifting beyond the recoil pattern's size and instead limit the recoil size to just the recoil pattern size, where the player's aim will stay until fire is stopped (if recovery is enabled).

(NEEDS PICTURES)

Recoil parameters

Weapon recoil can be set for infantry weapons and even vehicles. To set up recoil for a weapon, enable the recoil component within the weapon. WIthout this component, reload cannot be used. Once this component is enabled on a weapon, the parameters can be edited both within Mammoth and the in-game EDIT_WEAPON console command. The recoil component has its own tab within EDIT_WEAPON.

Ammo definition parameters

Weapon definition parameters

Oct 28 2019

• Added a replacement for the help screen, based off the old Renegade in-game encyclopedia from it's single player mode.
  • Toggleable via tt.ini
  • Will show everything in MP, in SP will use older unlock logic.

Oct 27 2019

• Overhaul of the muzzle logic, which allows for 26 different muzzle 'sets', each with a varying number of muzzle bones.
  • Added options in the weapons to choose which muzzle sets a weapon uses, ideal for swapping weapons in a vehicle.

Oct 14 2019

• Added orthographic camera toggle to the view menu in Mammoth. Has some edge cases where object selection might not work as expected, otherwise fully functional.
• Added roll/pitch/yaw and orthographic view size to "Goto Location" (Ctrl+G)
• Fixed editing objects that have non-zero X/Y rotation (previously, double-clicking on an object and pressing OK without any changes would rotate them in a weird way).
  • Enabled X/Y rotation edit fields.

Oct 09 2019

• New radar option: shows objects close to player and all allies regardless of distance.
  • ROM_Map script can set this new option:
    0 = Show everything
    1 = Show only close to player
    2 = Show close to player and allies

Oct 08 2019

• Scaling for proxied objects and infantry

  • Any proxy object in Max that has $ as its first character will make use of the scaling information in the Max object (e.g setting the proxied object to have 200% XYZ scaling will make the object 2x as big when the level is loaded)

  • Soldier presets have a new ModelScale setting. The camera height and origin offset will automatically scale with it.
  • IMPORTANT:
    • Only uniform scales are supported for now (same scale on all axes). Non-uniform scales will seem like they're working, but they will introduce subtle bugs!
    • Non-mesh objects (e.g. zones) are untested and unlikely to work.
    • Animated or otherwise moving/dynamic meshes (e.g. elevators, shatterable windows) are untested.

Oct 07 2019

• Mouse steering improvements:
  • Added a new flag to Controls that allows users to select whether they want mouse steering on VTOLs. Only affects vehicles that had mouse steering enabled in Mammoth (i.e things like APB Subs won't be affected)
  • VTOLs with mouse steering can disable steering while holding the "Cursor Targeting" key (default is V), this allows them to look around without moving. Steering and strafing reverts to the keyboard-only versions while this button is held.

Sep 30 2019

• Mammoth's "Export String Table" and "Import Tab Delimited" functions (English-only strings import/export) can now correctly handle newlines and other special characters.

• Added functionality to add new key actions to the game after release.

  • default_input.cfg gains a new section called "New Actions". The entries are of the format ActionName=BuildNumber, where ActionName is something like Jump or VehicleToggleGunner and BuildNumber is the scripts build number in which the new action was introduced to the game (e.g. 10753).

  • The engine saves its current build number into the config.dat file, separately for each every input config. It can then compare the saved build number to the entries in "New Actions" to determine whether those were added since the last time the player has played the game.

  • The new actions will automatically be bound to their specified default keys. The player will then receive an ingame-notification of the new action. If none of the default keys could be bound due to conflicts with existing keybindings, the notification will say so and direct the player towards the controls menu.

  • New strings.tdb entries:
    IDS_VERSIONED_KEYBINDS_TITLE: Title of the message window
    IDS_VERSIONED_KEYBINDS_SUCCESS: Message when default keys were successfully bound
    IDS_VERSIONED_KEYBINDS_CONFLICT: Message on failure due to conflicts
    IDS_FUNCTION_VEHICLE_TOGGLE_GUNNER: Translated name of the new action that was already introduced ages ago. Used for toggle gunner, CTOL landing gear toggle, jetpack toggle.

Sep 29 2019

• 64 bit builds of the engine (and editor, tools) are now officially supported, can be downloaded manually via Jenkins

Sep 23 2019

• Made light solve pass through translucent meshes (alpha test/blend). This usually improves lighting, makes it possible to decrease excessive fake lighting inside windowed buildings.

• New console command DEBUG_SHOW_DISTANCE: Shows the distance to the surface under the crosshair in the top right.

Sep 21 2019

• Spectators no longer take damage from scripts and zones.
• Spectators no longer get blinded by the gap generator.

• Added four new console commands to show bounding boxes:

  • CULL_SHOW_BUILDING_BOXES for buildings

  • CULL_SHOW_SOUND_BOXES for sounds

  • CULL_SHOW_PROJECTILE_BOXES for projectiles

  • CULL_SHOW_PHYS_BOXES <type> for physical objects. <type> is a bitmask and can be specified with either decimal or hexadecimal numbers (with 0x prefix). This means you can add the values in the table below to display multiple types at once.

    Value	Color	Type
    1	Magenta-ish ♦	Emitters
    2	Any Color ♦	Static Objects (Elevators/Doors = Red, Damageable = Green)
    4	Cyan-ish ♦	Soldiers / Vehicles
    8	Yellow-ish ♦	Lights
    16	Any Color ♦	Projectiles
    32	White ♦	Others (Decorations, Pseudo-Vehicle Structures)

     

• (Started work on 64 bit port of the engine)

Sep 19 2019

• IsDamageZone weapons can hurt damageable static objects again (walls/gates).

• Sniper zoom now works in 10 consistent steps (one step per mouse wheel tick). Previously it was framerate-dependent in a weird way.

Sep 18 2019

• Modified barrel bone code to also take BarrelBxx bones (currently setto a maximum of 2 each)

Sep 17 2019

• Jetpack physics fixes:

  • Added actual momentum to the calculations, should make jetpack flight behavior much more consistent (will need to fine tune the parameters though)

  • Fixed the bouncy collisions, flight mode will simply make the model press and slide against surfaces (potential risk of getting stuck, but it's still better than the bouncy behavior)

• Underwater physics:

  • Moved functionality of RA_Underwater_Target_Hider to the engine (script zone now simply sets underwater state).

  • Added opacity parameter to global water FX settings

  • Add a new Submerge Level setting to the "level settings" dialog and use it to determine when the submarine should submerge/surface. The current Water Level setting will be used to determine the surface of the water for the underwater tint, hurt unit script and underwater target hider.

  • Add Underwater Damage Warhead, Underwater Damage Amount and Underwater Surface Type to Global Settings/General in Mammoth. When an infantry or vehicle unit is underwater, every frame tick it will apply underwater damage using the warhead and amount values.

  • A soldier or vehicle is now considered underwater whenever it is below Water Level (level settings), but above a surface that has the type Underwater Surface Type (Global Settings/General, determined via raycast straight down).

  • Several bug fixes (ongoing...)

• Fixed W3DViewer not respecting camera alignment flags on meshes.

Sep 16 2019

• Add second warhead to JFW_EMP_New

Sep 13 2019

• Integrated underwater skyblocker and fog into level settings, will apply globally to all vehicles that enter the water death zone (except ships and submarines)

Sep 12 2019

• Made ammo with IsDamageZone ticked no longer "collide" with terrain or teammates.

  • This should allow using explosions or hitter effects for additional audio-visual feedback.

  • Note that this means they no longer damage non-targetable things like walls.

• Changed name of console command TOGGLE_PROJ_BOUNDS to PROJ_BOUNDS_ENABLE.

• Added console command PROJ_SLOW_MODE <velocity>. This will slow down time by a different amount for each projectile in order to make them hit a specific velocity in m/s.

Sep 11 2019

• Modified JFW_Fog_Controller, the script now only handles the APB Gap Gen effect. Swimming infantry and submarine fog and skyblocker effects have been moved to the engine.

Sep 09 2019

• Moved the logic from JFW_Swim_Script into the human physics engine.

  • Can copy the script parameters into the physics definition to get the same behavior.

Sep 08 2019

• Added two flags to refinery building definition:

  • PlayUnloadAnimationAfterDock: If ticked, instead of playing the refinery's docking animation as the harvester docks, it instead only plays it after it's docked.

  • RefineryUnloadMeshName: Name of the mesh that the refinery dump code looks for so that an animation will play when a harvester docks (was hardcoded to "REF_TIB_DUMP").

• New submarine physics:

  • Implemented a new physics type for submarines, derived straight from VTOL, so the old settings will result in the same behavior

  • The functionality from JFW_Submarine and related scripts are moved into the engine (not yet finished), so all visual FX will be handled on the client side, and all gameplay changes on the server side

  • Added a new global parameter for levels to set the water level (default is -1000)

• Massively enhanced gatling logic

  • First person gatling weapons are now doable; use same bone names (spin_barrel_0/spin_barrel_1)

  • Gatling logic now has a sound slot for a motor sound (GatlingContinuousMotorSoundID), that can be affected by the rotation speed, and a min and a max pitch (GatlingMinimumContSoundPitch/GatlingMaximumContSoundPitch)

Sep 01 2019

• Added new surface type Laser (needs new Max 2017 plugin)
• Enabled "lock vehicle camera to turret" option by default (for people who have never run the game before).

Aug 31 2019

• Added optional frame interpolation to all grid texture mappers. Enable by adding Interpolate=True to the mapper arguments.

Aug 28 2019

• Added wireframe mode to the renderer. Can be enabled globally in the editor and game (R_WIREFRAME_ENABLE console command).
  • Is internally available as a material property (so could be enabled for individual objects/passes), but is currently not exposed to mod developers (can be added on request or used for debug views).
• Added MSAA setting to the View menu in Mammoth, now defaults to 4x instead of OFF (helps wireframe mode in particular).

Aug 27 2019

• Some code changes to shader management (among other things like D3D resource leak fixes), project devs should regenerate the shader cache once (in Mammoth) to make live shader development easier for the coders.

Aug 26 2019

• Added ADDWEAPON console command. Put player id and preset name and it adds an infinite ammo instance of that weapon to that player's current char class.

Aug 25 2019

• Fixed Max 2017 plugin not exporting static sort level

Aug 22 2019

• Fixed Max 2017 plugin not exporting smooth skinning flag
• VTOL engine flame bones no longer spin (use texture mappers instead)

Aug 20 2019

• Significantly improved level export times:
  • Add some more detailed timing output to Artillery and Mammoth.
  • Artillery's asset collection after Mammoth export is now roughly 50x faster, making artillery overhead overall negligible
  • Reduced Mammoth level load time in batch mode by roughly 50% (disabled shader compiles and constant buffer creation)
• Added option to do a light solve only for the objects currently visible in the Mammoth viewport to help lighting design iteration (available in menu and toolbar and via Ctrl+Alt+L)
• New weapon flags GatlingCannotFireWhileWarmingUp and GatlingSpinningStopsDuringReload

Aug 18 2019

• Added spinning barrel weapon logic. New parameters UseGattlingLogic, GattlingWarmUpTime, GattlingWarmDownMultiplier

Aug 16 2019

• Added toolbar to Mammoth
• Fixed loud sounds playing when loading into the game (by muting the sound ololol)

Aug 14 2019

• Improved performance of debug visualizers (used for pathfind visualization in Mammoth, TOGGLE_PROJ_BOUNDS ingame, etc.)
• Added menu option to Mammoth to visualize the flight ceiling.
• TOGGLE_PROJ_BOUNDS now works in singleplayer games without the tt.ini entry (just like EDIT_VEHICLE, etc.)
  • Added shot direction indicator
• IsQuickCastAbility weapon flag:
  • Fixed erroneous server-side weapon fire on vehicle enter/exit.
  • Now works with vehicles
    • ContinueReloadOnVehicleExit in tt.ini must be false for this to really work (unless you want empty vehicles to just fire away)
    • Attached turret vehicles check whether their parent vehicle is disabled (e.g. underground) before firing
• Added IgnoreCollisionWithParentOfOwner to ammo definitions. Use for attached turret vehicles to prevent misfire.

• Added IsDamageZone to ammo definitions.

  • Instantly damages everything within a box of size ProjectileExtent

  • Will spawn beam effects and explosions for every target hit (not well-tested!)

  • Range is ignored, just set the ProjectileExtent.X value

  • Box orientation affected by weapon spray/recoil

  • Set velocity to something greater than 0 or it will not work

Aug 13 2019

• W3D Exporter: Fixed an issue with zero bone weights

Aug 11 2019

• W3D Exporter: Fix issue where 2 materials with the same data but on different passes were incorrectly being combined into one material in the resulting w3d file
• Added a "MechWalker" script to simplify walkers. fix hitching and animation sliding/reversing issues

Aug 09 2019

• For coders: Migration to Visual Studio 2019 and Windows 10 SDK

Aug 07 2019

• JFW_Kill_Message_Display can now use unicode character strings.
  • It is suggested to move kill icons to the lower Private Use Area instead of replacing existing characters.
• Animations for special damage types:
  • Fixed special death animations not playing at all
  • Added special wounded animations (animation files already exist, just weren't hooked up to code)

Aug 06 2019

• Added menu option to W3DViewer to toggle specular lighting
• Added R_SPECULAR_ENABLE console command to toggle specular lighting

Aug 05 2019

• New weapon preset flag PBReloadUninterruptable, means you can't interrupt the per-bullet reload (kind of using it more like a progress indicator)

Aug 04 2019

• New special damage types CHEM3/4/5 (respectively using emitters e_tib_dump_b/e_tib_dump_r/e_tib_dump)

Aug 03 2019

• Mammoth strings editor now supports Unicode characters everywhere (including search)
• Added a lot of new strings to the database that were previously hardcoded
• JavaScript code now supports translations via string IDs
• Added a mesh user text option "TwoSidedLightsolve=true"
  • Fixes problems where e.g. a two-sided fence model would be either fully light or fully dark on both sides depending on whether the actual front side faces the light, leading to inconsistent appearance
  • This option causes light solve to always pick the lighter result (dynamically lit models already work 100% correctly as if they had duplicated faces)
  • Not recommended for more "3D" meshes with multiple layers like bushes, which want to be darker on the opposite side of the light source
• The game no longer crashes when it can't find a config.dat (saves which input profiles exist and which one is selected)
  • You should no longer need to ship config.dat and input01.cfg in the data/config folder
  • The only thing you need is a default_input.cfg in the always.dat
• Fixed various bugs with the input profile Save/Load/Default buttons

Jul 25-27 2019

• New features for strings editor in Mammoth:
  • Search by numeric ID, code ID and English string
  • Import and export tab delimited string tables

  • Export Category and Import Category (the first one exports all the strings in a category to a tsv file including all the translations, the second one removes the category and all the strings in it and then loads all the strings from the tsv file)

• Language specific mix file support:

  • If folders named french/german/spanish/chinese/japanese/korean exist underneath the main leveledit folder, their contents will be exported to *.dat by the "export always" feature in Mammoth (artillery can also be made to export these by editing artillery.json and adding them in there just like you would with always2.dat)

  •  

    Mammoth will ignore the contents of these folders and not load their contents.

  • You create the folder for any languages you have and put language-specifc files (art and audio) in there. You should only put files in there that override files in the main always files and not files that dont exist in the main always files.

  • When strings.tdb is loaded by the game, it will use the language set in the registry (Language key next to registry settings like ClientChatLog and HighQualityShadows with 0 = english, 1 = french, 2 = german, 3 = spanish, 4 = chinese, 5 = japanese and 6 = korean). If no translated string exists for that language it will use the English string.

  • When the game starts, it will load the correct .dat file for the language set in the registry (should that file exist).

     

Jul 22 2019

• Dynamically lit two-sided faces now calculate the proper inverted normal in the shader if viewed from the "back" side so that lighting appears fully correct

http://tacitus.w3dhub.com/plugins/servlet/confluence/placeholder/macro?definition=e2FuY2hvcjpBUEJ9&locale=en_GB&version=2

Jul 17 2019 - APB 3.4.1.0

• Add a new flag disable_armor (off by default) to dp88_veterancyUnit. This will disable the code to change the shield/skin of the unit and is intended for vehicles that use JFW_Veteran_Armor_Deploy or other scripts to manage their armor.

Jul 15 2019

• Support numeric IDs in mammoth strings editor
  • Removed TDBEdit.exe as it is no longer needed

Jul 13 2019

• DamageableDoorPhys can now have an Explosion instead of a sound effect.
• Added ability to load dp88_Veterancy system settings from a veterancy.ini file

  • Example INI file:

    [Multipliers] RookiePointsValue=1.0 VeteranPointsValue=1.1 ElitePointsValue=1.25 [Points] UseCombinedPool=false BoostPrice=1 [SwitchCharacter] CarryOverPercent=0.6 ;InfantryCarryOverPercent=0.5 ;VehicleCarryOverPercent

     

Jul 11 2019

• Support for VTOL thrust vectoring for engine flames and engine rotation bones

Jul 10 2019

• DamageableDoorPhys now supports a destruction animation and sound

Jul 08 2019

• Added script MS_Destroyed_Remove_Key

Jul 07 2019

• Fix players getting kicked by the anti-cheat when they connect during the score screen intermission between maps.
• Vehicles can now smoothly adjust their weapon barrel yaw towards their target (e.g. close vs far targets for multi-barreled vehicles)
  • Feature is enabled if bones named "BarrelA0, BarrelA1, ..." are found.
  • New settings WeaponYawRate/Min/Max

Jul 06 2019

• Added JFW_Spy_Beacon* scripts for TSR spy logic

Jul 05 2019

• Changed the beacon explosion to do damage according to the building's armor type instead of the MCT's armor.
• The tabbed sidebar now has a separate tab for equipment.

• Add a "moon is earth" checkbox to the "sky settings" dialog (this does the same thing as the existing JFW_Moon_Is_Earth script and will change the moon textures except that its easier than using the script).

• Add a menu item that reloads the per-map sky settings so you don't need to close and re-open your level every time you change the settings.

Jul 04 2019

• Added option to stop the recoil aimpoint from shifting when it reaches the top of the recoil size. This makes it more Battlefield-esque.

Jul 03 2019

• The recoil resistance multiplier while you are in a scope now increases based on zoom level. At minimum zoom, it's just the amount set in the definition. At maximum zoom, the amount of resistance is doubled.

• Combined the sound definition pitch settings with the ones you can set for humans and jetpacks. Both will now affect the pitch and its randomization (the former will change it each time the sound is instanced, the latter will set a fixed random offset for each human instance)

• Tweaked the recoil code and made it more customizable. Has separate resist and recovery settings again. Recovery can be turned off entirely by setting either the pattern size or the recovery strength to zero.

• Recoil resist now only counteracts the recoil impulse, it does not move aim back to the original target (see Recoil)

• Things that squish vehicles now also squish unsquishable soldiers.

Jul 02 2019

• Added CMD_Kill_Message and CMD_Kill_Message_Display scripts. Requires a more complicated killmessage ini file:

  • StringFormat=KillerPlayerString,KillerString,KillString,KilledPlayerString,KilledString controls what the end result of the kill message is
  • PresetXStringIDKilledString, PresetXStringIDKillString and PresetXStringIDKillerString replace PresetXStringID
  • PresetXStringIDKilledString is for the killed player's object, like a tank
  • PresetXStringIDKillString is for a snarky message, eg " put a dozen holes in "

  • PresetXStringIDKillerString is for the killer's object

• Added a "sprint multiplier" parameter to the Human physics definition, so now every definition can set a different sprint speed w.r.t their normal move speed.

  • Sprinting is disabled completely if the multiplier is less than 1.0

     

• Sprinting now supports both looping and one-shot sounds

• Moved the sound pitch factor and randomization parameters to the physics definitions (human and jetpack).

Jun 30 2019

• Added R_WATCH_SHADER console command to recompile all instances if a shader file changes on disk.
• Improved performance of shadow rendering in some circumstances, particularly with stealth units

Jun 29 2019

• Added command history to the console, using the up/down arrow keys.

Jun 28 2019

• Moved recoil parameters from soldier and vehicle definitions to weapons

Jun 27 2019

• New medic beacon logic script: JFW_Medic_Case_Beacon
  • Deploys an AoE healing beacon when the Deploy keyhook is pressed
  • Can be disabled by enemy fire
  • Can be picked back up by the medic
  • Is destroyed if the medic dies

Jun 26 2019

• Implemented lock on time for tracking weapons.

• Implemented jumping sound slot for Soldiers, can be set in the human physics definition.

Jun 25 2019

• Ported vehicle squishing from AR to 5.0
• Ion Storm script now also changes sky color
• Weapons can now have a custom weapon ready time from exiting sprint mode. If not set, it uses the default switching time as before.
• Fix projectiles with extensions so they don't pass through geometry if they spawn inside.
• Fixed bullets spawning behind the turret for certain types of vehicles.

Jun 24 2019

• Created new physics type STOVL Aircraft, which can switch between VTOL and CTOL physics. When using this physics definition, make sure to set the vehicle type to 'CTOL Aircraft'.

  • Switching between flight modes is done using the 'drop flag' command (currently not yet bindable in the menu, can be set in input01.cfg with DropFlag_Primary=KEYNAME)

  • Switching from CTOL to VTOL is only allowed if the aircraft is within a certain threshold of rotation and angular velocity (i.e is not upside down or spinning too fast)

Jun 23 2019

• Added DamageableDoorPhys, will fully open when destroyed, then swap model (animation is not easily possible)
• Fixes to fog object handling for APB (underwater vision blocker)
• AI harvesters can now open locked doors
• Ported CheckCanEnterParentOnEntry vehicle def setting from AR to 5.0
  • Checks whether the parent object of an attached vehicle (e.g. cruiser, battle fortress) is currently being controlled by the same team before allowing a player to enter.
  • This does not prevent a player from entering the attached vehicle first and then an enemy to "hijack" the driver's seat in the parent object.
    • Changed some scripts to make the following sequence fully prevent mixed teams on the same combined vehicle:
      1. On the parent object, set DriverEnterCustom on dp88_CreateAttachedObject to 68470001
      2. Tick CheckCanEnterParentOnEntry on the attached vehicle preset
      3. Add CMD_Eject_On_Custom to the attached vehicle with EjectEnemiesOnly=true and ToggleVehicleTransitions=false
• Ported objective markers from AR to 5.0. See AR_Obj_Marker_* scripts and [Objective Markers] hud.ini section.

Jun 22 2019

• Added RequireCrouch flag for weapons
• Added refinery hack logic to dp88_buildingScripts_functionMoneyHack, distributes half of the funds to enemies
• Add support for a visibility blocker object to the underground script.
  • Create a Simple object preset with DefaultPlayerVisible set to false and an appropriate model and assign it to the "blocker" param of the SH_UndergroundVehicle script.
  • When the script is created, the blocker object is created at the Origin bone of the vehicle and then attached to that bone (because of DefaultPlayerVisible being false the blocker object is invisible).
  • When the script is destroyed, the blocker object is also destroyed.
  • When the vehicle goes underground, the blocker object is made visible for all occupants of the vehicle.
  • When the vehicle surfaces, the blocker object is made invisible for all occupants of the vehicle.

Jun 20 2019

• Made next/prev weapon key modify spectator speed in freelook mode. Added maximum speed to Mammoth global settings (general), defaulting to 5.

Jun 19 2019

• Added script JFW_Attach_Script_Custom_Until_Custom
• dp88_RegenerateHitPoints: accept float interval values

Jun 14 2019

• Added support for XInput gamepads (XBox controller). Left/right stick axes are hard coded to move and look, everything else can be bound to actions in the controls menu as usual.
• Added "toggle gunner" input to options menu because it is used by aircraft and jetpacks.

Jun 13 2019

• SSGM: Simple objects with encyclopedia type "Building" get SSGM_Building attached
• Anti-Aliasing setting can now be changed while ingame and applies immediately (except in exclusive fullscreen mode!)
• Shader developers can now recompile all shaders from disk using the RESETSHADERS console command (previously crashed the game)

Jun 12 2019

• Implemented ingame editing dialogue for weapon recoil parameters: EDIT_RECOIL

• Implemented ingame editing dialogue for humans and jetpack physics: EDIT_HUMAN

• Jetpacks:
  • Added engine flame support (max. 4 bones, names starting with ENGINEFLAME)
  • Added fuel parameter
  • Added flag for temporarily enabling/disabling the use of jetpacks from scripts code

Jun 11 2019

• EMP now affects JFW_Deployable_MSA.

Jun 09 2019

• Flying infantry can now be locked on by tracking weapons.

Jun 08 2019

• Moved vehicle turn radius parameter to wheeled vehicle physics definition (used by AI, fixes weird behavior with tracked vehicles that erroneously had non-0 turn radius set).

Jun 06 2019

• Added AllowClientSpectators boolean setting in tt.ini. Allows clients to use the TOGGLE_SPECTATOR console command on themselves (player ID not required).

Jun 04 2019

• Added a stealth effect variant that is non-recursive, but has much better performance. Can be activated by setting CheaperStealthEffect to true in the object preset definition.

  • Other stealthed units won't be visible at all when looking through this effect, so use with care. Recommended for small and numerous objects (e.g. the APB mines) where visual accuracy is less important and the performance impact is high.

• Ported a bunch of changes to JMG Utility scripts from 4.x to 5.0

Jun 03 2019

• Added per-map dazzle.ini (MAPNAME_dazzle.ini) and per-map sky textures to allow for more drastic differences in sun/moon appearance

  • New sky texture settings in MAPNAME_map.ini:

    [SkyTextures] StarTexture=Star.tga LightningTexture=LightningBolt.tga LightningSource=LightningSource.tga SunTexture=Sun.tga SunHaloTexture=SunHalo.tga MoonHaloTexture=MoonHalo.tga CloudTexture=CloudLayer.tga

     

• Add new surface types Blue Tiberium, Red Tiberium and Tiberium Veins for TSR.
• Texture quality and filtering settings can now be changed while ingame and apply immediately

Jun 02 2019

• Implemented soft flight ceiling for jetpacks

Jun 01 2019

• Changed JFW_EMP_New to not do friendly fire
• AI using splash against infantry will now target swimming infantry directly (splash causes them to miss)

May 31 2019

• Added ability for semi-automatic ammo types (where you must click after every shot). Arthritis ho!
• Implemented a form of aim-assist on weapons where the ammo uses AutoAdjustMuzzlesOnEnemyTarget. Muzzles will be adjusted to an estimated distance for a fixed time after losing the target.

May 30 2019

• Fixed weapon burst fire behavior
• Fixed MSAA not working on very old GPUs (D3D feature level 10.0)
• Added EMP effect texture support (REN_emp.dds), controlled by JFW_EMP_New

May 29 2019

• Added reverse torque scaling setting to tracked vehicles (allows setting a limit on how fast they can reverse)
• Added ION console command to test the Ion_Storm_New script

May 28 2019

• Option to clear light solve data in Mammoth (check the option, save and reload!)

May 27 2019

• Moved functionality of IJ_Aircraft_Landing_Gear into aircraft phys definition.

May 26 2019

• Added a sprint sound option to human phys def

• Added flag that tracks which team the user is on, can be accessed from JS to create per team HUDs.

May 22 2019

• Editor Combat Simulator now takes per bullet reload weapons into account.

• Editor Combat Simulator now takes range (damage falloff) and whether you want to target a building's MCT into account.
• Added new human physics for flying infantry (JetpackPhys)

May 20 2019

• Added ability to dynamically set targetability (visual target boxes around object)

  • Also added ability to make a target untargetable by enemies.

  • Added script for APB to allow submarines and such to be untargetable by enemies if submerged (RA_Underwater_Target_Hider)

May 19 2019

• Script parameters are no longer limited to 256 characters total (and won't currupt objects.ddb anymore...)
• Added version check to objects.ddb so that a file saved with a newer version of Mammoth will show a warning when opened with an older version of Mammoth (prevents crashes and file corruption in rare circumstances)

May 18 2019

• Added CMD_Supply_Truck_Miner which adds a more "Generals-y" version of the miner, which can go to a docking area, drive in, collect the goods, drive out then do the same sort of thing at the refinery.

  • It requires on the refinery zone and ore zone 2 waypaths each, one for entering and one for exiting. On the zones themselves (as in the actual instantiated zones), you will need to add the CMD_Supply_Zone_Waypath script, and put the waypath IDs for the entry and exit waypaths into it.

  • Also added a new scripting command; Does_Waypath_Exist. Put the waypath ID in as a parameter and it will return whether it exists or not.

  • Slightly shortened Drive_Forwards_Into_Dump_Zone into Dump_Forwards.

  • Added CMD_Supply_Dropoff_Animation_Zone, which allows a simple object to run an animation when a supply truck arrives at an ore zone.
• Error log contents are now deleted on first write so we don't end up with 100s of MBs of logs after a while.
• Added 'Host bone offset' vector to PhysicalGameObj, and a scripts function Set_Host_Bone_Offset(). Makes it possible to attach an object to a bone with a fixed offset without requiring a bone.

May 15 2019

• Added extra parameter to dp88_Ore_Miner: Drive_Forwards_Into_Dump_Zone

• Added team parameter to JMG_Utility_Apply_Damage_While_In_Zone
• Fixed the muzzle flash bug, transitions (switching camera, sniping, etc) no longer cause a muzzle flash to go off for no reason.

May 13 2019

• Added configurable Stealth on/off SoundIDs to global settings

Mar 07 2019

• Added damage by poke script pair: MS_Damage_By_Poke_Poker, MS_Damage_By_Poke_Target

May 06 2019

• Added ability to choose which vehicle types an ammotype can track. This is based on the internal type of vehicle, set on a vehicle's Settings tab.

May 05 2019

• Added ability to visualise the projectile bounds in game with the Toggle_Proj_Bounds console command. NOTE: Cannot be toggled without adding AllowDebugVisualisation = true in TT.ini

• Added a parameter to weapons, CannotFireWithoutLock which means that weapon cannot fire without a tracking lock-on (if the ammo it is trying to fire can track)

Apr 21 2019 — APB 3.4.0.0

• Added CMD_Repair_Zone_Anim, which will run animations on the service depot nearest this zone (so ideally the zone that spawned it)

Apr 18 2019

• Vehicles can now have multiple ejection ports, named under the same scheme as the muzzle bones. Eg. MuzzleA0 should have EjectA0, MuzzleB2 should have EjectB2, etc.

  • If the secondary fire mode is being used and the game can't find an EjectB bone, it'll look for the equivalent EjectA bone.

  • If any numbered bones can't be found, it'll look for a simple Eject bone. If it can't find that, it won't bother.

Apr 17 2019

• Modified continuous emitters and weapon code to use a rough estimate for particle travel time (stops them from going through walls)

• Merged "Gunplay" branch into 5.0, tons of new stuff available, in particular detailed recoil controls.

Mar 31 2019

• Vehicle doors now open for bots too

Mar 20 2019

• Various improvements to dynamic lighting, now actually uses the light intensity value and is consistent with the calculations of light-solve

Mar 16 2019

• Made Ranged_Damage_To_Buildings and related scripts functions use the same logic as the beacon for scaling the damage: Find the closest hit geometry polygon.

  • Previously, the building controller position was used, which caused inconsistency between nukes and demos/MADs and unintuitive behavior for large buildings

  • Take note that underground geometry can be hit and might be closer to the explosion than intended!

Mar 15 2019

• First public release of Max 2017 export tools!

Mar 14 2019

• Implemented multiple target bones and compatibility with tracking weapons. They will lock onto the tracking bone closest to where the user is aiming. Bone names are all that start with TARGET.

• Added specular lighting.

  • Material setup: Set specular colour in the Material Editor and shininess to a value between 1 and 1000. Lower values will cause the specular reflection to be very wide angled and diffuse, higher values will show up very tight and pinpoint.

  • To enable, create a new ini called RendererFeatures.ini and put these two lines in it (also put this in the W3DViewer folder):

    [RendererFeatures] SpecularEnabled=true

     

• W3DViewer

  • Display camera and poly values, animation frames and FPS.

  • Implemented "Copy Screen Size To Clipboard"

  • Implemented "Generate LOD"

  • Implemented "Record Screen Area"

  • Implement "Import Facial Anims"

  • Keyboard shortcuts for animation commands:

    Key	Action
    P	Play
    Space	Pause/Resume
    S	Stop
    Left/Right Arrow	Step Back/Forwards

     

Mar 10 2019

• "Prelit" is now a mesh flag instead of a user text addition in the new Max 2017 export tools.

Mar 08 2019

• Added new physics flag SmoothTurning for tracked vehicles and walkers that allows them to have smoother steering.

Mar 05 2019

• Allow the JS hud to use .ttf fonts. This requires setting a font name in hud.ini, as well as defining a FontSize for that element.

Mar 03 2019

• Changed maximum client→server net update rate (NUR) from 30 to 75.

Feb 26 2019

• Added new script CMD_Eject_On_Custom to force the driver and any passengers to eject from a vehicle on custom 68470001 (CMD_CUSTOM_EJECT).

Feb 21 2019

• Added TOGGLE_SPECTATOR <playerid> console command (host only).

Feb 18 2019

• Reimplemented untrack timer for tracking weapons. Last ammo fired (primary/secondary) will be used for the tracking logic.

Feb 17 2019

• Added new console command, ADDWEAPONS <playerid>. This adds all the weapons that have the flag AGiveWeaponsWeapon set in them. Useful for testing things.
• Also added the ability for ejected shotgun shells to have a different sound when they hit the ground. Use flag EjectIsShotgunShell in the weapon.

Feb 16 2019

• Improved weather system (snow in particular):
  • Fixed flickering/Z-fighting for surface-aligned particles (snow that has hit the ground)
  • Surface-aligned particles can now be seen from the other side of a window
  • Particles outside of the view cone are skipped during render processing
  • Maximum particle count can now be configured in tt.ini (can also be set per-map using xxx_tt.ini): MaxWeatherParticles (default 10000)
    • Set with care, this can affect performance significantly at higher densities
  • Reduced performance impact of excessive density settings, but still: Don't do that!
    • Performance deteriorates when moving quickly, can also freeze the game for a bit on teleport/respawn
    • Check whether particle count is at maximum via r_stats console command ingame, reduce density accordingly (maximum might not be hit exactly)
• Improved roll response of aircraft mouse steering. CTOL Aircraft has a new parameter "Roll Auto-Leveling Anti-Wobble" that will allow you to tune the auto-leveling separately.
• Made aircraft lift scale down towards 0 when rolling the plane upside down instead of always working 100% towards the top of the plane

Feb 15 2019

• Added active brakes for MotorVehicle physics model (used by Wheeled Vehicles), new parameter BrakeStrength. Press crouch or jump to trigger.
• Fixed the sound engine not getting the correct length of pitch shifted sounds (noticeable on Jukeboxes with pitch shifted songs)

Feb 14 2019

• DeadFactoryHarvesterSpawn setting on the vehicle factory now respects the SpawnDelay of the spawners

Feb 13 2019

• Changed vehicle engine sound pitch shift behavior for various vehicles. VTOLs and planes now use thrust, tracked vehicles use torque.
• Improved "fake HDR" rendering for the sun
  • May require changes in dazzle.ini and/or better dazzle textures since they weren't as visible before.

Feb 12 2019

• JFW_Airstrip_Reload_Zone now forces the plane to reload when it lands

• Aircraft advanced controls (keyboard) now enable FollowVehicleOrientation on the camera profile so you don't have to take your hands off the keyboard (see cameras.ini)
• Added command line option to specify light solve thread count in Mammoth: --light-solve-threadcount X
  • Use 1 if you consistently run into weird issues like infinite loops or light solve timeout

  • artillery.json can pass the argument to mammoth by adding it in the "export options" section

    "export_options": { "SOME_LEVEL.lvl": "--light-solve-threadcount 1", },

     

Feb 11 2019

• Fixed JFW_Airstrip_Sell_Vehicle allowing more than one sale of the same vehicle if you spammed the key
• Improved aircraft mouse steering by implementing a PID controller
  • 4 new tunable parameters per rotation axis (see CTOL Aircraft, use edit_vehicles ingame)
  • Reduces oversteering/wobbling and allows the steering to overcome potential pushback from the physics

Feb 09 2019

• Added facilities for ingame GPU & CPU statistics. Use console command R_STATS to toggle display.

Feb 08 2019

• Players can now exit planes that have safely landed anywhere on the map
• Added MenuPushedColor in hud.ini to set the color of pushed buttons in menus

Feb 07 2019

• Changed CTOL flight ceiling behavior and added three new parameters in CTOL Aircraft: Buffer Zone, Z-Velocity Threshold and Thrust Loss

Feb 06 2019

• Projectiles can now have an animation. The flag C4Animation is now ProjectileAnimation and enables it.
  • Export the projectile as a Hierarchical Animated Model and tick the box
• Fixed crouch movement speed, implemented option for crouch toggling

Feb 05 2019

• Weapon settings: Removed "auto-switch to last weapon when fired" logic from IsQuickCastAbility, moved it to its own setting "AutoSwitchOnFire"
• Fixed the ore truck never spawning again when it is destroyed before taken over by the refinery (or when WF dies while delivering and DeadFactoryHarvesterSpawn is enabled)

Feb 01 2019

• Added an option to take all screenshots without the HUD regardless of whether it's globally enabled
  • Toggle ingame using HUD_DURING_SCREENSHOT console command (faster typing: "HUD" + Tab + Enter), also gets saved between sessions in game.cfg

Jan 31 2019

• Bots can now detect enemies on radar
• Bots can now respond to killing enemies (section [EventKiller] in bot_config.cfg, analogous to [EventKilled])

• Mammoth: Added buttons for testing pitch factor and pitch randomization to the "Play Sound" dialog (also fixed crash when closing this dialog)

• Mammoth: Added "Play Sound" button to the sound preset settings

• Fixed weapon rate of fire timer resetting when sprinting or switching weapons. Allows weapons to have a lower switch delay than ROF interval without being abusable.

Jan 30 2019

• IJ_Aircraft_LandingZone_Aircraft now disables collision damage on aircraft within the landing zone against everything except terrain

• Implemented crash landing for CTOL aircraft
• Fix ingame freezes and stuttering from superfluous shader compilation (particularly stealth shader)

Jan 27 2019

• IJ_Aircraft_LandingZone_Aircraft now disables collision damage on aircraft within the landing zone
• Bots can now respond in chat to being killed, messages configurable via bot_config.cfg (which is an INI file in disguise)
  • New section [EventKilled], entries Enabled (int), ResponseCount (int) and RespX (string), where X is an integer index

Jan 26 2019

• Added CollisionDamageMultiplier to vehicles, does damage on collision with any other object
• Improved suspension physics behavior
• Added separate flight ceiling setting for CTOL aircraft

Jan 25 2019

• Fixed loading screen text

• Decoupled weapon tracking logic from primary ammo def

  • Weapons can have fully different stats for primary and secondary fire without messing up tracking.
  • The HUD displays and targeting are calculated based on whether the player used primary or secondary fire last.

• Not setting a secondary ammo no longer causes a crash, No secondary ammo type means the weapon won't fire if secondary fire is pressed.

Jan 24 2019

• Added support for rotatable textures for the GraphicInterface/JavaScript UI (including an offset for the pivot)
• Replaced WeaponDefID and WeaponRounds in armed game objects (i.e. vehicle and soldier presets) with a list of IDs and ammo counts
  • Backwards compatible, i.e. weapon list will load the old values in, filling "zero" WeaponDefIDs with empty slots (can be deleted if not needed)
  • Preset list dialogs (e.g. this, twiddlers, spawners) now support drag & drop reordering and can add/edit extra data (in this case ammo counts for every weapon preset given to a character/vehicle)
  • Ammo count can be edited via double click on the corresponding column entry, list items are now deleted via the DEL key
• When switching to a camera profile with FollowVehicleOrientation enabled, automatically face forward. This makes it slightly more useful, but exiting from a vehicle still points you in a semi-random direction.
• New weapon preset option "DelayedChargeFire", delays firing for charging weapons until trigger is released

Jan 23 2019

• Fixed sound pitch control and randomization (@devs: check all your sounds for pitch settings that until now didn't do anything!)
• Fixed weapon firing sounds getting cut off at high RPMs
• Added option for random pitch shift on vehicle engine sounds
• Added new weapon preset options IsQuickCastAbility and QuickCastAutoSwitchDelay, intended to be used in conjunction with IsCooldownAbility
  • Will fire immediately upon switching to it, then switch back to the last weapon after QuickCastAutoSwitchDelay (in seconds)
  • Will immediately switch back to the last weapon when interrupted by entering a vehicle, getting on a ladder, etc.
  • Cannot be selected via mouse wheel to prevent misfire, cannot be switched to at all if not ready
  • BUG: if you have a charging QuickCast weapon out while entering a specific vehicle for the first time, the vehicle will fire once (only on FDS, involves lag and is difficult to fix)
• Added MouseSteering_Sensitivity and MouseSteering_AggressiveTurnAngle to aircraft physics definitions
  • Sensitivity is a Vector3 for roll/pitch/yaw (in that order)
  • Aggressive Turn Angle designates the angular difference threshold beyond which the mouse steering will fully roll towards the target by pointing the plane's topside towards it

Jan 18 2019

• Added flap movement to aircraft, using the bones AILERONxxx, RUDDERxxx and ELEVATORxxx

Jan 16 2019

• Added FPS limiter to client, maximum read from engine.cfg (MaxFPS, default 300), can be set by MAXFPS console command
  • Alt+Tab was changed to not disable rendering and instead limits frame rate to 40fps
• New mouse steering implementation for aircraft, less likely to tilt your plane down for no reason

Jan 14 2019

• Added new scripts IJ_Aircraft_Landing_Gear and IJ_Aircraft_LandingZone_Aircraft
  • Allows manual landing gear deployment (add the name of a custom key hook to the landing gear script (e.g. "Deploy")
  • Replace dp88_Aircraft_LandingZone_Aircraft with these two scripts, copy all parameters
• Aircraft thrust now shows/hides the EXHAUSTxxx bones of the model
• Added an InfantryOnly parameter to script zones (if both InfantryOnly and VehicleOnly are checked, either class can activate it)

Jan 13 2019

• Implemented soft flight ceiling for CTOL aircraft
• Fix to make model-based script zones work if not placed at 0,0,0
• Fixed dazzles not appearing
• Added a VehiclesOnly parameter to script zones

Jan 12 2019

• Added placeholder HUD for CTOL aircraft

• Added CameraBone and DisableFloatingPlayerName parameter to cameras.ini. See documentation: cameras.ini.

Jan 11 2019

• Added edit_camera console command to modify camera profiles (does not write to ini file, like edit_vehicles)

• Added MaxCruisingSpeed parameter to aircraft presets

Jan 8 2019

• JFW_Airstrip_Repair_Vehicle now autostarts instead of waiting for a key press

• MS_Jukebox new parameters:

  • Delay delays the first song by x seconds
  • FirstSong forces the first song in the playlist to be played first instead of it being random

Jan 5 2019

• Added repair delay to JFW_Airstrip_Repair_Zone/JFW_Airstrip_Repair_Vehicle

Dec 31 2018

• Bots now dynamically change roles from offensive to defensive on demand as respective defensive/engineering objectives appear/disappear (first 3 bots used to be forced to always be defenders/engineers)

Dec 29 2018

• Add new flag NoLoop to MS_Jukebox, plays only the first song and then stops

Dec 28 2018

• Added the ability to add loading screen music on a global and per map basis.

  • Uses LoadingMusic key in tt.ini (for global) and in [mapname]_map.ini for per map basis. Fades out after loading is complete in 1 second.

• Added MS_Jukebox script for sound objects, references a Twiddler that contains the list of music tracks to play

• Bots now grab their vehicles faster and leave less vehicles crowding at the WF (mostly affects APB bots)

Dec 26 2018

• Added ability to point filter textures. Controlled via TextureManager.ini.

Dec 24 2018

• Fix so pre-placed vehicles dont crash

Dec 23 2018

• Added a parameterised repair delay to JFW_Repair_Zone_2, as well as 2 versions for APB that have Boats/Non-boats filtering.

• Added a safety timeout to Mammoth light solve due to a deadlock bug with unknown causes and solutions

• Added a progress bar and a few printouts to Mammoth batch mode (needs updated artillery)

Dec 20 2018

• New Aircraft physics model!

Dec 19 2018

• Fix fullscreen mode when DPI scaling is active on Windows 10

• MouseSteering VTOLs now strafe by default

Dec 13 2018

• changed settings to enable mouse steering without forward movement

Dec 12 2018

• Added weapon preset option CooldownAbility to always reload on a fixed cooldown, even if not currently held. The cooldown is equal to the reload time and starts as soon as the current clip is non-empty.

Dec 9 2018

• Enabled texture quality setting

  • Menu and loading screen backgrounds are loaded just like ingame models, so they must have no mipmaps to not be affected by texture quality (other UI textures still waste space if they have mipmaps, but it won't cause visual issues)

Dec 7 2018

• Made several logging facilities use a separate thread to write to disk (reduces stutter, especially with active anti-virus programs running)

  • Client chat log, server console log, anti-cheat log, engine diagnostics

• Converted client chat log to UTF-8, unicode character messages aren't just empty now

Dec 6 2018

• New scripts JFW_Tint_Controller and JFW_Water_Tint_Zone

Dec 3 2018

• Added FollowVehicleOrientation parameter to cameras.ini. See documentation: cameras.ini.

Dec 2 2018

• Multi-file drag-drop in w3dviewer

Dec 1 2018

• Remove "Generate LOD" from w3dviewer as no-one seems to need it at this point and finishing the implementation is a fair bit of work. If it (or any of the other w3dview features I decided not to support) turns out to be useful we can go back and implement it later)

Nov 30 2018 — APB 3.3.1.x

• Fix Mammoth pathfind generation for doors

Before I start the story of scripts.dll, let me say that I have been involved with modding for the C&C series since the beginning. I was the first person to figure out the RLE compression used for the .shp files of Tiberian Sun and I spent many hours in the debugger extracting filenames for the old games (anyone who knows how the old games worked will know that they didn't store filenames in the mix files and the community had to figure out the correct filename for all the files in each mix file).

Origins

The scripts.dll story begins when the mod tools came out.

When they came out I started fiddling with them and pulling the game and tools apart to see how they worked (as I had done with previous games).

I wrote a number of things back then including a fairly primitive W3D viewer (I still remember asking Greg Hjelstrom a LOT of questions to fill in the gaps in the knowledge of the w3d file format).

In terms of scripts.dll and its history, I did 3 things at that point. Firstly, I was involved (with a few others from memory) in convincing Greg to write a few rather useful scripts and include them in one of the later patches to Renegade. (these are the scripts that start with GTH).

 Secondly, I was involved in an effort to convince EA to release (to the public) the source code to the scripts.dll (not the engine itself, just the scripts.dll) to allow people to write their own gameplay scripts. This didn't happen (despite a fairly well-supported online petition) mostly because EA was concerned about the code being abused (malware etc).

And thirdly I was pulling the scripts.dll apart to figure out how it worked and what various of the scripts actually did. The first result of this was a tool called "scripts test" that simply dumped a list of all the scripts in the scripts.dll.

Other than the leveledit debug strings I found (and what I was able to figure out from reverse engineering and testing) I did also make use of a bunch of info given to me by Greg Hjelsrom at various points (I wont go into details since I don't have all the relavent emails etc handy and I probably should say too much in public anyway but lets just say that info was vital to getting things to work in those early days.)

My memory is a little hazy as to when I first decided to start writing my own gameplay scripts but the first official release came out on the 20th of August 2002 and was named version 0.9 beta. According to the old readme file I found (the only part of 0.9 beta I still have), version 0.9 beta contained 3 scripts named JFW_Spawn_Object_Death,JFW_Create_Objective_Death and JFW_Update_Objective_Death. JFW_Spawn_Object_Death (the first script I ever wrote) is still in the scripts.dll even today (and what the script does hasn't changed in all that time). The reverse engineering work at that time was (from memory) mostly done with various versions of IDA Pro (I forget if I was still using SoftIce for Renegade or not) and all the code was being written with Visual Studio 6.0.

That was quickly followed by 0.91 beta, 0.92 beta, 0.93 beta, 0.94 beta, 0.95 beta, 0.96 RC, 0.97 RC, 0.98 RC, 0.99 RC, 1.0 RC1 and then 1.0 RC2 (the oldest version I still have on my disk). Work continued on figuring out the internals of scripts.dll and the way scripts.dll talked to the engine (to expand what scripts.dll could do). By the time 1.0 RC2 hit, I had discovered a new source of information in the form of debug strings in the Renegade level editor. This gave us (the people working on scripts.dll at the time) the names of a bunch of things in the engine (including lots of the script commands).

Most of the work at this point was done by myself, Dante and Sir_Kane although some scripts had also been written by NameHunter. 1.0RC2 contains somewhere around 80 scripts or so, mostly written by me but also a few by NameHunter and Dante. Highlights include the first construction yard scripts,the beginnings of AI scripting and some nice utility functions including the first functions for sending a custom on zone entry.

The next part will cover the rest of the 1.x series (I no longer have copies of 1.0 final, 1.1, 1.1.1, 1.2 or 1.3 but I have all scripts versions from 1.3.1 through to 1.9.3 and will be able to talk more about what changed through those versions)

Scripts 1.x

Scripts 1.0-1.9

After 1.0 RC2 came 1.0 final (which I no longer have) then 1.1.

I still have an incomplete copy of a build labeled "1.1" in the readme file (although I dont know exactly what build it is, whether its 1.1 or 1.1.1 or something in between builds or what)

 The big change in 1.1 was the discovery of a complete symbol table in the Linux FDS (in layman's terms its a list of all the functions in the executable file with their names and definitions). Discovering this allowed me to completly rewrite the code to be a lot more like the original Westwood way of doing things. Too many changes between 1.0 RC2 and the code I have labeled 1.1 for me to go into any more detail.

Then after 1.1 came 1.1.1, 1.2, 1.3 and then 1.3.1 (the next build I still have)

In the time between the 1.1 code I have and the 1.3.1 release, work continued on reverse engineering the engine and I continued to write scripts to do cool stuff (and to take advantage of any new engine discoveries I made). NameHunter wrote more scripts and the first scripts for Reborn (not sure who wrote these early scripts) and RenAlert (written by Dante) were written. Also some scripts for something called Survival (not sure what this was or who wrote these early scripts) got written.

1.4 continued the general improvements along with more new scripts by me. This also marked the start of some scripts being written by Vloktboky. Further additions were made to the Reborn scripts (not sure by who) and the RenAlert scripts (this marked the beginning of work on RenAlert scripts by NeoSaber)

New in 1.5 was support for the Linux FDS thanks to Datalore (who did a great job of dealing with the funky way GCC does inline assembler and the other Linux-specific weirdness). Also new in 1.5 was a refactoring of some core code to be closer to how the real thing is laid out along with more engine research and general improvements. New scripts were written by Vloktboky and myself.

1.6 had more scripts by me, more cleanups, more scripts by Vloktboky, a couple new scripts by NameHunter and some new RenAlert scripts by NeoSaber. It also introduced some scripts for a mod called RA2 Vengeance.

1.7 had still more cleanups and engine research, more scripts by me (including the cloning of a bunch of interesting stock scripts), more scripts by NeoSaber (both for RenAlert and otherwise), some new scripts from TimeFX and a bunch of scripts from E! for a Generals mod called SCUD Storm.

In 1.7.1, the big change was a move from Visual C++ 6 to Visual C++ .NET 2003. Cleanups and engine research continued although this build contained no new scripts.

1.8 introduced the first engine calls (with a LOT of hacks involved). Cleanups and general engine research also continued. More scripts for Scud Storm, RenAlert and RA2Vengeance were added along with new scripts by me.(including more clones of stock scripts). One of the engine calls introduced in this first batch was the first engine call to use the special "debug fly" flying infantry logic westwood left in the game.

Scripts 1.9 was a major milestone with the first engine hacks being added. New console commands were added. Various engine calls were fixed to work over the network including animation, stealth, explosions, audio and poke. Exported engine functions were made available to do per-player screen fade and player terminal display. Fixes, cleanups and engine research continued as usual. More engine calls were added to engine.cpp including console input and output calls. New scripts were added by me along with new RenAlert scripts from NeoSaber.

1.9.1 was just some bug fixes on top of 1.9.

1.9.2 was more bug fixes on top of 1.9.1.

1.9.3 was just a bug fix on top of 1.9.2.

Scripts 2.x

Scripts 2.0 - 2.1

2.0 was released around xmas of 2004 and by this time the Blackhand Studios development group was well established and quite a few other people also worked on engine work besides me  (I dont plan to cover things like RenGuard or the Core Patches in this history series, nor do I plan to cover things written by other people like brenbot, the old pre-4.x SSAOW/SSGM/SSCTF stuff, Dragonade or Renegade Resurrection)

In 2.0, a number of script commands were made to work correctly in multiplayer including screen fade. Per-player commands were added for playing audio and some other things. The first commands to display messages on the client were added in 2.0 as well. Various other bhs.dll fixes were made including making Set_Model work correctly over the network for vehicles and infantry and stuff and making the harvesting arms of the tiberium harvester animate when its harvesting. A fix was also added for granting weapons to vehicles and changing the weapon of a vehicle. More console commands also got added.

New engine calls got added to engine.cpp including engine calls to remove scripts from an object, get the occupants of vehicles, get the weapon an object is using, get the hierarchy/skeleton name of an object, get the "sex" of an object (so you can use the correct infantry animation set) and kick the occupants out of a vehicle.

Some scripts were written by Dan, Vloktboky and myself along with an AI script from NeoSaber. General cleanups/fixes and engine research continued as usual. TheKGBSpy wrote more scripts for RA2 Vengeance. Due to some crap going on at the time that I wont go into, RenAlert wasn't shipping newer scripts builds or bhs.dll at the time but instead shipping their own thing (I will not be discussing the details of what was going on at the time since its long since over, all the people involved have left the community AFAIK, all the "secret" scripts were eventually published and all the engine know-how the relavent people were hoarding has long since been figured out)

2.0.1 followed soon after and fixed a couple of bugs.

Then came scripts 2.1. 2.1 added more new console commands. 2.1 also introduced code to output screenshots in .png format instead of the default .tga format. A hack was introduced that made maps load much faster but (unbeknownst to me at the time) made things load a lot slower in-game by disabling some code to pre-load and parse a bunch of w3d files on map load. The object create hook system was added in 2.1, as was the custom key hooks and the first version of the custom sniper scope code. Extra log files started to be created to log all sorts of messages (the details of why we started creating these log files is lost in the mists of time). The chat hook was first introduced in 2.1 as well as was a fix for the invisible harvester bug with airstrips. A fix was added to make the infantry death sound and powerup collection sound play in multiplayer. An engine call was added to get the version of bhs.dll.

Engine research and general fixes/improvements/cleanups also continued in 2.1. Engine calls were added to access the cGameData instance among other engine calls.By this time we had figured out the initial definitions of classes in Renegade including cGameData and WeaponBagClass as well as utility classes like Vector4, Matrix3D, SList, SimpleVecClass, SimpleDynVecClass, VectorClass and DynamicVectorClass. I wrote more scripts including clones of all the "secret" scripts RenAlert was using at the time (and at that point was refusing to share). The first scripts to be written by scripts contributor and later engine guru Saberhawk got added in 2.1 as well.

2.1.1 and 2.1.2 were just bug fixes on top of 2.1 to fix some issues with the AGT scripts.

2.1.3 added some stuff to disable some of the logging on the client (since some people didn't want those logs). It also featured code cleanup and improvements and bug fixes and the first efforts to block specific "bad" nicknames (e.g. nickname too long, nickname containing bad characters etc). Code was also added to disable certain netcode that could be used to cheat.

Scripts 2.2

After 2.1.3 came 2.2 which was a big release.

In 2.2, all of my scripts were re-organized into new source files divided up based on what sort of script it was (e.g. sounds, weapons, cinematics, vehicles, powerups, script zones etc). The usual cleanups, bug fixing and engine reverse engineering continued. New engine calls were added including the first engine call for changing the spawn character. Reborn got the first scripts for walkers/mecha and some new deployable vehicle stuff. I wrote some new scripts as well.

bhs.dll got a lot of improvements. Lots of work went into bug fixing, fixing crashes etc. 2.2 introduced the new crashdump code where the code to emit _except.txt when crashes happened was ripped out and replaced with new code to spit out a crashdump.txt with more info than _except.txt had. This made debugging crashes much easier. The chat hook was modified to support unicode messages (important for players using foreign language characters like ö in their chat strings). A hook was added to allow you to listen to "host messages" (i.e. messages sent from the server in various ways).

Scripts 2.2 was quickly followed up by scripts 2.2.1 and then 2.2.2. Both versions contained only bug fixes on top of 2.2.

Around the same time as scripts 2.2 came out, I also released a hacked improved version of leveledit (numbered 1.0.0.4) that fixed a bunch of bugs. Highlights of this release included making it read scripts.dll/scripts2.dll from the Renegade folder (no more need to copy them to the mod folder), fixing some crashes, adding the "export to mix" menu option to the menus (the logic was already there, it just needed to be made visible), displaying the current mod package name on the status bar and properly reading the game data files (including always2.dat). 1.0.0.4 no longer had problems when placing certain objects like multiplayer helicopters.

Scripts 2.3-2.4

Scripts 2.3 hit in January of 2006. It featured the usual bug fixes, cleanups and engine research. It also added some stuff to make Set_Obj_Radar_Blip_Shape and Set_Obj_Radar_Blip_Color work over the network. Code was added to include the Windows version and the date and time in crashdump.txt files. An engine call was added to let you switch to a different main hud texture at runtime. Improvements were made to the keyhook stuff. More scripts were written by me. WhiteDragon also wrote some scripts and some stuff was added for Reborn.

Scripts 2.3.1 then followed soon after with a few bug fixes.

After that came scripts 2.4 a few months later.

2.4 added some console commands to set and get the bandwidth for a player. The player join hook, load level hook and game over hook were added. The first hud.ini stuff was added (changing the colors used for the teams in chat etc). Engine calls were added to identify if running on Linux vs Windows and Dedicated server vs game client along with a way to identify the current game mode (WOL vs gamespy vs lan vs etc) and a couple of others.

The usual scripts cleanup, bug fixing and engine research also happened for 2.4 along with some new scripts by me. The split between the RenAlert guys and myself went away and all the secret stuff stopped. My reverse engineered clones of the formerly-closed-source scripts were removed and replaced with the real thing thanks to NeoSaber.

The "secret" scripts stuff was basically some stuff that for whatever reason the RenAlert guys didn't want to share. It had the missile silo scripts, CanyonRiver and Metro scripts, underwater stuff, submarine script and vehicle script. I dont want to go into details of the whole fight over the issue (and over the various engine related things that the "secret" scripts made use of) so this is all I will say on the matter.

Scripts 2.5-2.6

2.5 came out next and added a special console command and a few other things for the Linux FDS and some WOL stuff people were doing at the time. Code was added to disable the GameSpy serial number check (the GameSpy serial number database was missing serials from The First Decade so TFD players were unable to play on GameSpy without this change).

More cleanups, fixes and engine research happened as well along with the addition of some engine calls for getting information from players (current money, current score, things like that) although no new scripts were added in 2.5.

2.5.1 came out soon afterwards and fixed a bug with some things in 2.5 then 2.5.2 fixed more things.

Next came scripts 2.6. The usual cleanups and fixes and engine research continued, as did some new console commands for changing the vehicle limit as well as the commands for sending messages to the client and having them appear in the chat box alongside messages like "unit ready". Display_Health_Bar was made to work over the network as well as entries in hud.ini to let you change the public and private message colors. Per-player radar blip shape engine calls were added at this point along with engine calls for vehicle limit and message sending.

A bunch of new engine calls were added to engine.h including the first engine calls that worked with strings from strings.tdb. A bunch of new scripts got added by me.

Scripts 2.7

Scripts 2.7 again had the usual bug fixes/cleanups/engine enhancements.

Console commands were added to disarm C4 and beacons for a player along with some more stuff for LFDS WOL work. The Disable_All_Collisions, Disable_Physical_Collisions and Enable_Collisions engine calls were made to work over the network. A hook that gets triggered any time a player sends their version to the server was added along with a Set_Wireframe_Mode engine call and some work on an engine call for removing a weapon from a player. The first attempt at code to let you change the PT data at runtime was also added.

2.7 also marked the introduction of the first custom HUD code with large parts of the HUD (health/shield bar, time, credits, radar, weapons and other things) being customizable. Engine calls were added to engine.cpp for getting/setting the current ammo for weapons in various ways, disarming beacons and working with the PT data. 2.7 was the first version to expose the ini reading functionality to scripts.dll so people could use it to read and write ini files (instead of whatever code they had been using previously). I wrote some new scripts as did WhiteDragon.

2.7.1 followed 2.7 and contained bug fixes.

Then 2.7.2 followed 2.7.1 with more bug fixes.

Scripts 2.8-2.9

2.8 had more bug fixes/cleanups/engine research. It introduced per-player fog commands, Improvements were made to the code for sending the PT data changes over the network. Improvements were made to the custom HUD logic. New hud.ini keywords were added to let you change the cost and time multipliers that apply when the power is down, to disable the "locked to the player who bought it" logic, enable the use of the "hidden" PT pages globally and enable some special logic for purchasing. Fixes were made to try and stop certain server exploits. A change was made to make disabling the radar work better. Hooks were added for powerup purchase, vehicle purchase and character purchase as well as hooks for monitoring those purchase types (used if you just want to log things rather than actually change how the purchasing happens).

Engine calls were added to get the build time multiplier (i.e. the value used to increase the build time when the power plant goes down), change some settings related to the scrolling radar map feature, set/get a flag that will display "building" for vehicle buttons (used as part of various scripts that I will get to later). Code was added to send everything that would be written to the console through a UDP packet (intended so you can have something such as a server bot catch it and do stuff with it and not need to parse log files for the same info).

The first definitions of the classes NetworkObjectClass, OBBoxClass and BaseControllerClass were added. Engine calls were added to turn the base power off/on, toggle the base radar, find buildings of different types, identify if a map is a flying map (i.e. if the checkbox in LE is ticked), do things with script zones and some other stuff. I wrote some new scripts and some scripts written by Kamuix were added. Some new scripts written by WhiteDragon were also added including the first version of the ExpVehFac stuff for creating working naval yards and helipads where you buy stuff directly from the regular PTs

After 2.8 came 2.9.

2.9 included the usual cleanups/fixes/engine research along with new scripts by me. WhiteDragon wrote one new script. Engine calls were added to get the type and size of a script zone, to create a script zone at runtime and to identify if a given xyz coordinate is inside a given script zone. Console commands to change the player limit and time values were added. A new hud.ini keyword was added to turn off some code related to the disabling of the "vehicle" button when a vehicle is building. Hud.ini keywords were added to change a bunch of colors related to the UI as well as to disable the glow around the large menu item text icons. Hud.ini keywords were added to allow you to make certain units unsquishable and change certain things associated with the stealth texture. The first version of the sidebar logic also appeared in 2.9. A hook to grab all the console output was added along with a way to change the reticle textures for a given client at runtime. Engine calls to do things related to fog got added along with various ways to change the player limit. A fix got added for a glitch with the "start" button when connecting to XWIS/WOL and a hook to let you do special checks of hud.ini to prevent modifications for cheat purposes (the forerunner to the current scripts anti-cheat code). A new dialog box to display the chat history was added (since the sidebar doesn't have an inbuilt chat history like the PTs do)

2.9.1 followed up with some bug fixes and then 2.9.2 came after that with more bug fixes as well as some changes to prevent people mixing incompatible versions of scripts.dll and bhs.dll (e.g. trying to use a newer bhs.dll with an older SSAOW or similar)

Scripts 3.x

Scripts 3.0

3.0 was the first release to include the massive graphics enhancement that was shaders.dll. Saberhawk contributed a lot of the graphics code to this release and StealthEye did work on the netcode. This was the first version built using Visual C++ 2005.

Console commands to display a w3d file in-game and to turn off the HUD were added. More information was added to crashdump.txt. Improvements were made to the custom hud code. More colors related to the UI became customizable. Purchase sounds were added to the sidebar. A fix was added for vehicles getting stuck near ladders (including aircraft flying over them). A player leave hook was finally added. "wall lag" was fixed. C4 objects now triggered scripts attached to them properly. Turret lag was fixed. The first version of the "extended options" dialog got added (to allow in-game setting of various scripts.dll options). An engine call was added to trigger the "you aren't allowed to use this dialog" (like you get when you use an enemy PT).

Renegade was updated to detect more video cards and driver versions. 3.0 was the first version that moved Renegade so it was using Direct3D9 instead of Direct3D8. The shadow quality was improved. Programmable shader stuff was added including a normal mapping shader, a glass effect shader, a glow shader and some post-processing shaders. The usual scripts cleanups/fixes/engine research continued. A lot more classes in the game had their definition figured out or expanded/fleshed out (including for the first time, several of the GameObject classes). Engine calls were written to open a file (such that it would read from the mix files or data folder as appropriate), access weapon and ammo definitions and do some other stuff.

The first scripts for the RenAlert gap generators were added in 3.0 along with some other scripts for that mod. A clone of the Test_Cinematic script was added and I wrote several other new scripts. Kamuix wrote some more scripts as did WhiteDragon. Saberhawk wrote one new script. Work was done to make sure the scripts compiled with Visual C++ 2005 Express (the free version)

Scripts 3.1

Scripts 3.1 came out shortly before xmas of 2006 and contained a lot of bug fixes, cleanups and engine research. The "vsync" feature was added. I wrote some new scripts. Stuff got added to do different things with shaders and scopes. 3.1 may not sound like a big release but a lot of bug fixing and cleanup went into it to try and solve as many of the "3.0 sucks" complaints that were happening on renforums at the time.

3.1.1 followed soon after with a bunch more bug fixes and cleanups then 3.1.2 soon after with more fixes. Work continued on solving all the crashes and glitches people were reporting. A lot of the problems people had with the 3.x released turned out to be crappy graphics drivers, having shaders enabled on cards that just couldn't handle them properly or using the example shader databases in ways they weren't intended for.

3.1.3 came out next and had more bug fixes and cleanups. Then 3.1.4 followed (which was 3.1.3 with bhs.dll from 3.1.2 since I was unable to release a new bhs.dll at the time)

Then came 3.2 with even more bug fixes, cleanups and engine research. The graphics system continued to be improved and fixed. 3.2 also improved the generation of crashdump files so it wold keep multiple dumps around. Improvements were made to the unsquishable logic and a hud.ini keyword was added to let you disable the standard kill messages. Extra debug logging was added to the d3d9 code. Lots of shader work was done. "post process" shaders were renamed scene shaders. Some new memory leak detection code was added to the scripts.dll and a lot of memory leaks fixed (including memory leaks that existed in the stock game). Multi-sample anti-aliasing was added. An engine call was added to help you identify what object caused an explosion when one happens (i.e. beacon/c4 explosions). A bunch of classes were mapped out and reverse engineered and a bunch of engine calls (including one to let you iterate the player list) were added.

The old engine.cpp file was split up into multiple files to make it easier to manage. A lot of effort was put into performance as well. The first use of SSE in scripts.dll happened in 3.2. I wrote some new scripts. The first scripts for the Roleplay2 mod by Jerad Grey were added along with some more scripts from Kamiux. Zunnie wrote his first scripts and some more scripts were added for APB. The custom HUD code was further improved (and a chunk of it was opened up in shaders.dll at this point, a decision I still regret to this day).

3.2.1 followed with more bug fixes then 3.2.2 followed with even more fixes and 3.2.3 with yet more fixes.

Scripts 3.2

Scripts 3.3 came next. In 3.3, the Control_Enable command was made to work over the network. Improvements were made to the shader code. Some font code was cloned, rewritten and improved. Support for "shader plugins" (which with the benefit of hindsight was a stupid idea) was added. The vehicle management dialog was added to let you kick people out of your vehicle. More fixes, cleanups and engine research continued as per usual. A Set_Vehicle_Gunner engine call was added. I wrote some new scripts. The normal map shader was improved (in particular fog now affected normal mapped objects). APB got some new scripts.

Then came 3.4. with more bug fixes/cleanups/engine research. A feature was added to change the default sort order for WOL servers so it sorted by player count rather than name (this took away the incentive for people to horde nicknames like aaaaaaaaaaaaa just to be first on the list). I write some more new scripts. Saberhawk added one new script and one script was written for APB.

3.4.1 followed soon after that with a bunch of bug fixes then 3.4.2 with more bug fixes, 3.4.3 with more bug fixes again then 3.4.4 (the final release of the 3.x series) came after that.

Credits

I would like to give thanks to all the people who's help in many different ways has made the scripts.dll project what it is today.

• Greg Hjelstrom
• Greg Underwood
• Aaron "Apoc" Kaufman
• Olaf Van Der Spek
• StealthEye
• Ghostshaw
• WhiteDragon
• Dblaney
• danpaul88
• Saberhawk
• Sir_Kane
• Chronojam
• NeoSaber
• Deezire
• moonsense715
• Romanov
• CCHyper
• Jerad2142 
• Triattack
• Zunnie
• YRR
• E!
• Vloktboky
• TheKGBSpy
• EvilWhiteDragon
• Mac
• Crimson
• Blazer
• v00d00
• Scorpio9a
• Reborn
• Pushwall
• Wallywood
• Dante
• Datalore
• NameHunter
• TimeFX

• GeneralCamo

• Laeubi

• ChopBam

• OWA

And of course all the people involved in producing C&C Renegade and all the C&C Renegade Mods that exist out there and in testing the scripts.dll over the many years of development and anyone else I forget who has somehow contributed in some way to getting us where we are today.

1. Summary

• Teams have to sign up for the game to play.
• When it starts, participating teams are given starting countries equally.
• The game is played by teams attacking eachother's territory, trying to take over them by winning battles ingame.
• Attacks go in turns in the order teams signed up for game. The first team attacks first, then the next one, etc.
  In short, each team in every round has a chance to conquer 1 country, while also having to defend their own ones from enemy attacks.
• The game ends when either 1 team owns all countries or the number of rounds played has reached the limit (e.g. 10) - then the team owning the most countries wins.

2. Preparations

Before the game can be played, teams need to register to play (minimum 2, maximum 5).

Currently the teams are clans. If clan leaders log in on the ranks webpage and navigate to the Conquest menu, they can register their team to play by pressing the 'Join game' button.

3. Initializing the game

After enough teams have registered, the game can be initialized by a game moderator from ingame or IRC by using the !conquest command.
This command locks the partaking teams, hands out countries to all teams equally and automatically sets the next (first) battle.
The countries from here on are colorized to display their owner.

The first battle is always an attack done by the first team that registered for the game. The system automatically picks an enemy country next to one of their own countries.

Note: the game/match/map where the game was initialized is not part of the game mode.

4. Playing the game - World map status

The game mode starts after the battle has ended on which the mode was initialized with the !conquest command.
The clan leader of the next attack has a maximum timeframe of 5 minutes after the first initialization and at the start of every battle to change which country they want to attack by clicking a flashing country on the web.
Decide fast if your team is also involved in the currently active battle!

Additionally before selecting a country to attack, clan leaders can build a Refinery or a War Factory in one of their countries in their turn. If they forgot to build one they will be able to build one more later, when their turn comes again. Refineries will grant an amount of global credits per round that can be spent to send reinforcements to other countries, besides that defenders of a country under attack will be donated 100 starting credits each one if a Refinery was previously built in that territory. There is no limit to the number of Refineries that can be built in a country and the more Refineries, the more global credits a team will get every round but the starting credits will still be limited to 100 for each player. On the other hand, the number of War Factories that can be built is limited to one and their only function is to provide reinforcements to other countries, this means that teams may call in reinforcements in a battle where one of its neighboring countries has a War Factory building.

Clan leaders must be careful where they place buildings, as loosing a country will result in loosing the buildings too, because they will turn into enemy property!

Note: picking the next country to attack is not only strategically important (choke points, locking enemy teams away, etc.) but it also decides what map exactly is going to be played. Each country has an assigned ingame map - hover over the countries to see them.

Attacking rules:

• Your team can attack a country if it is next to one your owned countries (and is not currently under attack by another team).
• You can NOT launch your attack from a country that is currently under attack! (Except if there are only 2 teams left and you only have 1 country left - but of course you will not have a chance for your next attack if you fail to defend it in the current battle)

Note: it is not a problem if the clan leader forgets to choose a country. One is always picked automatically, but this choice can be suboptimal.

5. Playing the game - Ingame

When a match starts, it is randomly decided which team will play as which game faction (e.g. Allies/Soviets, GDI/Nod, etc.).
The system checks the ingame players' team affiliation and are switched to the appropriate faction.

If the game is played in strict mode, anyone else joining the game (not affiliated with the 2 partaking teams) is forced to be a spectator. Otherwise, in non-strict mode, these players are distributed to even the teams.

Mercenaries

All of this can be changed by flagging players as mercenaries. Moderators can do this with the !merc command.
If a player is a mercenary, they will fight for the faction the moderator chose them to fight for.

Note: this is a way for someone to be hired by the enemy team for whatever reason and the only way to exit spectator status in strict mode.

Reinforcements

Clan leaders fighting for their own clan can call in reinforcements with the !reinforcements <number> ingame command (number is 1 if it is omitted), as long as they built a nearby War Factory and they have enough global credits to spend. The "number" parameter is limited by the maximum drop locations that are available for that map. Besides this command has a cooldown, this means that it can only be used once every minute and additionally, an admin may have set an extra limit for the maximum available reinforcements for each call, for the first minutes of a game since map start.

The match goes on normally, the faction/team will win by completing the game objective defined on the played map (most common victory conditions are high score or destroying the enemy base).

Effects on the map

After each battle finished, the world map is updated. If the attacker team won, they take the country. If the defenders won, they keep it and the world map does not change.

6. End of the game mode

If a team has managed to conquer all of the countries in the region, they win. Alternatively, when the amount of rounds reaches the limit (e.g. 10 or 20) - then the team that owns the highest number of countries will win. It is possible to have multiple winners when they all have the same amount of countries.

Introduction

W3D uses a form of rigid body dynamics to simulate a wide variety of vehicles.  All of the geometric characteristics of a vehicle are determined directly from a model which is exported from 3ds-max.  For example, the number, placement, and behavior of any wheels in the vehicle is determined by the set of “bones” in the model.  Many wheel configurations can be defined by the model: front-wheel drive, four-wheel steering, all-wheel drive, tank tracks, etc can all be set up.  Parameters such as the mass, engine strength, and suspension stiffness are set in Mammoth, the W3D level editor.

Vehicle Balance/Origin Bone

The first thing to do is to position your vehicle model such that its center of mass is at the origin in 3ds Max, this is usually marked by an Origin bone.  In the X-Y plane, the CM (center of mass) should usually be placed exactly at the centroid of all of the wheels in the vehicle.  If the CM behind this point, the vehicle will lean backwards on its suspension, if it is in front of this point, it will lean forward, etc.  In the Z axis, the CM should be placed some distance below the center of the object to help prevent tipping over when turning corners.

Collision Detection (WorldBox)

As is the case with all objects in W3D, you can use separate meshes for projectile collision detection and physical collision detection.  In the case of vehicles you have to use a single OBBox named "WorldBox" for physical collision detection.  (Note: physical collision detection is used when the object is moving in the world, projectile collision detection is used when the code is determining whether bullets hit the vehicle).  For projectile collision detection, just use some representative meshes from your model.  The WorldBox OBBox must be linked to the origin of the vehicle, and be aligned with the world axes.  It should also be as small as possible while still containing the wheels and bulk of the body of the vehicle.  The physics code in W3D collides with objects in a buffer zone near the surface of the worldbox so it should not completely contain the model.  Below is a screenshot of a WorldBox.  Note how the WorldBox does not extend all the way to the front, top or back of the vehicle.

WorldBox checklist

• It should be named exactly "WorldBox" (or "WorldBox.00" when part of an LOD model)
• It should only exist in the top LOD of your vehicle
• It should be set up to export as an OBBox
• It should be Hidden
• It should have its Physical and Camera collision settings enabled
• It should be the only object in the vehicle model with Physical and Camera collision enabled
• It should be as small as possible while still containing the wheel contact patches in their initial position (more on this later).

Wheels

Wheels are defined by adding bones with a particular naming convention into your model.  All vehicles, including VTOL aircraft, have wheels.  At the bare minimum, there must be two bones per wheel; one to define the contact point of the wheel and one to define the center of rotation of the wheel.  The code will use the pivot points of the wheel bones to determine the following things: the initial position of the wheel, the radius of the wheel, the axis that the suspension travels along, and the axis that the wheel rotates about.  The two basic bones needed by each wheel are the "WheelP" (wheel position) bone, and the "WheelC" (center) bone. 

Below is a view of a wheel from the Humm-Vee model (with the WheelP bone selected). Note that the z-axis points along the direction of travel of the suspension and the x-axis points forward.  Also, the pivot point of the WheelP bone must be contained inside the world-box.  The initial position of all wheels should be at their extreme topmost point; imagine that the vehicle has just fallen off a skyscraper and landed directly on its wheels.

Attached to the wheel position bone, you need a bone which defines the center of rotation of the wheel; the WheelC bone.  Below is a view of a wheel with both bones set up.  Again, the important axis is the z-axis, it points along the axis of rotation of the wheel; in the "Top" viewport in Max, the z-axis should be pointing down your monitor (for all four wheels).   

The graphical representation of the wheel is then attached to the WheelC bone and will rotate and translate as the vehicle is simulated.  The simulation pays no attention to the graphical representation of the wheel or even whether it exists or not.  The hierarchical linkage for a simple wheel should look like the one below.  Note that the WheelC bone is attached to the WheelP bone; not the other way around.

The 'E' at the end of each of the names above is a flag signifies that this particular wheel applies the engine force at its contact point.  Through this naming convention you can create four-wheel drive, front-wheel drive, or rear-wheel drive wheels.  Other flags that are available include:

• S - The wheel will turn when the vehicle changes its steering parameter.
• I - The wheel will turn in the opposite direction of the vehicle's steering parameter (rear wheel steering).
• T - Intended for tilt steering. Currently a clone of the "S" flag
• E - The wheel will exert the engine force at its contact point
• L - The wheel is part of the left track of a tracked vehicle
• R - The wheel is part of the right track of a tracked vehicle
• F - The wheel is "fake"; it will graphically move with the vehicle but no forces are computed.
• H - The wheel is a "Hover" wheel; it will ignore any surface friction and drag, and use the default values.

The complete naming convention for a wheel bone is below.  The name always starts with the word 'Wheel', followed by a single character and a two digit number (e.g. WheelP00).  Following the digits, any of the above flags can be added.

    Wheel {P,C,T,F} {00} [S] [I] [E] [L] [R] [F] [H]

Here are some examples of valid wheel bone names:

• WheelP00ES - The contact point of wheel 00 which has the engine force and steering applied to it
• WheelC05 - The rotation axis of wheel 05 which only exerts a suspension force and rolls with the vehicle

Advanced Wheel Settings

You may notice that there are two more types of wheel bones that have not been described yet.  These bones can be used to create wheels whose suspension moves in a manner more complex than simply translating along the z-axis of the WheelP bone.  First I'll show an example of a translational constraint using a WheelT bone.  This example is from the front wheel of the Nod Recon Bike:

The presence of the WheelT bone in a wheel hierarchy causes the wheel to translate along the Z-axis of the WheelT bone rather than the contact point bone.  This is used for the front tire of the Nod Recon Bike.

The rear wheel of a Recon Bike rotates along an arm.  This can be accomplished by using a WheelF bone.  Below is a picture of that situation.  The WheelF bone will be rotated about its Y-axis to maintain contact between the wheel and the ground (see the picture for how to set it up).  This is probably the most complex type of wheel to create...  Look at the Nod Recon Bike for reference.

Wheel Checklist

• Each wheel should have a bone named WheelPxx and WheelCxx (where xx is a two digit number)
• All wheel bones should have all W3D options disabled except for Export Transform
• The wheels should be positioned at their extreme topmost position (smashed into the vehicle) and their contact points must be contained inside the world box of the vehicle.
• The hierarchy should look like this:  Origin->WheelP->WheelC->Graphical Wheel
• The Z axis of all WheelP bones should point along the direction of travel of the suspension
• The X axis of all WheelP bones should point towards the front of the vehicle (direction of rolling)
• The Z axis of all WheelC bones should point along the axis of rotation of the wheel (typically down in the Top viewport)
• All wheel bones should have their flags set (append an 'E' to the wheels that are attached to the engine, append an 'S' to the wheels that steer, etc)

Turrets

Vehicles can have turrets which can fire weapons.  The turret aiming motion is generated by the game code as long as certain bones are present in the model.  There are three types of bones involved in controlling a turret.  The 'Turret' bone will be rotated to set the turret's 'heading'.  The 'Barrel' bone will be rotated to set the tilt of the weapon.  And the 'Muzzle' bone will be used as the location to create projectiles from.   Below is a picture of a the turret from the GDI Mammoth Tank:

In the above picture, you can see that there are several muzzle bones.  All of the bones follow the convention that their axes should be aligned with the world axes; Z is up, X points towards the front of the vehicle, Y points to the left of the vehicle.  If you create your boxes in the 'Top' viewport, they will be oriented in this fashion automatically.  One improvement over the linkage shown above would be to attach the V_Barrels mesh as a child of their Muzzle bones because the game engine automatically applies a recoil to the muzzle bone (attaching them in that way would cause the meshes to recoil when the weapon is fired).

Vehicles with more than a single Barrel bone

If you have a vehicle with two muzzle bones aligned side by-side and offset from the center, you can make the barrels yaw inwards to meet the target. Using the same naming convention that is used for the Muzzle bones (MuzzleA, MuzzleB etc.) you can setup barrels that behave in this way. For example, a vehicle that is setup with a BarrelA0 and a BarrelA1 bone will automatically yaw it's barrels inwards to make hitting targets a lot easier. Below is a picture of how this can be achieved, using a test model.

(Image of BarrelA0 and BarrelA1 bones in use)

Vehicles with Gatling barrels

Vehicles can support barrels that spin, in cooperation with the gatling tech in the weapon definition. To have models with these spinning parts, name the part of the weapon that you wish to spin spin_barrel_x (where x is either 0 or 1, as you can only have two.) and adjust the pivot so that the x-axis points in the direction you want the part to spin (this is normally parallel to the barrel. See the below image for an example. The blue gatling barrels are named spin_barrel_0 and have their pivot with the x axis pointing down the barrels.)

Make sure that you still have a Barrel bone, as this does not replace that. Furthermore, make sure that the weapon in use is set up as a gatling weapon! 

Turret Checklist

• The model should contain a 'Turret' bone, either a 'Barrel' bone or a BarrelA0 and BarrelA1 bone, as well as one or more muzzle bones.
  • There can be up to 26 Muzzle bone 'sets'. e.g. MuzzleA, MuzzleB, MuzzleC, all the way to MuzzleZ.
  • There can be any number of Muzzle bones per Muzzle bone sets. The number of muzzles per set does not have to be equal. e.g. You could have 2 MuzzleA bones, 4 MuzzleB bones and 1 MuzzleC bone, if you so desire.
• The bones should be connected in the hierarchy shown above.
• Visible meshes in the model should attach to the appropriate bones so that they move when the game logic controls the turret (i.e. the turret mesh should be attached to the turret bone so that it will rotate properly)
• All of the bones should have their pivot points aligned with the world axes.
• All bones should have Export Transform enabled and Export Geometry disabled.

Engine Special Effects

VTOL vehicles can control bones to display engine effects.  Here are some examples of engine effects:

• The flame on the Orca engine lengthens when the vehicle accelerates or climbs (EngineFlame)
• The Orca engine rotates forward and back as the vehicle accelerates or decelerates (EngineAngle)
• The rotors on helicopters spin when they are in flight (Rotor/RotorA/RotorB)

Any bone present in the model which starts with the name "EngineFlame" will translate along its Z-axis along with the vehicle's acceleration.  Any bone present which starts with the name "EngineAngle" will rotate about its Z-axis.  In the screenshot below, the EngineAngle bone for one of the Orca engines is selected.  Below it is the EngineFlame bone and not shown is a skin which has vertices attached to both bones and stretches as the EngineFlame translates.

Helicopter vehicles can use the EngineAngle bone to tilt their rotors as they fly forwards and backwards.  In addition, they can contain 'Rotor' bones which will spin about their Z-axis when in flight.  The parameters for how much these bones rotate and translate are all controlled through settings in the level editor.

Engine Effects Checklist

• "EngineAngle" bones will rotate about their Z axis
• "EngineFlame" bones will translate along their Z axis
• "Rotor" bones will constantly spin about their Z axis while the object is in flight
• "RotorA" bones, which are hidden when the rotor angular velocity is above or equal to the RotorBlurThreshold 
• "RotorB" bones, which start hidden and are unhidden when the angular velocity is above or equal to the RotorBlurThreshold

Aircraft Specific Effects

Aircraft have some extra bones that the game can control to give the appearance of proper flight controls. The engine can simulate the Ailerons, Elevators and Rudders of a plane.

The ailerons control roll, elevators control pitch up and down and the rudder controls yaw left and right. 

This image shows a full set of flight control surfaces in 3ds Max (Ailerons in green, rudders in red, elevator in blue). Ailerons rotate around the Y-axis, elevators also rotate around the Y-axis and the rudders rotate around the Z-axis. You can have up to six ailerons, six elevators and six rudders per vehicle.

Vehicle Damage

As a vehicle becomes damaged, the game code can un-hide particular bones in your model.  This can be used to show damage by attaching emitters to those bones since emitters in the model will start emitting when the bone they are attached to becomes un-hidden.   There is support for three stages of damage, activated when the model reaches 25%, 50%, and 75% damage.  When the model loses 25% of its health, all bones whose names begin with DAMAGE25 will be un-hidden.  Once the object has lost 50% of its health, all bones whose names begin with DAMAGE50 will also become un-hidden.  And when it has lost 75%, the DAMAGE75 bones will un-hide. 

Inverse Kinematics

Vehicles can have a simple inverse kinematic system, with a maximum of 4 pairs of bones. This can be used for hydraulic systems on vehicle turrets, recoil hydraulic absorbers, etc. The system will rotate the two bones along their Y-axis so that they will always point at each other along their X-Axis. To set this up, have two bones, with the same root name and either IK0 or IK1 at the end. For example, in the below image, the two selected bones are named hyd_ik0 and hyd_ik1. They face each other along the X-Axis (the red arrow) and they rotate along the Y-axis (which points out of the screen in this side on view). These bones can't be parented to each other, but they can be parented to objects in the scene. For example, in the image, the top IK bone is parented to a barrel bone and the bottom IK bone is parented to the chassis, This will allow the hydraulics in the model slide in and out properly as the barrel pitches up and down.

Physics Parameters

All of the actual physics parameters are controlled through the Mammoth level editor.  When creating a vehicle, the first thing you have to do is choose the physics model that it will use.  There are five main physics models for vehicles: WheeledVehicle, TrackedVehicle, Motorcycle, VTOLVehicle and AircraftPhys. 

Parameters common to all vehicles

• Mass - the mass of the vehicle
• GravScale - a scale factor that is applied to the gravitational force on the vehicle. This is set to 2.25 for most vehicles.
• Elasticity - not currently used.
• AerodynamicDragCoefficient - controls the amount of drag.
• Spring Constant - spring constant for the suspension (even VTOL vehicles have a suspension)
• Damping Constant - damping in the suspension springs
• Spring Length - suspension length, wheels start at their initial position and can translate down this far
• Traction Multiplier - scales the amount of traction available to the vehicle
• Lateral Moment Arm - length of the rotational moment arm for lateral forces at the tire contact patches.  this lets us fake the lean of the vehicle when turning without having to adjust the W3D model.
• TractiveMoment Arm - length of the rotational moment arm for tractive forces at the tire contact patches.  This lets us control how much the vehicle "dives" when it brakes and how much it leans back when accelerating.
• EngineFlameLength - if the vehicle has an "EngineFlame" bone, this controls how far that bone will translate.  Since this parameter is available to all vehicles (not just the Orca), we could create things like Recon Bikes and cars that have a flame emitting out of their engine.

Parameters specific to ground vehicles

• MaxEngineTorque - this is the torque that the engine can output.  For tracked vehicles we don't have a sophisticated engine simulation; this torque is simply divided between the wheels and applied (also scaled by user input)
• EngineTorqueCurveFilename - this is the engine torque curve (relates torque to engine RPM).  These curves are created with the "SimpleGraph" tool
• Gear Count - number of gears in the transimission
• GearRatio[0-6] - transmission gear ratios
• FinalDriveGearRaio - gear ratio in the differential
• DriveTrainInertia - inertia in the drive train components
• ShiftUpRpms - point at which the code shifts into a higher gear
• ShiftDownRpms - point at which the code shifts down to a lower gear
• MaxSteeringAngle - maximum angle of the steering tires
• LeanK0 - internal torsional spring constant for motorcycle "balancing"
• LeanK1 - internal torsional damping constant for motorcycle "balancing"

Parameters specific to VTOL (Vertical Take-Off and Landing) vehicles

• MaxHorizontalAcceleration - acceleration of the vehicle in the X-Y plane
• MaxVerticalAcceleration - acceleration of the vehicle along the Z axis
• MaxFuselagePitch - angle that the vehicle pitches when acclerating forward
• MaxFuselageRoll - angle that the vehicle rolls when strafing or turning
• PitchControllerGain - spring constant for the pitch controller
• PitchControllerDamping - damping constant for the pitch controller
• RollControllerGain - spring constant for the roll controller
• RollControllerDamping - damping constant for the roll controller
• MaxYawVelocity - how fast the vehicle can spin
• YawControllerGain - how fast the vehicle reaches its MaxYawVelocity
• RotorSpeed - how fast the 'ROTOR' bones should spin
• RotorAcceleration - acceleration of the 'ROTOR' bones
• RotorDeceleration - deceleration of the 'ROTOR' bones
• RotorBlurThreshold - determines the angular velocity at which RotorA/B bones are swapped. 

Parameters specific to Aircraft

Menu options

File

Edit

Sound

Objects

View

Pathfinding

Lighting

Tools

Presets

Strings

Object manipulation

Selection

• Clicking on an object in the window with the left mouse button will select that object and deselect any currently selected objects.
• Ctrl+click will add that object to the currently selected objects or remove it if its already selected.
• Alt+Click will create a clone/duplicate of the currently selected object(s) at the position of the original(s) (the mouse has to be above one of the selected object(s). If nothing was selected, the object the mouse is above will be cloned.

Edit

• Pressing the delete key will delete the currently selected objects.
• Double clicking on an object in the window with the left mouse button will open the object edit dialog for that object.

Move

• Moving the mouse while holding down the left mouse button will move the currently selected objects. If you hold down the Shift key it will move in the Z axis otherwise it moves in the X and Y axis. If the Lock To Axis menu options are enabled, movement is restricted to that axis.
• Pressing the left, right, up or down arrow keys will move the currently selected object(s) in the x and y axis. Holding Shift will make the up and down arrow keys move the object in the z axis. These movement keys are not affected by the "lock to axis" menu options.

Rotate

• Holding Ctrl and pressing the 8 and 2 keys on the keypad will rotate the currently selected objects around the x axis. Holding the 0 key on the keypad will increase the speed (but note that the speed set by the + and - keys has no effect on the speed used in this case).
• Holding Ctrl and pressing the 9 and 7 keys on the keypad will rotate the currently selected objects around the y axis. Holding the 0 key on the keypad will increase the speed (but note that the speed set by the + and - keys has no effect on the speed used in this case).
• Holding Ctrl and pressing the 6 and 4 keys on the keypad will rotate the currently selected objects around the z axis. Holding the 0 key on the keypad will increase the speed (but note that the speed set by the + and - keys has no effect on the speed used in this case).
• Holding Ctrl and pressing the 5 key on the keypad will reset the rotation of the currently selected objects.

Script zone sizing

• If a Script Zone or Damage Zone object is selected, holding Ctrl and pressing the left, right, up or down arrow keys will resize the zone in the x and y axis. Holding Shift will make the up and down arrow keys resize the zone in the z axis. Holding the 0 key on the keypad will increase the speed (but note that the speed set by the + and - keys has no effect on the speed used in this case).

Camera movement

Mouse

• Pressing the middle mouse button (normally the mouse wheel on a wheel mouse) and moving the mouse will pan the level left/right/up/down.
• Pressing the right mouse button and moving the mouse will rotate the level up/down/left/right about the current camera position.
• Scrolling the mouse wheel will move the camera into and out of the level.
• Special mouses: using your mouse button 4/5 will rotate around an object/terrain in the center of the screen. Using the alternative ALT key before clicking will center around an object. If no object is found, it will rotate around a point 40 units in front of the camera.

Numpad

• Holding 0 on the keypad will increase the movement speed of the camera and object movement keys mentioned below. Holding Ctrl and pressing the + or - keys on the keypad will increase or decrease the speed used for this feature.
• Pressing 8 or 2 on the keypad will move the camera into and out of the level.
• Turning on the Caps Lock and pressing 8 or 2 on the keypad will move the camera forward and back along the xy plane.
• Pressing 9 or 3 on the keypad will rotate the camera up and down.
• Pressing 4 or 6 on the keypad will rotate the camera left and right.
• Holding alt and pressing 4 or 6 on the keypad will pan the camera left and right.
• Pressing 7 or 1 on the keypad will pan the camera up and down.
• Pressing 5 on the keypad will centre the camera

WASD keys

• Holding SHIFT on the keypad will increase the movement speed of the camera when using WASD keys.
• Pressing A or D will pan the camera left and right
• Pressing W or S will move the camera into and out of the level.
• Turning on the Caps Lock and pressing W or S on the keypad will move the camera forward and back along the xy plane.

TBD

Swimming

Weapons are one of the key parts of the engine. Without weapons you can't shoot things. Weapons here aren't just limited to infantry carried weapons, vehicles also use these too.