Matrix Games Forums

Some stuff cropped up on the main forum, and I thought it would be of interest on a “scenario design” sub-forum.

The thread is herwins tm.asp?m=1864845

The operative text is:

The code looks for some specific mines, in certain combat routines. These mines are presumed to be in their assigned slot locations. If things were moved around to different slots in the device file, it might be the cause of some of this instability.

Another source of instability might be the nationality designations for both the Thais and the (selected/designated/identified/chosen/whatever) mines.

There are different minefield entry, exit, clearing, attack routines, that differ also with respect to the kind of TF doing the entering, exiting, etc.. So issues may appear in one form, but not in another.

You might want to check and make sure your “basic” mines (those called out in stock) are in the same device file slot locations as they are in the stock scenarios. You might also want to check and make sure your Thai Navy units are identified as belonging to either IJA or IJN (nationality type 01 and 02 respectively) in both the ship and class files.

And:

There are many devices that are slot specific; many are well known – Ohka, A-Bomb, Zero (for the bonus), Engineers, Eng Vehicles, Support, Mech Support, etc..

There are also many other devices that are defined in terms of slot specificity and are called out as such in certain of the combat routines. These include certain aerial ordnance, certain AA guns, certain depth charges, certain torpedoes, certain mines, and other things as well, the list goes on and it is not possible to provide it.

Without warranty, and without verifying that other things aren’t effected as well, the important thing for a modder, is to insure that, at least, the weapon placement for aircraft ordnance, AA MGs up to & including 40mm, depth charges, torpedoes, and mines in the original, stock device database structure should remain sacrosanct. Lots of open empty slots for additions, but rearrangement will certainly introduce instability, unless you are very, very lucky and don’t move a ‘defined’ device. Squads and other land thingies aren’t an issue (except for the Eng, Sup, … stuff that everybody knows about anyway).

Many devices have a nationality component associated therewith (i.e., only US A-Bombs, for example). So if an allied weapon turns up in a designated Japanese slot, all sorts of fun things can happen.

Nationality is also very important. There are only the stock defined nationalities. Entering an undefined nationality in a non-op nationality ‘type’ field looks good in the editor and the OOB list, but is unrecognized by the engine, so the engine can essentially ‘pick’ which side the undefined units are on; so Thailand better be Japanese, or again all sorts of fun things can happen.

Long ago Andrew Brown and I - independently but simultaneousy - came to the conclusion that stock slots should be used for everything except for cause. This was verified by Matrix. So we backfitted CHS and RHS to stock slots in most respects. This did result in not only increased stability but also increased program execution speed.

You CAN change stock slots - but you need to know what you are doing - either because you have firm information from Matrix or because you have done proper testing. There are more than a few cases where we have achieved some purpose by swapping slots - but it is always "for cause" - deliberately - to get the effects of the code in that slot where we want it. Thus - there is one identified slot which tends to retain supplies instead of sharing almost all with other land units in the hex. This slot is used by a base force at PH in stock. I use it for a CD unit on Bataan which tends to lose its guns when starved - although IRL the guns survived until the end.

You can NOT use the undefined "nations." [The term nation is a misnomer IMHO - it should be called "service" because it has things like IJN, IJA, USN, USMC and US Army] These are only "hooks" - and if something so defined is called - there is a 100 per cent chance the game will crash. However, you can change the 'nation' assignment of a unit - and it is stable - provided you WANT the effects you get. For example, Duch and Philippine "nations" don't respawn. There is also a combat modifier associated with a "nation" - and when you want a perfectly awful one this is a good way to get it. Many of the comments above would be more correct if they said that devices were associated with a "side". While it is perfectly true that atomic bombs are associated with a "service" (or nation) - most devices are not so specifically associated - and any service of teh same side can use most of them.

The watchword is - test. Be guided by what it says in the manual - and what programmers say - but don't assume either is right: programs don't ever do entirely what is intended (see the behavior of code when you start a scenario as Russian Active) - and this program has been changed many times - but never properly documented. No one has a perfect understanding of it. One Matrix programmer said he thought he understood a major combat system - until he found a branch which "changed everything" - after a year of looking at code. So - use what is said as a starting point - then test, test and test some more.

It is amazing what you can do - if you are creative. But not everything you try is going to work.