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

 
Messages:3509
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

Report message to a moderator

Captain

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

 
Messages:328
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.

Report message to a moderator

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

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

Report message to a moderator

Captain

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

 
Messages:328
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

Report message to a moderator

Master Sergeant
Re: BUGZILLA report all bugs here![message #324415] Thu, 29 August 2013 00:42 Go to previous messageGo to next message
Katagelan is currently offline 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.

Report message to a moderator

Private 1st Class
Re: BUGZILLA report all bugs here![message #324417] Thu, 29 August 2013 00:52 Go to previous messageGo to next message
Flugente

 
Messages:3509
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.

Report message to a moderator

Captain

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

 
Messages:346
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.

Report message to a moderator

Master Sergeant
Re: BUGZILLA report all bugs here![message #324452] Thu, 29 August 2013 21:53 Go to previous messageGo to next message
Kriplo is currently offline Kriplo

 
Messages:256
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

Report message to a moderator

Master Sergeant
Re: BUGZILLA report all bugs here![message #324454] Thu, 29 August 2013 22:15 Go to previous messageGo to next message
Kriplo is currently offline Kriplo

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

also game refuse start as in Language Defines.h current define is POLISH and probably should be ENGLISH ?

Report message to a moderator

Master Sergeant
Re: BUGZILLA report all bugs here![message #324456] Thu, 29 August 2013 22:21 Go to previous messageGo to next message
Flugente

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

Report message to a moderator

Captain

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

 
Messages:256
Registered:February 2008
Location: Zagreb - Croatia
So those new functions are part of JA2UB, thanks.

Report message to a moderator

Master Sergeant
Re: BUGZILLA report all bugs here![message #324461] Thu, 29 August 2013 23:56 Go to previous messageGo to next message
Flugente

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

Report message to a moderator

Captain

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

 
Messages:154
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.

Report message to a moderator

Staff Sergeant
Re: BUGZILLA report all bugs here![message #324491] Fri, 30 August 2013 14:09 Go to previous messageGo to next message
Elvis_A is currently offline 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

Report message to a moderator

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

 
Messages:2793
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.

Report message to a moderator

Lieutenant
Re: BUGZILLA report all bugs here![message #324504] Fri, 30 August 2013 16:30 Go to previous messageGo to next message
Elvis_A is currently offline 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

Report message to a moderator

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

 
Messages:1961
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

Report message to a moderator

Sergeant Major

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

 
Messages:2793
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.

Report message to a moderator

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

 
Messages:1961
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.

Report message to a moderator

Sergeant Major

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

 
Messages:256
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:

Report message to a moderator

Master Sergeant
Re: BUGZILLA report all bugs here![message #324558] Sun, 01 September 2013 04:30 Go to previous messageGo to next message
silversurfer

 
Messages:2793
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.

Report message to a moderator

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

 
Messages:2793
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

Report message to a moderator

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

 
Messages:2793
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.

Report message to a moderator

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

 
Messages:346
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.

Report message to a moderator

Master Sergeant
Re: BUGZILLA report all bugs here![message #324604] Mon, 02 September 2013 20:58 Go to previous messageGo to next message
Kasar is currently offline 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!

Report message to a moderator

Private 1st Class
Re: BUGZILLA report all bugs here![message #324605] Mon, 02 September 2013 21:18 Go to previous messageGo to next message
Flugente

 
Messages:3509
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.

Report message to a moderator

Captain

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

 
Messages:2793
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

Report message to a moderator

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

 
Messages:693
Registered:July 2008
I believe it's fixed in 6344

Report message to a moderator

First Sergeant
Re: BUGZILLA report all bugs here![message #324612] Mon, 02 September 2013 22:28 Go to previous messageGo to next message
Kasar is currently offline 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...

Report message to a moderator

Private 1st Class
Re: BUGZILLA report all bugs here![message #324667] Tue, 03 September 2013 21:43 Go to previous messageGo to next message
Kriplo is currently offline Kriplo

 
Messages:256
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

Report message to a moderator

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

 
Messages:2793
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?

Report message to a moderator

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

 
Messages:256
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

Report message to a moderator

Master Sergeant
Re: BUGZILLA report all bugs here![message #324714] Wed, 04 September 2013 13:10 Go to previous messageGo to next message
Elvis_A is currently offline 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.

Report message to a moderator

Master Sergeant
Re: BUGZILLA report all bugs here![message #324719] Wed, 04 September 2013 14:21 Go to previous messageGo to next message
Gambigobilla

 
Messages:693
Registered:July 2008
Can you check if there is an invisible mike (it happens) with Ctrl + GABBI then ALT + E

Report message to a moderator

First Sergeant
Re: BUGZILLA report all bugs here![message #324731] Wed, 04 September 2013 16:40 Go to previous messageGo to next message
silversurfer

 
Messages:2793
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.

Report message to a moderator

Lieutenant
Re: BUGZILLA report all bugs here![message #324744] Wed, 04 September 2013 20:55 Go to previous messageGo to next message
silversurfer

 
Messages:2793
Registered:May 2009
Kriplo
@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.

Ok, I looked a bit closer at the code and it doesn't seem to make any sense to me now. The calculations for AIM_SHOT_HEAD and AIM_SHOT_LEGS that you see before the switch have nothing to do with being a prone shooter. They are applied directly to iChance and represent a penalty for shooting at certain body parts.

The switch that we are looking at represents a penalty for shooting at a target that has a specific stance and we are prone.

The last option where target stance is ANIM_STAND and we are prone uses this formula:

iChance -= (INT32)((5 - ubAdjAimPos - iRange / CELL_X_SIZE) * 10 * iPenalty);

I don't know where this iPenalty comes from but it doesn't belong there at all.
In addition to that the formula doesn't make sense. Example:

Our target is 5 tiles away (iRange = 50) and we are shooting at the torso (torso is AimPos 2).

(5 - 2 - 50/10) *10 = -20

iChance -= -20 means iChance - (-20)

Hey cool, we just got a bonus of 20 points to CTH. :whythis:
No doubt why people love to play with OCTH... Very Happy

A few more results:
	      aimed at
Distance      Body Part		Result
   1		Legs		 10
   1		Torso		 20
   1		Head		 30

   2		Legs		  0
   2		Torso		 10
   2		Head		 20

   3		Legs		-10
   3		Torso		  0
   3		Head		 10

   4		Legs		-20
   4		Torso		-10
   4		Head		  0

   5		Legs		-30
   5		Torso		-20
   5		Head		-10

As you can see if the target is 3 tiles or further away we receive a bonus to CTH in most cases.
Actually for headshots this stuff doesn't even apply because:
if (pTarget != NULL && ubAimPos != AIM_SHOT_HEAD)


I think I will remove the "case ANIM_STAND" completely and make it a separate if clause below with some NCTH magic.


edit: I'm going to use this formula now for the penalty:

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


The worst thing that can happen is that you are prone on ground level, your target is standing on a roof and you aim for the head. iHeightDifference would be 5 in this case.
At 1 tile range you would get a penalty of -50. Is that too much? Remember, you are basically looking at a wall trying to aim at a head 4.5 meters above you, not the ideal situation...
At 10 tiles range the penalty would be just -5 which is almost nothing and you wouldn't have to break your neck in the process. Wink

[Updated on: Wed, 04 September 2013 21:36] by Moderator

Report message to a moderator

Lieutenant
Re: BUGZILLA report all bugs here![message #324746] Wed, 04 September 2013 22:25 Go to previous messageGo to next message
Kriplo is currently offline Kriplo

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

Excellent fix, thanks, calculation now work like a charm :cheers:
it's was so itching bug as currently test fix for incorrect vertical angle formula in firing bullets.

Report message to a moderator

Master Sergeant
Re: BUGZILLA report all bugs here![message #324827] Fri, 06 September 2013 23:42 Go to previous messageGo to next message
Parkan is currently offline Parkan

 
Messages:439
Registered:April 2010
Location: Russia,Sevastopol

Something weird is going with music in game.The battle tracks can play only 5-15 second then they start from all over again.the win music after tactical battle never run,plus i got bug with win music 5 times win music played after autoresolve battle.what is shit happened with it?

Report message to a moderator

Master Sergeant
Re: BUGZILLA report all bugs here![message #324828] Fri, 06 September 2013 23:51 Go to previous messageGo to next message
wolf00 is currently offline wolf00

 
Messages:1148
Registered:September 2006
Location: Czech Republic

prizes in tony black market are in mess,some are in negative values ... sci 1753 6358.exe

Report message to a moderator

Sergeant Major
Re: BUGZILLA report all bugs here![message #324829] Sat, 07 September 2013 00:18 Go to previous messageGo to previous message
wanne (aka RoWa21) is currently offline wanne (aka RoWa21)

 
Messages:1961
Registered:October 2005
Location: Austria
Parkan
Something weird is going with music in game.The battle tracks can play only 5-15 second then they start from all over again.the win music after tactical battle never run,plus i got bug with win music 5 times win music played after autoresolve battle.what is shit happened with it?


it seems the bugs have something to do with the music externalization. I forwarded the bugreport to Jazz, so he hopefully can fix it.

Report message to a moderator

Sergeant Major

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


Current Time: Fri Mar 29 14:16:13 GMT+2 2024

Total time taken to generate the page: 0.04413 seconds