Home » MODDING HQ 1.13 » v1.13 Bug Reports » BUGZILLA report all bugs here!
Re: BUGZILLA report all bugs here![message #324400] Wed, 28 August 2013 20:12 Go to previous messageGo to next message
Kriplo

 
Messages:261
Registered:February 2008
Location: Zagreb - Croatia
@Flugente
Benefit is faster start under debugger (can bet time will be halved) and make debugging easier specially when work with laptop where take almost half minute. Sure, it's far from easy to implement, but anyway it will be nice to have it Very Happy

@Rowa21
Faster is but without "edit and continue" and not always showing values after breakpoint, but good option for test before commit, thanks.
Re: BUGZILLA report all bugs here![message #324403] Wed, 28 August 2013 21:06 Go to previous messageGo to next message
pheloncab

 
Messages:281
Registered:August 2004
Location: So. Cal. or texas
Flugente
If you are in B13 and command moveitem on D13, that means your merc will move items from D13 to B13. Not the other way around. Are there items in D13 they could move?


Thanks.. Left the webpage up when I fell asleep at the keyboard, and woke up and realized the error I made and put in an edit. When it refreshed.. your answer was there..

Re: BUGZILLA report all bugs here![message #324404] Wed, 28 August 2013 21:09 Go to previous messageGo to next message
Katagelan

 
Messages:21
Registered:June 2012
Flugente


Why would we do that? The whole point is to externalise as much as possible (and reasonable) for maximum freedom of the user. There are other sections that would benefit from speeding up much, much more. Like attachment handling for example, which causes debug exes to hang every time one opens EDB.[/quote]

Then why make the "drop all loot" not switchable mid-game ? That would be a step toward maximum freedom.
Re: BUGZILLA report all bugs here![message #324406] Wed, 28 August 2013 22:03 Go to previous messageGo to next message
Shadow21

 
Messages:329
Registered:November 2001
Location: on route to San Hermanos
i found a bug that freezes the game. every time mercs automatically consume food the game hangs if one of the mercs tries to consume a drink or another item that is in a stack of more than four items.
Re: BUGZILLA report all bugs here![message #324408] Wed, 28 August 2013 22:15 Go to previous messageGo to next message
Flugente

 
Messages:3542
Registered:April 2009
Location: Germany
Shadow21
i found a bug that freezes the game. every time mercs automatically consume food the game hangs if one of the mercs tries to consume a drink or another item that is in a stack of more than four items.
Works fine for me... exe? mod? Anything else odd?


Re: BUGZILLA report all bugs here![message #324409] Wed, 28 August 2013 22:19 Go to previous messageGo to next message
Flugente

 
Messages:3542
Registered:April 2009
Location: Germany
Juan
Then why make the "drop all loot" not switchable mid-game ? That would be a step toward maximum freedom.
It was switchable once, but it was moved later on for different reasons


Re: BUGZILLA report all bugs here![message #324410] Wed, 28 August 2013 22:29 Go to previous messageGo to next message
Shadow21

 
Messages:329
Registered:November 2001
Location: on route to San Hermanos
Flugente
Shadow21
i found a bug that freezes the game. every time mercs automatically consume food the game hangs if one of the mercs tries to consume a drink or another item that is in a stack of more than four items.
Works fine for me... exe? mod? Anything else odd?

i am indeed using mods. i use arulco revisited and AFS.
i am using exe version 6322 but had that problem with older version as well.

if i put 8 pet bottles into a backpack slot and the merc is thirsty (glass icon on portrait) the next time the merc auto drinks (full hour) the game freezes and i cant move the mouse, it doesnt crash though.
Re: BUGZILLA report all bugs here![message #324411] Wed, 28 August 2013 22:44 Go to previous messageGo to next message
Flugente

 
Messages:3542
Registered:April 2009
Location: Germany
And that also happens when you drink from a stack manually?


Re: BUGZILLA report all bugs here![message #324412] Wed, 28 August 2013 23:52 Go to previous messageGo to next message
Shadow21

 
Messages:329
Registered:November 2001
Location: on route to San Hermanos
that works without problems. the freeze only occurs when time is compressed and the merc drinks automatically
Re: BUGZILLA report all bugs here![message #324415] Thu, 29 August 2013 00:42 Go to previous messageGo to next message
Katagelan

 
Messages:21
Registered:June 2012
Cowering or pinned down enemies ( the ones doing the cowering civilian animation )can become impossible to hit even in hand-to-hand.
Sometimes a militia can occupy the same space and be hit even when it is the cowering one who is targeted.
I have seen a militia kicking repeatedly another who was standing on top of a prone pinned enemy.


When a sector loads for tactical battle, sometimes the game ceases to recognize my AZERTY keyboard and works in QWERTY.
Reloading the game makes the situation normal again.


The masterkey underbarrel shotgun replenishes indefinitely its ammunition.
Re: BUGZILLA report all bugs here![message #324417] Thu, 29 August 2013 00:52 Go to previous messageGo to next message
Flugente

 
Messages:3542
Registered:April 2009
Location: Germany
Juan
The masterkey underbarrel shotgun replenishes indefinitely its ammunition.
That is known. I haven't been able to solve that one so far. To reload it with, drop ammo on the main gun while an underbarrel firing mode is selected.


Re: BUGZILLA report all bugs here![message #324444] Thu, 29 August 2013 14:44 Go to previous messageGo to next message
Uriens

 
Messages:332
Registered:July 2006
Juan
Cowering or pinned down enemies ( the ones doing the cowering civilian animation )can become impossible to hit even in hand-to-hand.
Sometimes a militia can occupy the same space and be hit even when it is the cowering one who is targeted.
I have seen a militia kicking repeatedly another who was standing on top of a prone pinned enemy.


I can confirm those. Unhittable bug usually happens when a stun or explosive grenade is used. I used to think that explosion makes actors fall on impossible locations and that is what causes the 'invulnerability' bug. However, I have seen this happen on enemies that were on plain grassland with no objects near so I really can't tell what causes this. I guess to replicate have a group of enemies and toss stun grenade at them following with explosive one. Those that don't get hurt by explosion (and should) are pretty much those that got 'invulnerability' bug. Could be related to cover animations but I'm not 100% sure.

On top of that, frequently enemies go to 'dying' state but don't really die. They appear 'grayed out' as if they are out of vision (not true though) and can be force targeted as if you are shooting at the tile. One shot will end them though. AI ignores such targets.

Quote:

When a sector loads for tactical battle, sometimes the game ceases to recognize my AZERTY keyboard and works in QWERTY.
Reloading the game makes the situation normal again.


That could be because of ALT+SHIFT windows keyboard shortcut that switches language settings. Try pressing ALT+SHIFT again to get back to standard. You can also try to disable that shortcut in windows if you don't really need it. I've had it cause similar problems in numerous games so I have it turned off completely.
Re: BUGZILLA report all bugs here![message #324452] Thu, 29 August 2013 21:53 Go to previous messageGo to next message
Kriplo

 
Messages:261
Registered:February 2008
Location: Zagreb - Croatia

Current build won't compile under debug:

1>c:\games\jagged alliance 2\buildnew\strategic\luainitnpcs.cpp(1481) : error C2065: 'l_InitMapProfil' : undeclared identifier
1>c:\games\jagged alliance 2\buildnew\strategic\luainitnpcs.cpp(1483) : error C2065: 'l_SetKeySoldier' : undeclared identifier

Rowa21, Flugente please check if this functions are part of JA2UB or whatever and fixit Wink
Re: BUGZILLA report all bugs here![message #324454] Thu, 29 August 2013 22:15 Go to previous messageGo to next message
Kriplo

 
Messages:261
Registered:February 2008
Location: Zagreb - Croatia

also game refuse start as in Language Defines.h current define is POLISH and probably should be ENGLISH ?
Re: BUGZILLA report all bugs here![message #324456] Thu, 29 August 2013 22:21 Go to previous messageGo to next message
Flugente

 
Messages:3542
Registered:April 2009
Location: Germany
SVN won't let me commit. Just move the '#ifdef JA2UB' to line 1480 for the time being.


Re: BUGZILLA report all bugs here![message #324457] Thu, 29 August 2013 22:44 Go to previous messageGo to next message
Kriplo

 
Messages:261
Registered:February 2008
Location: Zagreb - Croatia
So those new functions are part of JA2UB, thanks.
Re: BUGZILLA report all bugs here![message #324461] Thu, 29 August 2013 23:56 Go to previous messageGo to next message
Flugente

 
Messages:3542
Registered:April 2009
Location: Germany
Both errors fixed in r6337.


Re: BUGZILLA report all bugs here![message #324465] Fri, 30 August 2013 03:51 Go to previous messageGo to next message
Faalagorn

 
Messages:156
Registered:February 2012
Location: Poland
In revision 1741, when the ini was last changed it says:
; JA2 1.13 - Unfinished Business (JA2 1.13)
; VFS_CONFIG_INI = vfs_config.JA2113.ini


While I think it should be:
; JA2 1.13 - Unfinished Business (JA2 1.13)
; VFS_CONFIG_INI = vfs_config.UB113.ini


While we're at it, why not just change it so there is some consistent naming scheme in these files, i.e. something like this:
; JA2 1.13
VFS_CONFIG_INI = vfs_config.JA2113.ini

; JA2 1.13 - Vanilla (JA2 Classic)
; VFS_CONFIG_INI = vfs_config.JA2Vanilla.ini

; JA2UB 1.13
; VFS_CONFIG_INI = vfs_config.UB113.ini

; JA2UB 1.13 - Vanilla (JA2UB Classic)
; VFS_CONFIG_INI = vfs_config.UBVanilla.ini

There's still some inconsistency in the naming of the ini files themselves (omission of the "113" in Vanilla inis and omission of "JA2" in UB inis, but well.
Re: BUGZILLA report all bugs here![message #324491] Fri, 30 August 2013 14:09 Go to previous messageGo to next message
Elvis_A

 
Messages:282
Registered:December 2012
Location: exUSSR
After updating svn 173x to last 1744, exe was 6322, mercs dissapeared from MERC site, even there are emails left from Speck about new available mercs. Last available merc was Larry, now it is Lance again. Is it bug or some changes in ini after update?

edit 2
4.7x33 100 AP ammo box fits AR magazine slot in lbe. is it supposed to be like that?

[Updated on: Fri, 30 August 2013 15:06] by Moderator

Re: BUGZILLA report all bugs here![message #324494] Fri, 30 August 2013 15:13 Go to previous messageGo to next message
silversurfer

 
Messages:2759
Registered:May 2009
E1vS
After updating svn 173x to last 1744, exe was 6322, mercs dissapeared from MERC site, even there are emails left from Speck about new available mercs. Last available merc was Larry, now it is Lance again. Is it bug or some changes in ini after update?


Was your game started with exe 6322 or was it older than that? In 6286 there was a bugfix for merc availability which is not able to automatically fix all related bugs in older savegames. If your game was started after that fix there shouldn't be any problems with merc availability.

Re: BUGZILLA report all bugs here![message #324504] Fri, 30 August 2013 16:30 Go to previous messageGo to next message
Elvis_A

 
Messages:282
Registered:December 2012
Location: exUSSR
silversurfer
E1vS
After updating svn 173x to last 1744, exe was 6322, mercs dissapeared from MERC site, even there are emails left from Speck about new available mercs. Last available merc was Larry, now it is Lance again. Is it bug or some changes in ini after update?


Was your game started with exe 6322 or was it older than that? In 6286 there was a bugfix for merc availability which is not able to automatically fix all related bugs in older savegames. If your game was started after that fix there shouldn't be any problems with merc availability.



I started the game recently. exe was the same 6322. MERC mercs were available ja 1 natives + some others, and in the end of list Larry Roachburn. I will "wait" one week in the game. I opened Merc site and Speck said something like with current profit new mercenaries will be available soon. Maybe game progress resetted or some files changed.

By the way my imp mercs cannot do gun repair to 100%. they have technician trait. I edited manually ja2 options ini and put it TRUE.

[Updated on: Fri, 30 August 2013 16:36] by Moderator

Re: BUGZILLA report all bugs here![message #324509] Fri, 30 August 2013 17:32 Go to previous messageGo to next message
wanne (aka RoWa21)

 
Messages:2001
Registered:October 2005
Location: Austria
Faalagorn
In revision 1741, when the ini was last changed it says:
; JA2 1.13 - Unfinished Business (JA2 1.13)
; VFS_CONFIG_INI = vfs_config.JA2113.ini


While I think it should be:
; JA2 1.13 - Unfinished Business (JA2 1.13)
; VFS_CONFIG_INI = vfs_config.UB113.ini


While we're at it, why not just change it so there is some consistent naming scheme in these files, i.e. something like this:
; JA2 1.13
VFS_CONFIG_INI = vfs_config.JA2113.ini

; JA2 1.13 - Vanilla (JA2 Classic)
; VFS_CONFIG_INI = vfs_config.JA2Vanilla.ini

; JA2UB 1.13
; VFS_CONFIG_INI = vfs_config.UB113.ini

; JA2UB 1.13 - Vanilla (JA2UB Classic)
; VFS_CONFIG_INI = vfs_config.UBVanilla.ini

There's still some inconsistency in the naming of the ini files themselves (omission of the "113" in Vanilla inis and omission of "JA2" in UB inis, but well.


Thanks, I correct the ja2.ini


Re: BUGZILLA report all bugs here![message #324520] Fri, 30 August 2013 23:40 Go to previous messageGo to next message
silversurfer

 
Messages:2759
Registered:May 2009
People, when working with Lua script function "CheckFact" please always supply the fact AND a profile ID (profile ID can be 0 in most cases). Otherwise the function will always return "false".

Function call should look like "CheckFact( fact, profileID )".

I just got shot by Kingpins goons while entering his house because of a incomplete function call in the current scripts...

Fix for that and other similar errors is on its way to RoWa.

Re: BUGZILLA report all bugs here![message #324521] Sat, 31 August 2013 00:00 Go to previous messageGo to next message
wanne (aka RoWa21)

 
Messages:2001
Registered:October 2005
Location: Austria
silversurfer
People, when working with Lua script function "CheckFact" please always supply the fact AND a profile ID (profile ID can be 0 in most cases). Otherwise the function will always return "false".

Function call should look like "CheckFact( fact, profileID )".

I just got shot by Kingpins goons while entering his house because of a incomplete function call in the current scripts...

Fix for that and other similar errors is on its way to RoWa.


Thanks silversurfer, I have just committed the fix.


Re: BUGZILLA report all bugs here![message #324535] Sat, 31 August 2013 13:50 Go to previous messageGo to next message
Kriplo

 
Messages:261
Registered:February 2008
Location: Zagreb - Croatia
In r6340 fix tank bursting shells problem, and some other tank related bugs mostly with invalid animation decisions, bad APs calculation and limitation to 6 rounds when tank use machine gun.

Barry and Bob dies horribly many times before due to this fixing :bawling:
Re: BUGZILLA report all bugs here![message #324558] Sun, 01 September 2013 04:30 Go to previous messageGo to next message
silversurfer

 
Messages:2759
Registered:May 2009
To those experiencing weired face exchange with the merc swapping feature (CTRL + left / CTRL + right):

I have a feeling that this is somehow related to interrupts. Could you please check and confirm (or not).

When it happened in my game that a merc was moved away from the spot where I put him it was during an interrupt. I could see that my Squad[0][] array had the wrong order but I don't know why. For example merc 4 was now in position 0. This is retained during save/load. Also gTeamPanel has the same wrong sort order. The only way to fix Squad and gTeamPanel is to reassign the group but at some point it gets a wrong sort order again. http://forum.egosoft.com/images/smiles/icon_think.gif

First thing I will do is to issue a sort command after swapping mercs so that the Squad array has the correct order but this will not fix the issue with interrupts.

Re: BUGZILLA report all bugs here![message #324574] Mon, 02 September 2013 01:31 Go to previous messageGo to next message
silversurfer

 
Messages:2759
Registered:May 2009
edit: Found what I was looking for. Data Breakpoint is the key. Smile

Could someone please lend me a hand here? I'm trying to solve the bug where opponents that are killed at the edge of a roof will stand there forever in dying state.

I already found the reason why animations are not working correctly.

Soldier Control.cpp:

BOOLEAN SOLDIERTYPE::CheckSoldierHitRoof( void )

This function checks if the victim can fall from the edge of the roof. It sets some flags.

this->EVENT_SetSoldierDesiredDirection // this sets the direction that our victim should be turning to before he falls off the roof
this->flags.fTurningUntilDone = TRUE; // turn until you fall
this->usPendingAnimation // FALLOFF or FALLFORWARD_ROOF, in my tests it was always FALLOFF (backwards)

So far so good. This works fine. Turning animation starts. This is handled in:

void SOLDIERTYPE::TurnSoldier( void )

This code here is supposed to make us fall from the roof:
if ( this->flags.fTurningUntilDone && ( this->usPendingAnimation != NO_PENDING_ANIMATION ) )
{
	if ( this->ubDirection == this->pathing.bDesiredDirection )
	{
		UINT16 usPendingAnimation;

		usPendingAnimation = this->usPendingAnimation;
		this->usPendingAnimation = NO_PENDING_ANIMATION;

		this->EVENT_InitNewSoldierAnim( usPendingAnimation, 0 , FALSE );
		this->flags.fTurningUntilDone = FALSE;
	}
}

On the first run of TurnSoldier( void )
this->flags.fTurningUntilDone is TRUE
this->usPendingAnimation is FALLOFF

Unfortunately my victim was not facing the right direction at the beginning so he had to turn a bit (faced SW, desired was SE).
Now here comes the problem - on the next run of function TurnSoldier( void ) the flag
this->usPendingAnimation is set to NO_PENDING_ANIMATION. WTF? The above code will never be used with that! :rant2:

So far I haven't been able to find the spot where this->usPendingAnimation is set to NO_PENDING_ANIMATION after the first run of TurnSoldier( void ). How can I backtrace this?

[Updated on: Mon, 02 September 2013 11:00] by Moderator


Re: BUGZILLA report all bugs here![message #324597] Mon, 02 September 2013 19:39 Go to previous messageGo to next message
silversurfer

 
Messages:2759
Registered:May 2009
Managed to fix the "undying soldier on roof edge" problem in rev. 6346. :yaysupplz:

The problem was part of resetting animations if a new situation occurred. In general this functionality should stop anybody from doing anything for example when an interrupt happens but it shouldn't prevent the dead from dying. Wink


Also added a change that enemies do not attack empty player vehicles anymore. Made little sense to me that a soldier would attack an empty car when there are dangerous mercs around.

Re: BUGZILLA report all bugs here![message #324601] Mon, 02 September 2013 20:07 Go to previous messageGo to next message
Uriens

 
Messages:332
Registered:July 2006
You killed rooftop zombies bug? :bawling:

That bug was with us so long I was just about to propose to moderators to make it a forum account and give it a honorable bug badge. :et5:

I guess all it gets now is a funeral. :rip:

Well, ok, I'm just kidding. :blah:
Good job on fixing this.


Btw. regarding:
silversurfer
To those experiencing weired face exchange with the merc swapping feature (CTRL + left / CTRL + right):

I have a feeling that this is somehow related to interrupts. Could you please check and confirm (or not).

When it happened in my game that a merc was moved away from the spot where I put him it was during an interrupt. I could see that my Squad[0][] array had the wrong order but I don't know why. For example merc 4 was now in position 0. This is retained during save/load. Also gTeamPanel has the same wrong sort order. The only way to fix Squad and gTeamPanel is to reassign the group but at some point it gets a wrong sort order again. http://forum.egosoft.com/images/smiles/icon_think.gif

First thing I will do is to issue a sort command after swapping mercs so that the Squad array has the correct order but this will not fix the issue with interrupts.


It's quite possible this has to do with interrupts. First time I ran into this it was just when I landed in Omerta after fresh start of the game. OFC, I was in combat almost immediately and it's quite possible interrupts caused this.

When I tried to recreate the bug I was trying to move mercs when there were no enemies in sector so the feature worked fine.
Re: BUGZILLA report all bugs here![message #324604] Mon, 02 September 2013 20:58 Go to previous messageGo to next message
Kasar

 
Messages:27
Registered:August 2013
Location: Toronto, Canada
Hi there, I have posted this in another thread - but perhaps this is the best place for it.

Seems the arrival drop off point gets moved to sector p16 when it had been placed in an area, that then gets taken over by the enemy. The game auto-relocates it, but to p16. Once at p16, it cannot be selected, or moved and any mercs that arrive are stuck in p16 without any options to do anything.

I have the latest patch from DepressiveBrot's link, on top of 1.12.

Any ideas?

Thanks in advance!
Re: BUGZILLA report all bugs here![message #324605] Mon, 02 September 2013 21:18 Go to previous messageGo to next message
Flugente

 
Messages:3542
Registered:April 2009
Location: Germany
Kasar
Hi there, I have posted this in another thread - but perhaps this is the best place for it.

Seems the arrival drop off point gets moved to sector p16 when it had been placed in an area, that then gets taken over by the enemy. The game auto-relocates it, but to p16. Once at p16, it cannot be selected, or moved and any mercs that arrive are stuck in p16 without any options to do anything.

I have the latest patch from DepressiveBrot's link, on top of 1.12.

Any ideas?

Thanks in advance!
Buggler fixed that this very morning. The next SCI / any exe >= r6344 will have this fix.


Re: BUGZILLA report all bugs here![message #324606] Mon, 02 September 2013 21:19 Go to previous messageGo to next message
silversurfer

 
Messages:2759
Registered:May 2009
Kasar

Seems the arrival drop off point gets moved to sector p16 when it had been placed in an area, that then gets taken over by the enemy. The game auto-relocates it, but to p16. Once at p16, it cannot be selected, or moved and any mercs that arrive are stuck in p16 without any options to do anything.


This bug was fixed yesterday in rev. 6344 by Buggler. Thanks for that. Smile
I just don't know if it will fix your savegame where the marker is already in an inaccessible sector.

edit: Now I know why he is called Flugente. He's so damn fast. Very Happy

@Gambigobilla Razz

[Updated on: Mon, 02 September 2013 21:21] by Moderator


Re: BUGZILLA report all bugs here![message #324607] Mon, 02 September 2013 21:20 Go to previous messageGo to next message
Gambigobilla

 
Messages:709
Registered:July 2008
I believe it's fixed in 6344
Re: BUGZILLA report all bugs here![message #324612] Mon, 02 September 2013 22:28 Go to previous messageGo to next message
Kasar

 
Messages:27
Registered:August 2013
Location: Toronto, Canada
Very cool, thanks!

I will try to finish the game without the ability to recruit new mercs. I should be fine, as I had a lot before this happened.

I may have to go get the robot if it gets too hairy...
Re: BUGZILLA report all bugs here![message #324667] Tue, 03 September 2013 21:43 Go to previous messageGo to next message
Kriplo

 
Messages:261
Registered:February 2008
Location: Zagreb - Croatia

OCTH in CalcChanceToHitGun practically return 0 when you try to aim torso and distance between your prone merc and standing soldier less then 3 tiles. Aiming legs or head haven't this problem.
Comparing v1.12 with latest one shows that iPenalty is introduced in chance depending on target stance and seems have unset value for AIM_SHOT_TORSO.

Attached code shows where problem rise:
// Effects of visual range
// From for JA2.5:  3% bonus/penalty for each tile different from range NORMAL_RANGE.
if (!TANK(pSoldier))	// WANNE: No penalty on the tank
	iPenalty = 3 * ( NORMAL_RANGE - iSightRange ) / CELL_X_SIZE;
...
//CHRISL: We should probably include these target size penalties even if we can't see the target so that shooting a "hidden" head is harder then a "hidden" body
// if aiming at the head, reduce chance to hit
if (ubAimPos == AIM_SHOT_HEAD)
{
	// penalty of 3% per tile
	//iPenalty = 3 * iSightRange / 10; //comm by ddd
	iPenalty = INT32(gGameExternalOptions.uShotHeadPenalty * iSightRange / 10);
	iChance -= iPenalty;
}
else if (ubAimPos == AIM_SHOT_LEGS)
{
	// penalty of 1% per tile
	iPenalty = iSightRange / 10;
	iChance -= iPenalty;
}
//CHRISL: A target's stance should have no impact on an aimed, headshot.  The head doesn't get any smaller just because the target is crouching down.
if (pTarget != NULL && ubAimPos != AIM_SHOT_HEAD)
{
	// targeting a merc
	// adjust for crouched/prone target
	switch( gAnimControl[ pTarget->usAnimState ].ubHeight )
	{
	case ANIM_CROUCH:
...
		break;
	case ANIM_PRONE:
...
		break;
	case ANIM_STAND:
	// if we are prone and at close range, then penalize shots to the torso or head!
	if ( iRange <= MIN_PRONE_RANGE && stance == ANIM_PRONE )
	{
		if ( ubAimPos == AIM_SHOT_RANDOM || ubAimPos == AIM_SHOT_GLAND )
		{
			ubAdjAimPos = AIM_SHOT_TORSO;
		}
		else
		{
			ubAdjAimPos = ubAimPos;
		}
		// lose 10% per height difference, lessened by distance
		// e.g. 30% to aim at head at range 1, only 10% at range 3
		// or 20% to aim at torso at range 1, no penalty at range 3
		// NB torso aim position is 2, so (5-aimpos) is 3, for legs it's 2, for head 4
		iChance -= (INT32)((5 - ubAdjAimPos - iRange / CELL_X_SIZE) * 10 * iPenalty);
	}
	break;
	default:
		break;
	}
}


As CTH is part of never ending public debates and will probably never satisfy, I prefer to stand away messing with that and left to someone with OCTH/NCTH experience to fix that Wink

Re: BUGZILLA report all bugs here![message #324668] Tue, 03 September 2013 22:23 Go to previous messageGo to next message
silversurfer

 
Messages:2759
Registered:May 2009
Hmm, you are right, iPenalty holds some value from another calculation above. I have no idea which formula to implement there.

NCTH does it differently:

iHeightDifference = uiShooterHeight - uiTargetHeight;
if (iHeightDifference < 0)
{
	iHeightDifference *= -1;
}
else
{
	iHeightDifference = 0;
}

// Height difference is mitigated by range. A LONGER range reduces this penalty!
if (iRange > 0 && iHeightDifference > 0)
{
	FLOAT fTempPenalty = gGameCTHConstants.BASE_SHOOTING_UPWARDS * iHeightDifference;
	fTempPenalty /= iRange;

	fBaseModifier += fTempPenalty;
}


If our shooter is prone (height level 0) and we are shooting at the head of the target (height level 2) the height difference is 2.

BASE_SHOOTING_UPWARDS * 2 = -30

At iRange = 3 tiles (distance to target) the penalty is -10 which is big enough but it won't make our CTH 0. How about we "borrow" this piece of code for OCTH?

Re: BUGZILLA report all bugs here![message #324673] Tue, 03 September 2013 22:58 Go to previous messageGo to next message
Kriplo

 
Messages:261
Registered:February 2008
Location: Zagreb - Croatia
@silversurfer

Don't know reason for those changes probably to create more balance, but seems someone forget torso aiming from close distance.
Not sure if similar problem had NCTH as primary playing/testing with OCTH as NCTH concept is still mystery to me.

As you notice just before entering switch keyword, iPenalty is set for AIM_SHOT_HEAD and AIM_SHOT_LEGS but left some previous improper value for anything else.

Well, afraid I'm no use, so will leave decision to you as you have experience with CTH stuff Smile
Re: BUGZILLA report all bugs here![message #324714] Wed, 04 September 2013 13:10 Go to previous messageGo to next message
Elvis_A

 
Messages:282
Registered:December 2012
Location: exUSSR
svn 1747
exe 6343

I saw interesting bug yesterday. It is Mike recruitment related. After repelling attack on Grumm mine, 1 Deidrana soldier retreated to the next grumm sector. In tactical mode I heard bursts of fire and militia dying. It was in front of the ACA building near Bar. I was surprised that it was Mike. Good thing that I had one AIM merc to recognize him. I used 2 vacuum grenades and he did not fell down. I used 4 my mercs to beat him to Critical. He killed 4 elite militia and left 2 elite militia almost dead. If I did not beat him, I am pretty sure he could kill all militia in sector.

The Bug was after I recruited Mike. In map view there was still one soldier in sector. So I left sector in tactical, and entered again - still someone present but no enemy actually in sector, so I left sector but no autobattle triggered, and loyalty decreased =( I quit the game and started again. This time autobattle triggered and bug disappeared.
here are save files
http://www68.zippyshare.com/v/36218716/file.html

About bug with MERC mercs disappearance - new mercs slowly started to appear on the site.
Re: BUGZILLA report all bugs here![message #324719] Wed, 04 September 2013 14:21 Go to previous messageGo to next message
Gambigobilla

 
Messages:709
Registered:July 2008
Can you check if there is an invisible mike (it happens) with Ctrl + GABBI then ALT + E
Re: BUGZILLA report all bugs here![message #324731] Wed, 04 September 2013 16:40 Go to previous messageGo to previous message
silversurfer

 
Messages:2759
Registered:May 2009
The problem with invisible Mike should be solved since revision 6239. The game reads a flag that is stored in the savegame to make sure that it doesn't spawn another Mike. If this flag is set wrong from playing with an older exe before, the bug could still happen, I think. This flag should be fixed when Mike is spawned so you should probably never encounter the problem again.


E1vS

About bug with MERC mercs disappearance - new mercs slowly started to appear on the site.


The game checks regularly if new mercs should become available. This depends on days passed and the amount of money spend on M.E.R.C. Looks like the conditions are met in your game and the mercs show up now.

Previous Topic: 1440x900 resolution bug.
Next Topic: Mine income adjustment range
Goto Forum:
  


Current Time: Sat Oct 24 23:38:00 EEST 2020

Total time taken to generate the page: 0.03182 seconds