{7, 0, 100} I'm guessing that first number is default value, while the other 2 are min/max values allowed.
I have it set up like this:

MIN_DELAY_ENEMY_REINFORCEMENTS = 0
RND_DELAY_ENEMY_REINFORCEMENTS = 0
MIN_ENTER_ENEMY_REINFORCEMENTS = 64
RND_ENTER_ENEMY_REINFORCEMENTS = 64
MIN_DELAY_MILITIA_REINFORCEMENTS = 0
RND_DELAY_MILITIA_REINFORCEMENTS = 0
MIN_ENTER_MILITIA_REINFORCEMENTS = 64
RND_ENTER_MILITIA_REINFORCEMENTS = 64

When I used this value reinforcements came as they used to, as soon as they were called. It was counterattack event in Chitzena so about 96 enemies appeared and no stealth since it was day attack.

I'm guessing the problem is that default values are 7 turns min delay for enemy forces and 8 turns added random value to that so it can take up to 15 turns for enemy forces to appear. Similar for for militia where min is 10 and and adds random 10 value which can make them come after 20 turns.

If you set gGameExternalOptions.sMinDelayEnemyReinforcements = iniReader.ReadInteger("Strategic Gameplay Settings", "MIN_DELAY_ENEMY_REINFORCEMENTS", 0, 0, 100
and
gGameExternalOptions.sMinDelayMilitiaReinforcements = iniReader.ReadInteger("Strategic Gameplay Settings", "MIN_DELAY_MILITIA_REINFORCEMENTS", 0, 0, 100)
it should work as it used to in vanilla.

Btw, values of 7 or even 10 turns min delay are a bit excessive since by that time most of the fights are almost resolved. Kindda think it's best to have them set as they are in vanilla and have modders and players play with them.

I want to commit my changes regard of reinforcement delay to ja2_settings.ini , but see that Data and Data-1.13 directory contains different ini files.

Is there particular reason why they differs? vfs will still take those from Data-1.13, so does Data-1.13 contains valid ones or I need to separately add changes to both?

Kriplo

I want to commit my changes regard of reinforcement delay to ja2_settings.ini , but see that Data and Data-1.13 directory contains different ini files.

Is there particular reason why they differs? vfs will still take those from Data-1.13, so does Data-1.13 contains valid ones or I need to separately add changes to both?

I think data is there for true vanilla to still be played.

Yes, prone position is far better then original but still looks occupy to much space comparing to standing.

Maybe we should just standing stance translate to prone as if you lay down you not suddenly became bigger neither taller.
Yes, at screen we see guys almost big as house, but that's just for esthetic's, we need to think of real physics how to translate body to those cubes which actually get hits not pixels on screen
And no matter how many hit locations put on JSD will never see that on screen but will feel when bullets start flying Those files just represent physical interaction, like could you pass through or not, how solid they are...

anyway, I will fix that but need to know was an idea of v.1.13 to calculate turning or not?
From my point of view seems logical to add turning cost for grenades?

The problem is that the structures should somehow reflect what we see on the screen. If the player sees the bullet fly into the target and gets a "miss" he will be pissed.

I have seen the opposite in the past. It looked like my bullet missed a prone target but it was counted as "hit". That didn't feel right and it was probably because of the large structure size. Now that I made it smaller I'm going to play with it and see if it works better. It should...

I think that if you have to turn it should cost more AP than if you are already facing the target.

Vanilla?!? ROFL
does work that stuff anymore, does anybody test it? even v1.13 is in quite mess, maybe problem is number 13, maybe will get less bugs if rename it to 14 :whistle:

• Vanilla JA2 with core 1.13 fixes and externalizations, but no additional features turned on by default and no new stuff like new mercs. It will take files from only Data folder
• 1.13 JA2 - what "everyone" plays
• Vanilla UB
• 1.13 UB

JSD for persons contains 8 items for 8 directions, and they goes clockwise starting with person who facing north (N,NE,E,SE,S,SW,W,NW)

Vanilla?!? ROFL
does work that stuff anymore, does anybody test it? even v1.13 is in quite mess, maybe problem is number 13, maybe will get less bugs if rename it to 14 :whistle:

@pheloncab
Could you describe a little bit this impossible range, how they occur, where they occur, what estimated range was, maybe even type of grenade, are you sure it was throwing stance not launching from GL?

So I assume it goes (W,NW,N,NE,E,SE,S,SW) and the JSD editor is missleading which maps to 3D instead of isometric.

Now I'm pretty sure about that as test what MoveBullet function use as target facing, and results was no matter of direction from where bullet is comming, if target facing e.g. north it always use north definition from JSD.

I think that we shouldn't try to fix this to death because we will never have "the perfect" fix anyway. A somewhat improved structure definition is already a big improvement.

JSDs also have index 0 to 7 so I assume they use the same logic. Looking at standing stance structures this matches perfectly and the other stances match as well

About merc facing north I presume when he look in the top of your monitor, and first entry in JSD is for that then go clockwise.

Index: TileEngine/structure.cpp
===================================================================
--- TileEngine/structure.cpp	(revision 6420)
+++ TileEngine/structure.cpp	(working copy)
@@ -1875,6 +1875,11 @@
 		{
 			gprintf( 0, LINE_HEIGHT * 1, L"DDoorRt with orientation %s", WallOrientationString[pStructure->ubWallOrientation] );
 		}
+		else if (pStructure->fFlags & STRUCTURE_PERSON)
+		{
+			if (pStructure->pDBStructureRef != NULL && pStructure->pDBStructureRef->pDBStructure != NULL)
+				gprintf( 0, LINE_HEIGHT * 1, L"PersonStructure with StructureNumber %d", pStructure->pDBStructureRef->pDBStructure->usStructureNumber );
+		}
 		else
 		{
 			gprintf( 0, LINE_HEIGHT * 1, L"UNKNOWN STRUCTURE! (%x)", pStructure->fFlags );

I also found the code where the structure is added to a merc:

Toggle Spoiler

fReturn = AddStructureToWorld( sGridNo, pSoldier->pathing.bLevel, &( pStructureFileRef->pDBStructureRef[ gOneCDirection[ pSoldier->ubDirection ] ] ), pSoldier->pLevelNode );

that means the structures indices are rotated one step in counterclock direction in jsd file and need to rotated back one step clockwise in code.
upDirection [NORTH] returns pDPStructure[1]. (NW,N,NE,E,SE,S,SW,W).

Uriens

Yup, was just planning to report this. When merc is lying prone and you order him to shoot at something that requires him to change facing he will spend significantly less ap's then advertized on crosshair info. Actually, even though you planned to spend all ap's on shooting that target, merc will have 20+ ap's left when he's done. It's pretty big bug in calculation.

Those are fixes from r6414:

Brief: //dnl ch71
- Fix more problems of deducting APs when try to shoot from different stances but need turn to your target.
Details:
- Problems raised after introduction of conditional APs charge in case that you need to rise gun and turn, so charging only higher of this to two value if not prone.
- Another problem is alternative fire mode from hip which is currently allowed only in stand so was missing such condition as well for change scope mode if going down.
- As run into problems from above for our merc, need adopt it to CalcBestShot for AI too.


please test it if APs are now deducted correctly.

Now thinking it will be nice to had all current mods in one place (SVN) it's will be easier to test before commit changes, currently need to download and install separate mods, like wildfire (or we have branch for them too but I'm not aware of it).

• 1.13 JA2 Demo (mentioned before)
• Wildfire 5.0
• Wildfire 6.06 & 6.07 (silversurfer did some changes to it recently)
• Most of the UB mods ported to 1.13
• Flugente's WH40K, (2), (3)
• Flugente's Zombie Invasion

I think this is not logical and should behave as ordinary GL like M79, also they take cost for raising gun but isn't such cost included in basic launch cost.

What do you think should attached GL behave as ordinary GL or it's fine by you to take almost 40% more cost for nonsense?

• Windows 7 Professional x64 English
• Intel Core i5-760 (4 cores & no HT, 2.8GHz)
• 2 x 8GB RAM (1600mhz DDR3)
• AMD Radeon 5870 GPU
• 1920x1080 resolution (but I think it happened on lower resolutions too)
• OS is on an OCZ-VERTEX2 SSD drive @ SATA 2.0, Game is installed on secondary HDD WD20EARX @ SATA 3.0, both are running under AHCI

Tested on 6407 exe revision and 1773 SVN revision.

Quote from exe revision history:

Quote:

r6386 | Kriplo | 2013-09-10 22:49:49 +0200 (Di, 10 Sep 2013) | 16 lines

Brief: //dnl ch68
- Magically appeared reinforcements for enemy and militia just turn after they are called from now could be delayed and randomized.
Details:
- Practically all enemy reinforcement which can populate available slots was always appeared next turn after they are called so now we have game settings under "Strategic Gameplay Settings" for fine tunning enemy and militia reinforce entry:
MIN_DELAY_ENEMY_REINFORCEMENTS enemy reinforcement will arrive minimum this number of turns after they are called, if 0 then is disabled.
RND_DELAY_ENEMY_REINFORCEMENTS additional random delay added to minimum when reinforcements will arrive after they are called.
MIN_ENTER_ENEMY_REINFORCEMENTS minimum enemy units which will enter after above delay is over.
RND_ENTER_ENEMY_REINFORCEMENTS additional random enemy units to appear after passing delay.
MIN_DELAY_MILITIA_REINFORCEMENTS enemy reinforcement will arrive minimum this number of turns after they are called, if 0 then is disabled.
RND_DELAY_MILITIA_REINFORCEMENTS additional random delay added to minimum when reinforcements will arrive after they are called.
MIN_ENTER_MILITIA_REINFORCEMENTS minimum enemy units which will enter after above delay is over.
RND_ENTER_MILITIA_REINFORCEMENTS additional random enemy units to appear after passing delay.
- After first delay ends any other reinforcement appeared more frequently or if already arrive (but no free slot), they will pop up soon after slot is free.
- Add option NO_REMOVE_RANDOM_SECTOR_ITEMS under "Strategic Gameplay Settings" to prevent permanent random removal of your sector items.
- Add missing function DisplaySectorItemsInfo.

However, such lines don't exist in the options ini file at all. As a result, I have yet to see any reinforcement's arrive for either militia or enemy in my current Chitzena coounterattack battle.