Home » MODDING HQ 1.13 » v1.13 Bug Reports » BUGZILLA report all bugs here!
|
Re: BUGZILLA report all bugs here![message #324098]
|
Sat, 17 August 2013 23:37
|
|
anv |
|
Messages:258
Registered:March 2013 |
|
|
Regarding MERC availability: Yeah, my entire problem with previous system was lack of checking if StartMercsAvailable of merc is set to true, which prevented adding special conditions for certain mercs, like quest outcomes and .ini settings. As for putting mercs in the middle of .xml - order of display on MERC website depends on position there, and it's quite natural mercs should be displayed according to their skills/price, not date of adding them to repository. What I didn't realize was that changing source mid-game (pre-Kulba->post-Kulba) with some new mercs already "unlocked" (not really unlocked, just LaptopSaveInfo.gubLastMercIndex increased) would result in my new function skipping those mercs, hence looping first few mercs instead. Good to see silversurfer fixed this without losing savegame compatiblity. Shame I didn't explain changes better then. Well, apparently haste is a bad advisor.
Bug report:
6287/1729
1. Quitting from tactical immediately to main menu during rain - raining sound keeps on playing.
2. Moonwalk - when you order merc to run and click behind him with alt pressed, he starts running backwards (with animation playing as if he was still running forward - it's especially noticeable when running diagonally). Although considering how hilarious this looks I'm able to accept it as a feature.
Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: BUGZILLA report all bugs here![message #324212]
|
Wed, 21 August 2013 01:28
|
|
LootFragg |
|
Messages:349
Registered:August 2009 Location: Berlin, Germany |
|
|
Edit: Bug from r6239 already solved in r6279.
SolvedGot an interesting one.
Savegame packed as 7z, 200kB: http://www.file-upload.net/download-7988571/JA2Save.7z.html
Also been renamed, you will need to remove the additional information.
Revision 6239.
You will need to change the following values in Ja2_Options.ini from the trunk to start the savegame:
[System Limit Settings]
MAX_NUMBER_PLAYER_MERCS = 32
MAX_NUMBER_PLAYER_VEHICLES = 6
MAX_NUMBER_ENEMIES_IN_TACTICAL = 64
MAX_NUMBER_CREATURES_IN_TACTICAL = 40
For the bug to occur, you will need to set the following parameter in CTHConstants.ini:
[General]
RANGE_COEFFICIENT = 1.55 This can be any value, apparently, equal to 1.55 or higher. Lower values than 1.54 or equal will prevent the bug from happening. Tested values are 1.1, 1.52, 1.53, 1.54, 1.55, 1.6, 1.7, 1.8, 3.0.
Edit: The crucial threshold seems to be between 1.54000002 and 1.54000003.
What you need to do: Load up the savegame, go to the combat in Drassen Mine, end the turn.
What should happen: Enemies will move. Raven will spot one enemy. A female soldier will run around the corner behind the church and charge towards Haywire. The screen will go black and it will output an error message via dialog box, titled "Error", saying "Unhandled exception. Unable to recover."
What will prevent the bug: Either another RANGE_COEFFICIENT value at 1.54 or lower (or somewhere in between 1.54 and 1.55 but I didn't test it further). OR you can load the game, cheat with GABBI, hit Alt+E to see enemies, there will be five soldiers behind the church of whom two soldiers are next to each other closest to the right church corner. Target the outer one that is not directly at the church wall (the woman that will run around the corner) and hit her with Ctrl+H once. She won't have enough AP to get close and the bug won't occur.
Also, I'm very interested in your findings, so if this gets a proper solution, I'd be delighted about a quick PM linking me to the topic. Good hunt! ^^
-------------------
Super Edit: Same phenomenon, new angle. More data.
Savegame: http://www.file-upload.net/download-7988813/JA2Save2.7z.html
1) The range coefficient threshold for the crash depends on GRAVITY_COEFFICIENT as well. Default is 4.0.
With values of 3.238374 and below (tested to 1.0), the RANGE_COEFFICIENT threshold will be between 1.560000002 and 1.560000003.
With values of 3.238375 and higher (tested to 4.3, will change at 4.4 or earlier), the threshold will be between 1.41000002 and 1.41000003.
2) The enemy soldier has a P229R. The target this time seems to be Buzz on the roof of the dental clinic building, weirdly, as Buzz cannot be seen from the position the soldier is on when the game crashes. I have tried the same circumstances with Buzz being left one tile behind or prone so she wouldn't get spotted and the bug didn't happen.
What you need to do to trigger it: Have Razor run 3 tiles along the house wall, PAST the window, not only in front of it.
What should happen: The enemy soldier will get an interrupt when Razor has run past the window, will turn around and run towards the church window to take a peek. The game crashes. If not, Raven will spot her and say a prayer.
This is some AI related calculation but it doesn't seem to require line of sight to the target. But that's just my observation, I won't hypothesize about code.
[Updated on: Wed, 21 August 2013 04:48] by Moderator Report message to a moderator
|
|
|
|
|
|
|
|
Re: BUGZILLA report all bugs here![message #324332]
|
Mon, 26 August 2013 01:04
|
|
LootFragg |
|
Messages:349
Registered:August 2009 Location: Berlin, Germany |
|
|
Problem foundUsing r6312 executable on r1738 repo. If the sector where the ice cream truck was found (in my case D9) is loaded, squads on travel assignments will never arrive at their destination, instead travel indefinitely. As soon as the sector is unloaded, all squads will arrive. Encountered on r6279, upgraded to r6312 to test. Tested with debug (standard trunk) version plus minimum JA2_Options.
Savegame as 7zip. Requires [System Limit Settings]
MAX_NUMBER_PLAYER_MERCS = 32
MAX_NUMBER_PLAYER_VEHICLES = 6
MAX_NUMBER_ENEMIES_IN_TACTICAL = 64
MAX_NUMBER_CREATURES_IN_TACTICAL = 40
Also cheated my squad to the sector, recruited Hamous and sent him driving off. He would also never arrive at any other sector until his former sector got unloaded. Driving everywhere is possible unless D9 is loaded. Also, D9 in my case is fixed, regardless of Hamous being there or not, as long as it is loaded, no squad, ice cream truck or not, will arrive.
Flugente pointed out that there are Bloodcats in the sector which causes the game to think we are in battle, therefore all travel assignments get delayed. Since Bloodcats are supposed to be hidden, there is no warning on time compression like in normal battles, which caused a whole lot of confusion.
Hamous and the Ice Cream Truck being in the sector is a mere coincidence. The point here is the invisible Bloodcats battle with the mercs in the sector.
[Updated on: Mon, 26 August 2013 07:15] by Moderator Report message to a moderator
|
|
|
|
Re: BUGZILLA report all bugs here![message #324333]
|
Mon, 26 August 2013 01:48
|
|
Flugente |
|
Messages:3507
Registered:April 2009 Location: Germany |
|
|
Hmm. Will try tomorrow evening again - so far no luck... instead after a certain point, merc portraits vanish completely, which could indicate possible memory leaks etc.
Edit: This is all very.. bizarre. The error also occurs in older builds (tested with 6219), but without the disappearing portraits.
An odd effect is that it seems to be connected to your merc in D9 (Ears). Simply ordering him to move to another sector leads to normal behaviour, even without loading any other sector.
Edit2: Not entirely true... ordering Ears to move sector causes the sector to unload, after which one can cancel the movement order. The error really is connected to D9 being loaded - and killing hamous and the Truck doesn't help...
Edit3: gaaaaah. Stupid, stupid me. The solution is very simple: Your D9 contains a bloodcat. Bloodcats are hostile. When we are in battle with hostile civilians or bloodcats (not enemies), we delay any arrival by 3-6 minutes, in order not to start another battle. That is okay... the error is that the game should deny time compression with a warning which it doesn't. Not sure if such a warning exists, but it should imho.
I suspect this has sth to do with you not yet knowing of the 'cats. Thus the battle hasn't yet started in the stricter sense, but they are still registering as hostiles.
Solution: Shoot cats :maskedsniper: :blackcat: (it's 3 cats it seems). There's no code fix in the stricter sense, but it should definitely put out a warning and deny time compression.
Report message to a moderator
|
|
|
|
|
Re: BUGZILLA report all bugs here![message #324354]
|
Mon, 26 August 2013 21:45
|
|
Kriplo |
|
Messages:256
Registered:February 2008 Location: Zagreb - Croatia |
|
|
Well I will hardly called them improvements rather bug fixing
Currently not adding anything spectacular new because don't want to add more bugs then they are already there. So only intensively debugging and observe AI behavior, e.g. have function which temporary add all soldiers to my team then manually equip them with all kind of weapons and stuff, after that check if they use them properly, and of course surprisingly find they don't
So here are current fixes and few little changes as I'm wrote them in svn:
- AI will avoid use of last two locations, previously this lead into premature end turn although soldier have plenty of remaining APs.
- Fix problems with improper APs calculations for burst and autofire which lead into AI to forcibly cancel and end turn for those actions.
- Add option for decide to use short autofire instead of one long to enhance chance to hit.
- After taking cover change facing toward closest enemy to avoid going in status red and rather take proper black decisions.
- Fix bad public noise processing after AI investigate closest disturbance and find nothing, also erase all same noise points in team members if one of them already investigated.
- Sometimes AI not fire when target is on roof, happens in situation when previous target was on ground because bLevel was not update.
- Instead to calculate ChanceToHit only from STANDING from now AI calculate chance for all stances, so AI should be more eager to attack.
- Basic support for reducing AI friendly fire during best shot calculation, then AI decide depending of soldier character to fire or take other action. Still in autofire accidentally friendly hits could be higher depending of bullets spreading.
- AI will ignore attack breathless targets if there are other in better condition.
- AI will not fire into dying targets.
- AI should avoid go into creature gas.
- Fix bursting grenades from non burst launcher.
- Not use GL if grenade is already in it
- Not firing from rocket launcher if couldn't find hand grenade.
- Refusing to launch grenade from attached GL if couldn't find grenade in other pockets.
- Never fire from single rocket launchers like LAW.
- Incorrect chance to throw calculation for GLs which lead into no decision to throw.
- Whole cylinder of grenades was permanently remove from pocket after reloading launcher.
If you play game with OCTH then you will see little improvements as AI is more eager to fire upon, but in NCTH as play above savegame from LootFrag AI didn't attack at all, because all CTH is zero, but after switching to OCTH they became far more aggressive.
BTW playing those save under debug, game is terrible slow, after you press end turn few seconds pass before AI start his movement then if you get interrupt and press end turn again same story, please could anybody confirm that problem?
Report message to a moderator
|
Master Sergeant
|
|
|
|
|
|
|
|
Re: BUGZILLA report all bugs here![message #324381]
|
Tue, 27 August 2013 20:25
|
|
Kriplo |
|
Messages:256
Registered:February 2008 Location: Zagreb - Croatia |
|
|
@DepressivesBrot,
Check tanks, and find out you are right, they still burst shells although decision was to burst from machine gun, there are plenty bugs from bad APs calculation, improper weapon handling/switching, unlimited ammo, chance to hit seems always return 99, and some not tank related problem with autofire switch and shot calculation if primary gun is not already in HANDPOS.
The latest one don't know how to fix is related to tank burst animation, obviously it's old one where autofire is fixed to 6, so for now solution is to hardcode to 6, because any other value will mess APs deduction, bad animation and they still will fire just 6.
Report message to a moderator
|
Master Sergeant
|
|
|
Re: BUGZILLA report all bugs here![message #324384]
|
Tue, 27 August 2013 20:40
|
|
Kriplo |
|
Messages:256
Registered:February 2008 Location: Zagreb - Croatia |
|
|
silversurferKriplo
If you play game with OCTH then you will see little improvements as AI is more eager to fire upon, but in NCTH as play above savegame from LootFrag AI didn't attack at all, because all CTH is zero, but after switching to OCTH they became far more aggressive.
I believe that somewhere I have seen that with NCTH when a target is outside gun range the chance to attack is zero. CTH is not zero in that case so I think that it would be reasonable to implement a certain chance to attack, maybe a calculation that considers how far outside of gun range the target is. At the moment I'm just too busy with work to really look into the code.
Kriplo
BTW playing those save under debug, game is terrible slow, after you press end turn few seconds pass before AI start his movement then if you get interrupt and press end turn again same story, please could anybody confirm that problem?
I can confirm that playing in debug mode is slow. Starting the game already takes much longer. I got used to it somehow. :whoknows:
NCTH is new stuff I don't know how it works but AI from AICalcChanceToHitGun always have zero and yes it's outside gun range, e.g. have pistol and is 13 tiles away, but in OCTH he will fire as CTH is not zero.
Yes debug is always been slow but currently is very bad even with Core i7 3770K, but this end turn is strange one, if you get time just load LootFrag savegame and after end turn always there is pause of 3,4 seconds.
To improve game start does anybody plan to create XML resource compiler inside game which will compile just out of date XMLs and already compiled will be in binaries again instead every time parse whole XML bunch?
Report message to a moderator
|
Master Sergeant
|
|
|
|
|
|
|
|
Re: BUGZILLA report all bugs here![message #324394]
|
Wed, 28 August 2013 14:18
|
|
pheloncab |
|
Messages:278
Registered:August 2004 Location: So. Cal. or texas |
|
|
Running 6322 + AFS.
Hamous is in Drassen airport, set to move items to Drassen Mine.
I took the rest of my mercs out, took over the SAM site, then explored a little and wandered back to the mine.
~ full day of time passed, 0 items have moved. my ini uses 30min blocks instead of 45 for counting assignments, if that changes anything with this particular one.
Edit:
moved 3 more mercs(imps) to B13, set them to move to D13.
checked the move item toggle on strategic inventory screen, no items are hashed out as unmovable.
timed forward 6 hours. no items moved.
Edit again:
got it working. you have to set it to bring items to the merc, and yet save the items you wanna keep by sector..
Amazing what happens when you try again after sleep.
[Updated on: Wed, 28 August 2013 20:34] by Moderator Report message to a moderator
|
Master Sergeant
|
|
|
|
|
|
|
|
|
Pages (42): [ 19 ] |
|
Goto Forum:
Current Time: Sun Jan 05 00:19:26 GMT+2 2025
Total time taken to generate the page: 0.04262 seconds
|