What changes did you make ?
Note - if you need to make changes to the 'configure' or 'make' scripts, you must modify the 'configure.am' or 'make.am' (auto-make) 'masters' = otherwise your changes will be lost when the script is next 're-built'
Display size
Crimson Field's hex 'tile' size may be fine for a 'smart phone' but a real pain on a modern PC screen (which are all bigger than 640x480 :-) ). So the first thing I did was to 'zoom' the tile & unit size by x2 to better suit modern computer displays (see below for details)
The tile and unit artwork (.bmp source) can be 'magnified' to 200% using any photo-edit package, however the units really need to be re-worked to improve their appearance (note that bmp colour palette index '0' is used as 'transparent')
To fit with the new playing size, I adjusted the default CoMET edit window size (from 816 x 630 ???) to 1280x1024
SDL 'adds' borders and control 'bars' in different sizes depending on the 'requested' window size. To fit exactly onto a 1280 x 1024 screen you 'ask' SDL for a 1274 x 999 window :-)
Changing the 'zoom' setting
First, the tiles and units .bmp (artwork) files were 'zoomed' to 200% using a photo-edit package (PaintShop Pro) and re-saved
Next, in lset.h, I changed the DEFAULT_TILE_WIDTH from 32 to 64 and the DEFAULT_TILE_HEIGHT from 28 to 56. In the same file, the 2nd column offsets = TileShiftX & TileShiftY have to be changed from 9 to 18 and 14 to 28.
Both Crimson.exe and CoMet.exe automatically picked up the larger tiles & unit icons. The only thing that is not quite correct is the unit height spacing in the (building / transport) 'contents' pop-up frame. The problem is that the unit 'icon' is ASSUMED to be the same height as the other icons in the frame. Whilst it is possible to change 'icon height' in gamedefs.h, this then breaks the 'test' for how many will 'fit' in the unit list before scrolling is required AND breaks the mouse 'select' of the unit icon (which is, apparently, also based on assumptions of 32). Every time I found another 'assumption' (and fixed it) something else 'broke', so I ended up leaving the 'contents' code alone (even with the larger unit icons 'overlapping' it's still usable)
The default window size for CoMET is found in src\comet\main.cpp (opts.width & opts.height at lines 95/94), however if a cfed.ini file exists (in My Documents/crimson/) the resolution defined there will be used instead (this will be "800x600", if you ran CoMET before making changes to the opts.w/h default:-) )
CoMET has no UI to change the display window, so to change it's display size, you 'hand edit' the /My Documents/crimson/cfed.ini file
NOTE To obtain an actual window of 1280 x 1024, you have to set the 'default' size to 1274 (opts.width) x 999 (opts.height) = these are the values that will appear in cfed.ini when the actual window size is 1280x1024 :-)
In crimson.exe, a map 27 tiles wide by 17 rows high fits 'exactly' into a 1280 x 1024 pixel window.
The 'next step' would be to allow user control of x1 or x2 zoom. This will require adding back the original tile & unit set and modifying the game code to add a 'button' to switch between the sets (to avoid language issues, I plan to use the '+' key to switch between zoom settings)
Todays Tablets may have fewer pixels ('half HD' is not uncommon - i.e. 1024x720) but they are also much smaller (typ 7") than the typical desktop (at least 17", typ 21"+). Crimson is virtually unplayable on such devices (unless zoomed up) as the HEX's are too small even for a stylus to select reliably
New Tile 'icons'
For full details see my New Tiles page
One of the first things I did was to 'rework' the building icons (as already suggested in my previous Terrain Tile definitions page and detailed in my New Units page, Next)
I also wanted some 'decent' beaches = you can't "Fight them on the beaches" unless you actually have some beach terrain tiles :-) I also wanted some 'desert sand' terrain tiles
Reworking the existing 'single hex side river banks' (replacing grass with sand) allowed these 6 tiles to be multi-used for 'beach' and 'desert river banks' as well. Even so, I was forced to add one extra row 9of 24 tiles) to the CFTiles.bmp file
Using some of the spare (undefined) tiles positions I added some 'pontoon' tiles (see later re: 'Using Events' = converting a 'pontoon unit' to a 'pontoon tile') and some additional 'house' tiles. After adding these, I was left with one 'spare' position in the 'default' set which I used for an extra 'rocks' tile
New Tile 'types'
Whilst classifying the new tiles, I noted that there was no 'hills' type definition - further I noted that various 'barricade' tiles (tank traps, walls) were classed as 'rough' ? Looking into the source code for the tile 'generation' tool revealed that the 'rough' type was being classed as 'barricade'. I thus decided to re-instate barricade as a type and create 2 new types, rough and hills (see next page for details)
Modified Units
I immediately changed many of the unit 'characteristics' to address some of the multiple inconsistencies incorporated into the 'standard' unit set
All aircraft had their move distance increased (some up to double) to reflect the fact that, in any 'real world', aircraft are always (much) faster than trains (and all other 'ground' units).Next, the 'Anti-Aircraft Guns' were renamed AA Missile Battery (the AA Tanks doing a perfectly good job as 'guns').Troop Trains were given a 'medic' capability (which means they are allowed to repair the units being carriedThe final 'tweak' to the existing units was to rename 'Mines' (and rework the icon) into a sort of automated 'defense gun' and give them an 'attack' power (which made them a bit more useful than the 'floating rock' functionality they started with :-) )
Note every change of unit 'name' required a 'search & replace' on all the combat maps (*.src fields in \levels\ folder). See also below, new unit type, for AA missile to be carried by the Missile Battery (which was changed into a 'transporter' type)
New units
For full details see my New Units page
Whilst Battle Isle was 'promoted' as a 'future war' game, there were no missiles ! So, of course, Crimson Fields suffers from the same limitations
Rockets would always be invented and used as a weapon well before more powerful gunpowder and metal working techniques allowed any type of 'gun' to be built. Since Missiles are simply 'guided rockets', it is inconceivable that any 'modern' or 'future' civilisation would lack access to such basic weapons.
'Explaining away' lack of missiles with some 'hand waving' pseudo-scientific explanations (eg 'super effecting jamming', 'E.M.P. / atmospheric electro-magnetic interference**', 'cloaking devices' etc) fails to explain how artillery and tanks are able to acquire their targets, not to mention the fact that the easiest 'sensor' to fool is the human eye - any simple camouflage / smoke screen blocks direct vision as does fighting at night - so if you have Infantry they must have access to radar, IR and night vision equipment at the very least.
**whilst an E.M.P. 'gun' or other 'electro-magnetic interference' might be used to 'explain' the non-availability of semi-conductor based computer systems, all usable WW2 missile systems were developed well before the invention of the first 'point contact' germanium transistor in 1947. During the 10 years it took before silicone based transistors became available (1954) let alone the first 'integrated circuit' (1960) many guided missile systems were developed (and used) based on vacuum tube technology.
Even if it is accepted that 'magic'** prohibits any sort of workable 'guidance' system, this would not stop 'unguided' rockets being deployed as short and 'medium' range weapons (see WW2 'bazooka' / 'panzerfaust' anti-tank weapons and the Katyusha / Nebelwerfer 'artillery' rocket systems), although it's to be admitted that unguided long range rockets (such as the WW2 German V2) are virtually useless against targets smaller than a city
** Jamming (or EM pulses) sufficient to disrupt (shielded) vacuum tube based systems wouldn't prevent the use of mechanically linked 'live guidance' (as the Allies discovered with the 'Kamikaze' of WW2). In fact, you don't need human suicide pilots to guide your missiles - birds will do just as well (see the Pigeon guided missile), and, no doubt a dolphin (or squid) guided torpedo would be even simpler (see Military use of dolphins).
Another glaring omission is the lack of many standard support units.
Whilst it might be argued that in a limited battle some standard support units might be unavailable, as noted already, no sane commander would deploy an Aircraft Carrier with only Patrol Boats and Torpedo Boats as 'supports', especially when the opposition is known to possess Submarines !
I thus 'downgraded' the 'Aircraft Carrier' to 'Assault Carrier', but I still couldn't convince myself that anyone would deploy such a unit unsupported = so I added the Guided Missile Cruiser, ASW Frigate and Mine Sweeper
To support (and oppose) amphibious operations, I added Landing Craft, Coastal Defense Battery and Bunker. I also created 'mined anti-tank defences' as a unit (which allows them to be 'cleared' i.e destroyed, unlike the terrain tile anti-tank barriers)
To support units in the field, I added Transport Helicopters, a Mobile Workshop and a Bridge laying transport (plus a Pontoon Bridge as a 'deployable' = 'mine' type unit)
I decided that adding further 'logistics' units (ammunition carrier etc) was a 'step too far', however I did modify the unit 'weights' to control what the various 'transport' units are allowed to carry (see later, especially 'Controlling Missiles')
To 'round out' the land units, I added a Light Anti-Tank Gun and the Self-Propelled Gun
Four missiles were added :- A-A Missile, SAM Missile, Cruise Missile and (anti-tank) Rocket. To support the SAM site (see below), I added a Radar Control unit. Submarines were redefined as 'transporters' and Torpedo added as a 5th missile type (with a 'weight' that allowed it to be carried by Torpedo Boats & Bombers)
Helicopter Gunships and Infantry were also defined as 'transporters' and allowed to carry Rockets. The only 'clever' bit is to make Cruise Missiles and Rockets type=ground (so they can be destroyed after impacting a unit with power(ground) but no power(air)). Torpedoes, of course, are type=ship and have a power(ship) only.
How to use Rockets & Missiles ?
Limiting units use of missiles
To ensure Bombers could 'drop' Mines & launch Torpedoes & Cruise Missiles - but not AA missiles - whilst Fighters & the AA Missile Battery both used short range AA missiles (only), whilst Interceptors & SAM Site both had the choice of mixing long & short range AA Missiles, required a lot of 'playing around' with all the unit 'weights' (since 'minweight' and 'maxweight' is used to control all the 'transporter' types, not just those already mentioned). I thus created a spreadsheet of my current Unit definitions(right click and 'save link as' to download the .xls from here)
To avoid Transports becoming 'armed' with missiles means that any units they carry will be without their 'own' missiles. In particular, this means Infantry and Scouts would have to leave their anti-tank Rockets behind when taking Air or Sea Transport.Since this effected the 'scenarios' rather too much, I (reluctantly) allowed Air & Sea Transport (including Landing Craft but not Hovercraft) to carry Rockets (and trust that those creating their own maps won't abuse this too much)
Missiles in combat
The main problem with my Missiles is that they are 'just normal units' = so they can keep 'flying for ever' and must be 'attacked' and destroyed like any other normal unit :-)
My (partial) solution is to give them 'no'** defence ("armour = 1"), which then allows 'anything with an AA capability' to 'shoot them down' & more or less guarantees they won't survive the first 'combat'. This means, of course, that every missile 'target' must have some 'power' against the missile type (otherwise the missiles will 'survive' the 'combat')
**Unfortunately, if you actually set "armour=0" (or .1) Crimson.exe "crashes" as soon as the missile is in 'combat' (a value of -1 does not cause a 'crash' but makes them 'invulnerable' instead :-) ).At a guess, the combat code contains a 'divide by armour' (so when armour = 0 you get an unexpected overflow 'exception error' and the .exe crashes). This should be found and 'trapped', however, so far, I have not managed to track down the actual code responsibleI also tried setting "size=1" in the units definition file (units.src) for Missiles. This has no effect = all units get an initial size=6 when 'deployed' or when built. It is possible to set the size in the {level}.src map file 'by hand', however this would only 'work' if you never allowed factories to build new Missiles. This, of course, should also be fixed.Finally, I tried defining a new 'type' = 'missile' (in addition to the standard 'ground', 'aircraft', 'ship') so that everything can be given a 'power(missile)=99'). Unfortunately, this also failed ('mkunitset' errors out during the .usrc 'make'). This would be the 'ideal' solution to ensuring missiles are 'single use', however I suspect that 'fixing' the mkunitset code would simply 'move' the failure point elsewhere (such as the obviously 'broken' combat code that's unable to cope with 'armour=0')
Since 'everything' can shoot at missiles, this (hopefully) means Missiles will get shot down before players realise that to 're-arm' an AA Battery all they have to do is fly their own Missiles 'into' them (since the Battery is just a 'transporter' :-) )
Currently, there is nothing to stop Missiles being 'launched' from deep within your own lines & then sent flying around in circles for half a dozen turns before finally attacking an enemy 'target'.
Whilst this is fine for Cruise Missiles, it's not so clever for Rockets & AA missiles :-)The only real solution is to find a way for missiles to be automatically 'destroyed' at the end of the turn after launch ... this could be done, for example, by modifying the 'after combat clean up code' so that, when it removes all units reduced to a strength of 0, it also removes those with 'armour' 0
The ideal (future goal) is to assign a 'life time' to missiles, so that Rockets and short range missiles can be 'eliminated' after 1 or 2 turns and Long Range missiles last a bit longer
Missile sites
These are based on a 'factory' type terrain tile linked to a 'Radar' unit using the Event system (see my Using Events page)
Essentially, the 'factory' builds (from 'crystal' resources, delivered eg. by transport units) and 'launches' Missiles. A 'Missile Control Radar' unit (with a move = 0), which can be attacked & destroyed, is placed on the tile. An 'Event' is then setup to 'monitor' the Radar unit's existence .. when the Radar unit is destroyed, the Event is triggered and replaces the Missile 'factory' tile with the 'destroyed site' (actually, the 'bomb crater' trench tile #167 was initially used).
I wished to avoid 'upsetting' the tile definition sequence, so I decided to 're-use' the 'bunker' tile icons (called 'city' in the .tsrc definitions). This gave me a Missile Site in each player colour (note - in most maps, 'blue' units start in the North, brown in the South = so blues Missile Site 'points' south whilst browns 'points' north). The 'neutral city' tile can then become the 'destroyed site' tile
After the 'Missile Control Radar' unit is destroyed, unless the Event script removes it, the Missile Site 'building' remains 'under the wreckage' and can be 'captured'.To allow 'repair' it is only necessary to allow the site to build a Control Radar Unit (getting it to 'deploy' is another problem)
How to create (totally) new unit artwork
I start by 'painting' the 'brown' player unit in North facing orientation on a 'transparent background' (= .bmp palette no. 0 = RGB 210,2,242) hex (64w x 56h pixels ... but watch out for the hex 'corners' !)
Since most units are laterally symmetrical, IN THEORY it is only necessary to create 'one half' of the 'N' facing master unit - 'mirror' then gives you the other half :-)
For REALLY GOOD unit artwork, you should 're-paint' each 'facing' with appropriate 'shadow' effects etc. - however the unit will still look quite acceptable if you generate the 'South' facing version by simply 'flipping' the North icon artwork by 180 degrees
The other 4 'facings' can be generated after a 60 degree rotate (with perhaps a bit of a 'tidy-up' to smooth out some of the jaggies generated by the rotate) and then using combinations of 'mirror' and 'flip'.
To create the 'blue' army colour units from 'brown' artwork, just copy the 6 'brown' icons & then in your photo-edit software, use 'Colour', 'Adjust', 'HSL (Hue Saturation Lightness)' and select "-50% Hue"
Click "Next >>" (nav bar, left) for a look at my new combat Units