| Re: BUGS: Tais' SCI's[message #303796]
|
Mon, 23 April 2012 18:25  
|
|
 spaeR |
 |
Messages:77
Registered:September 2008
Location: Hungary |
|
|
I save, then the game crash, restart the game, and the game crash again! The weapon descriptions work, but the accesories (scopes, under. grenade launchers, supressors...) will crash! The game crash in strategy screen, and in tactical modes.
[Updated on: Mon, 23 April 2012 19:25] by Moderator Report message to a moderator
|
Corporal
|
|
|
|
| Re: BUGS: Tais' SCI's[message #303801]
|
Mon, 23 April 2012 19:28
|
|
| Wil473 |
 |
Messages:2815
Registered:September 2004
Location: Canada |
|
|
Decided to see if the bugs I found yesterday were repeatable - yes they are. Produced save games to confirm the issue exists under different OS (created on Win XP SP3, bug repeated on Win7 from save games). All testing done under Rev.5216 SCI.
Save games uploaded to MediaFire: HAM 5 Bugs now in SVN
Save Game Description / Process:
1) "HAM 5 Bug - LAW vs. soldier"
Blood, Grunty and Igor have been setup with various LAW-type weapons.
- Hit the middle target with a LAW, and notice that only he sustains damage, as there is no explosion
- Hit the ground near the targets and there is the expected explosion, along with expected damage
- Hit the middle target with Igor's RPG-7 and there is the expected explosion/damage
Bug seems to affect the original type LAW weapons. Re-loadable launchers, like the RPG-7, are not subject to this bug.
2) "HAM 5 Bug - LAW vs. tank"
Similar setup as 1)
- Hit the tank with a LAW-type weapon, no explosion/damage
- Hit the tank with Igor's RPG-7 and explosion/damage (likely the tank is gone too)
- Mortar and shells brought along because I wasn't expecting the RPG-7 to be so effective (these seem to work ok)
3) "HAM 5 Bug - Inventory 1"
N3, Meduna Airport, fight completed. Mercs still present in N3, sector inventory still present. Swapping between tactical and strategic does nothing to N3 inventory while the mercs are still there.
4) "HAM 5 Bug - Inventory 2"
The team has been Alt-T (strategic map cheat) out of N3. The sector inventory for N3 is present until you load the tactical view of N3, mercs do not have to be in N3. Bug is entirely repeatable.
[Updated on: Mon, 23 April 2012 19:31] by Moderator Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: BUGS: Tais' SCI's[message #303884]
|
Wed, 25 April 2012 05:44
|
|
| JKeenan |
|
Messages:3
Registered:April 2012 |
|
|
I'm not a coder, just a player, so I'm unable to tell if this is specifically a bug in Tais' SCI or something else.
My wife and I tried to play in co-op mode and were unable to because each time both players clicked Ready, the host's game crashed to the desktop. She's on a Windows XP netbook, I'm on a Windows 8 notebook. Game works fine in single-player mode on both computers. I was able to resolve this problem by removing JA2 from both computers and reinstalling JA2 and Tais' SCI and clearing the read-only attribute from both folders.
Once we were actually able to get into the game, though, we'd be able to play a few turns each before the game would freeze during the computer's turn. My screen would say that I was waiting for my wife, but hers would say that she was waiting for the computer. I wasn't able to do anything to get the game going again; we both had to force quit. This happened three times. The game also crashed once without a message; the window just disappeared. I know from experience that JA2 crashes occasionally and there isn't much you can do about it. The game consistently locking up during the computer's turn is new to me, though.
Report message to a moderator
|
Civilian
|
|
|
|
| Re: BUGS: Tais' SCI's[message #303957]
|
Fri, 27 April 2012 06:00
|
|
| JKeenan |
|
Messages:3
Registered:April 2012 |
|
|
After continuing to play the game, we've discovered that this problem has something to do with interrupts, and it happens frequently enough to make JA2 almost unplayable in co-op mode. Any time an interrupt occurs, there is a significant chance that one person's computer will say it's the other player's turn, while that person's computer will say it's still the AI's turn.
I tried to remedy this by changing the BASIC_REACTION_TIME_LENGTH value to 100, which I thought should make interrupts almost impossible. I figured this would significantly change strategy but would at least make the game playable. However, we still got interrupts. I also see something in the INI file about an "improved interrupt system," which I thought might be the cause of the problem, but I see nowhere to turn it on or off.
The next thing I tried was setting a turn timer, figuring that although we might not be able to use all of our interrupts, at least we'd be able to continue the game when the timer ran out. That didn't work either; when the bug occurs, the turn timer doesn't move.
We've started a couple dozen games, and so far, have only finished two. I figure someone else must have encountered this bug at some point. How did you work around it?
Report message to a moderator
|
Civilian
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: BUGS: Tais' SCI's[message #304657]
|
Mon, 14 May 2012 07:37
|
|
| Strohmann |
 |
Messages:287
Registered:August 2011
Location: Division Thought Crimes |
|
|
(SCI_113SVN_r5270_20120512 + WF maps)
is it possible, that the aiming cap calculation is broken again? setting in Items.xml to negative values, even small ones like -1 causes a significant shrinkage of the aiming circle and a jump in muzzle stability.
-5 -> muzzle stability 90/100
-1 -> muzzle stability 90/100
0 -> muzzle stability 70/100 (deleting the tag in Items.xml has same effect)
10 -> muzzle stability 80/100
this bug? (Thread "NCTH Discussion on What Exactly We Have Right Now (as far as XML Tags)"
Toggle SpoilerChrisLPercentCap only increases or decreases the upCap portion of the NCTH muzzle stability calculation. uiCap represents the maximum stability a particular merc can attain assuming perfect conditions and is based on the merc's Lvl, MRK, WIS and DEX, with MRK being weighted 3:1, DEX weighted 2:1 and LVL & WIS both weighted 1:1 (by default). PercentCap is used to modify this cap value. uiCap is then forced to fall within the valid 0-ubMaximumCTH limits. So if you have a uiCap of 97 without a PercentCap modifier, and you're using something that has a PercentCap=10, you end up with a uiCap of 99 (by default). uiCap is them put through further equations to determine the actual maxAim score possible.
As an example, my test merc gets a uiCap of 97 and ends up with a maxAim of 83. The 14 point difference is a result of various factors. If I modify the weapon so that it has PercentCap=10, my merc's uiCap only increases to 99 (ubMaximumCTH) which results in a maxAim of 85.
Now, I do see a bug if you use a negative PercentCap, which is supposed to be absolutely plausible. The uiCap value is a UIN32 value and we use the following equation to include the PercentCap modifier:
uiCap += (uiCap * GetPercentCapModifier( pInHand, gAnimControl[ pSoldier->usAnimState ].ubEndHeight )) / 100;
Because uiCap is an unsigned int, if 'GetPercentCapModifier' returns a -10, and my initial uiCap is 97, I end up with the following:
uiCap += (97 * -10) / 100;
uiCap += (4294966326) / 100;
uiCap += 42949663;
uiCap = 42949760;
Which will get reset to 99 because of ubMaximumCTH
Anyway, after fixing this bug with a simple variable recast, this same test merc ends up with a uiCap of 88 and maxAim of 75 when I set the weapon's PercentCap=-10.
uiCap += (INT32)(uiCap * GetPercentCapModifier( pInHand, gAnimControl[ pSoldier->usAnimState ].ubEndHeight )) / 100;
I'll commit this small fix to the release branch so it's available the next time a build is released.
EDIT: I fixed a similar issue with PercentTargetTrackingSpeed
gievteh
[Updated on: Tue, 15 May 2012 01:16] by Moderator Report message to a moderator
|
Master Sergeant
|
|
|
|
|
|
|
|
|
|
Blog
Search
Help
Members
Register
Login
Home
