The FX editor is pretty rough, but for those with the desire to experiment, here it is!
https://www.dropbox.com/s/koc3bh3bqtbc5im/BA_ParticleTool001.rar
- you'll need to set up the PATHS.TXT file to point to the appropriate unit models and textures. Only the first 2 are used. - any FX textures need to be in the same folder as the tool. - it seems to crash sometimes on exit, esp if you cancel saving or loading the FX file. - it's lacking some animation control for existing units, I assume Richard works on them without animations initially.
There are a couple of readmes, a simple one from me and a more detailed one from Richard.
My suggestion for trying it out would be to load up the CORE/ANIM/BANG.FXF file and then the CORE/ANIM/BANG.S4F mesh. This (if the CORE texturepage textures are in the tool folder) should show you some of the various explosion effects. I have also included a couple of files which Richard suggested too.
Note that any custom FX will need to be attached to custom animations in the local ANIM folder (as per airstrikes, etc in the main game data). That said, the game will try and load EXPLOSIONS.FXF from the root of a custom campaign before loading the main FX file from the core game data.
While the iPad can run any mod from the desktop version of the game, it can suffer from the textures being in the incorrect format for the platform. To improve user experiences of your mod on iPad, you could package up iPad format textures in your mod and they will be used rather than the desktop format TGA or DDS files. To do this, grab the tools from the following link (these are PC tools, but the readme includes details of where to get OSX versions of the tools as well).
As always, we are happy to answer any questions in the modding forums.
You can now provide a callback to further reduce the tiles shown as being “moveable” to in the UI.
// return 1 to show this tile as being valid, zero otherwise FUNCTION MOVE_SHOW_TILE_CALLBACK(me, tilex, tiley)
Note that this function is not called on all tiles on the map, it is only called on tiles which have already passed the standard AP test that already happens as part of the process of marking tiles. Also note that this does NOT prevent movement to the tile, so the logic for movement and for marking the tile as moveable in the callback must be consistent.
It is possible to manage multi-turret units. Note that this functionality is not supported for 2D units, nor will it work correctly for units with more than a single man.
To tell the game that a model has more than one turret, you need to name the “first” turret as _1Turret00_XX. All subsequence turrets must have the form _1Turret01, _1Turret02, etc. The maximum number of turrets supported is 16, so the max valid turret index is _1Turret15.
If a unit has an attribute named SYSTEM_TURRETMASK then the bits in this value will be used to determine the behaviour of the turrets. If a bit is set, then the corresponding turret will follow the desired turret facing. Otherwise the turrets will remain stationary.
The INIT_ unit creation callback is the best place to add the SYSTEM_TURRETMASK attrib if desired.
It is now possible to show literal strings using AddVizUnitText. Simply add a $ prefix character to the string (the $ will not be shown). Note that there is a hard limit of 127 characters, and that floating text is always single line, so strings should be kept short.
//build a set of all the tiles touched by a line from the center of tile x0,y0 to tile x1,y1 into the CheckRoute array BuildTileLine(x0, y0, x1, y1)
This function will build a set of all the tiles touched by a line running between the two denoted tiles. This tile set can be accessed using the GetCheckRoute* functions. This allows, for example, LOS-type checks against units or other tile attributes.
It is now possible to have more than one terrain type which behaves as water. This change is coupled with the ability to alter the colour of a water tile. As before, any terrain type named Water will be water, but the is a new terrain tag WATERCOLOUR which, if set, will denote the terrain as also being water.
WATERCOLOUR should be a hex value denoting a colour which will be modulated with the normal water display. So a value of FF808080 will give water which is 50% darker than normal. Note that the alpha value has no effect.
In multiplayer games it is critical that turns play out identically on each machine. While you can (e.g.) show UI to one side only, it is important that nothing is done to alter what happens to the game model. To allow more flexibility in what can be done in multiplayer, we have added a new script command as described below.
AddCustomOrder(function, [param,...]) // adds an order to call a fn in the scenario script. params must in the correct order for the function call. String params are NOT supported, only numeric values.
basically it adds in a call to an order which will then be executed at the same time on both machines in an MP game. So (as an example) you can do the following (psuedocode).
1. show some UI for only one side
if( GetShowSide() == 0 )
{
ShowMyCustomUIStuff() ;
}
2. once you have gotten any information you want from the UI, you then add in the custom order, which will call a function in your scenario script to do the actual work [i.e. you still should NEVER affect the world in any way in the UI, you just collect values from the UI, and then everything to affect the game needs to happen in the scenario script function which you call]
AddCustomOrder( "MyCustomOrderFunction", param0, param1, 78, 0) ;
3. define the function in your scenario file and it will be called at the same point on both machines (note, works in single player too). Obviously the function itself needs to execute the same on both machines, or be MP safe :) Remember you can use any function so long as it is included in the scenario file.
FUNCTION MyCustomOrderFunction( something, somethingelse, more, less)
{
// do actions to the world here
}
This scenario script callback, if found, can return a points value which is used on the Force Selection screen, overriding the value from the map. This allows for dynamic force points allocation.
The form of the function is:
FUNCTION FORCE_POINTS_CALLBACK(side, points)
note that returning a negative value will tell the game to keep using the map value.
New function GetWinner will return the winning side of the current battle, or -1 if the battle is still unresolved.
//returns the winning side or -1 if the battle has not ended GetWinner()