|
|
|
|
Re: Bugs: 2014 Official 1.13 Release (7435) with 7609 Update[message #338316]
|
Tue, 16 December 2014 15:27
|
|
Spek |
|
Messages:7
Registered:December 2014 Location: Finland |
|
|
SpekDave near Balime refills the ice cream truck instead of the Hummer if the truck is acquired first. Also, if you get the truck first and later dismiss it after buying the Hummer, Dave stops giving free fuel.
On the other hand, if the Hummer is obtained first, Dave refills it correctly, but doesn't refill the truck in the event that the Hummer's tank is already full, as the code in Tactical\Interface Dialogue.cpp suggests.
Just to suggest a possible fix to my own bug report, I think the problem lies in the ubLoopLimit variable in the FindSoldierByProfileID() function in Tactical\Soldier Profile.cpp:
SOLDIERTYPE * FindSoldierByProfileID( UINT8 ubProfileID, BOOLEAN fPlayerMercsOnly )
{
UINT8 ubLoop, ubLoopLimit;
SOLDIERTYPE * pSoldier;
if (fPlayerMercsOnly)
{
ubLoopLimit = gTacticalStatus.Team[0].bLastID;
}
else
{
ubLoopLimit = MAX_NUM_SOLDIERS;
}
for (ubLoop = 0, pSoldier = MercPtrs[0]; ubLoop < ubLoopLimit; ubLoop++, pSoldier++)
{
if (pSoldier->bActive && pSoldier->ubProfile == ubProfileID)
{
return( pSoldier );
}
}
return( NULL );
}
The vehicle refilling code calls FindSoldierByProfileID(PROF_HUMMER, TRUE), which sets ubLoopLimit to the last index in the player's team. However, the for loop right below it ends before it reaches that value. From what I can tell, the game adds all vehicles at the end of the player's team, making it impossible for the code to actually find the Hummer if the ice cream truck is acquired first. That's also why increasing MAX_NUMBER_PLAYER_VEHICLES fixed the problem, since it ensured that the Hummer was never the very last "soldier" in the team. Therefore, it seems to me that incrementing the loop limit by one should resolve the issue.
ubLoopLimit = gTacticalStatus.Team[0].bLastID + 1;
Report message to a moderator
|
Private
|
|
|
|
|
|
|
|
Re: Bugs: 2014 Official 1.13 Release (7435) with 7609 Update[message #338519]
|
Tue, 23 December 2014 07:24
|
|
Deleted. |
|
Messages:2657
Registered:December 2012 Location: Russian Federation |
|
|
Strange bug - enemy attacked in strategic, but there's no enemy in tactical.
Tested with:
Wildfire 6.07 mod from svn,
r7678 from stable branch
savegame - bug and just before
Description: started new game, alt+O in Omerta, teleported to drassen mine with ctrl+T, killed all enemy with alt+O, trained some militia.
Then enemy attacks sector, the battle starts but there are no enemy soldiers in sector.
If I load another sector and then again load Drassen mine, suddenly all enemy soldiers appear on the map.
Not always reproducible if starting new game, but always with this save.
Started game with the following options:
MAX_NUMBER_PLAYER_MERCS = 32
MAX_NUMBER_PLAYER_VEHICLES = 2
MAX_NUMBER_ENEMIES_IN_TACTICAL = 64
MAX_NUMBER_CREATURES_IN_TACTICAL = 40
MAX_NUMBER_MILITIA_IN_TACTICAL = 64
MAX_NUMBER_CIVS_IN_TACTICAL = 40
MAX_STRATEGIC_ENEMY_GROUP_SIZE = 24
ALLOW_REINFORCEMENTS = FALSE
ALLOW_REINFORCEMENTS_ONLY_IN_CITIES = FALSE
MIN_DELAY_ENEMY_REINFORCEMENTS = 3
The bug disappears if set MIN_DELAY_ENEMY_REINFORCEMENTS = 0
[Updated on: Tue, 23 December 2014 07:55] by Moderator Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
|
Re: Bugs: 2014 Official 1.13 Release (7435) with 7609 Update[message #338858 is a reply to message #335180]
|
Fri, 09 January 2015 11:33
|
|
Spek |
|
Messages:7
Registered:December 2014 Location: Finland |
|
|
According to Tactical\ShopKeeper Interface.cpp, Micky is supposed to pay you extra if he's drunk:
UINT32 EvaluateInvSlot( INVENTORY_IN_SLOT *pInvSlot )
{
UINT32 uiEvalResult = EVAL_RESULT_NORMAL;
FLOAT dPriceModifier;
UINT32 uiBuyingPrice;
//if the dealer is Micky
if( gbSelectedArmsDealerID == ARMS_DEALER_MICKY )
{
INT16 sSoldierID;
sSoldierID = GetSoldierIDFromMercID( armsDealerInfo[ gbSelectedArmsDealerID ].ubShopKeeperID );
if( ( sSoldierID != -1 ) && ( GetDrunkLevel( &Menptr[ sSoldierID ] ) == DRUNK ) )
{
//Micky is DRUNK, pays more!
dPriceModifier = armsDealerInfo[ gbSelectedArmsDealerID ].dSellModifier;
}
else
{
// Micky isn't drunk, charge regular price
dPriceModifier = armsDealerInfo[ gbSelectedArmsDealerID ].dBuyModifier;
}
}
else
{
dPriceModifier = armsDealerInfo[ gbSelectedArmsDealerID ].dBuyModifier;
}
Unfortunately, GetSoldierIDFromMercID() only goes through the player's team, which Micky is not part of, so the function returns -1 and I don't get my money!
INT16 GetSoldierIDFromMercID(UINT8 ubMercID)
{
UINT16 cnt;
UINT8 ubLastTeamID;
SOLDIERTYPE *pTeamSoldier;
cnt = gTacticalStatus.Team[ OUR_TEAM ].bFirstID;
ubLastTeamID = gTacticalStatus.Team[ OUR_TEAM ].bLastID;
// look for all mercs on the same team,
for ( pTeamSoldier = MercPtrs[ cnt ]; cnt <= ubLastTeamID; cnt++,pTeamSoldier++)
{
if ( pTeamSoldier->ubProfile == ubMercID )
{
if( pTeamSoldier->bActive )
return( cnt );
}
}
return( -1 );
}
I'm not sure what would be the best way to fix this, though.
Report message to a moderator
|
Private
|
|
|
|
Re: Bugs: 2014 Official 1.13 Release (7435) with 7609 Update[message #339009 is a reply to message #335180]
|
Sun, 18 January 2015 18:25
|
|
MinotaurZombie |
Messages:2
Registered:October 2014 |
|
|
There's a bug with the latest stable build/bug fix of vanilla 1.13. The SAM sites do not correctly let you train militia. Thankfully its an easy fix after talking with some friends. The xml file for the facilities do not show the SAM sites in it, and by adding them there it works just fine. Thought I would let you guys know.
Report message to a moderator
|
Civilian
|
|
|
|
|
|
Re: Bugs: 2014 Stable 1.13 Release (7435)[message #339936 is a reply to message #339266]
|
Sun, 08 March 2015 12:42
|
|
Marius |
|
Messages:29
Registered:February 2011 Location: Norway |
|
|
Finished a 7609 game yesterday and ran across the following problems:
1. I did not get the offer to speak with Tony after getting rid of Brenda by giving her the video. Hans would only say his line about "Make love not war etc." and then the default "I don't want to talk more" thing. It doesn't matter how many times I returned and whether or not I had high Leadership, he'd say that every day. I found a workaround in blowing up the wall in the room behind him though and just going straight to Tony. Could this have happened because Tony was "out" the day I finished the quest to meet him perhaps?
2. Miguel and Carlos never joined no matter how many towns I had liberated. Just to be safe I saved before talking to them each time and reloaded if they wouldn't join before trying with one more town, but alas, never any result.
3. Skyrider would not refuel his helicopter using the new refuel system and turning it off did not improve things. A lot of walking and ice cream trucking happened as a result. This has been addressed and acknowledged in another thread though.
4. Not sure if bug: I've turned off the RECRUITABLE_JA1_NATIVES thing in the .ini, yet M.E.R.C. was still flooded with JA1 characters. Going by the ini option's name and the description "If set to TRUE, JA1 native guides will appear on MERC website." I'm guessing it only toggles off a very few spesific JA1 mercenaries and thus this is working as intended?
[Updated on: Sun, 08 March 2015 12:43]
Nobody's perfect... I'm a nobody!Report message to a moderator
|
Private 1st Class
|
|
|
|
|
|
|
|
|
|
|
|
Re: Bugs: 2014 Stable 1.13 Release (7435)[message #340202 is a reply to message #340061]
|
Tue, 24 March 2015 22:18
|
|
onewithdeath |
|
Messages:39
Registered:January 2004 |
|
|
Hi, I need your help.
Assertion Failure [Line 2605 in file .\Strategic Movement.cpp]
Group 24 (AI) attempting illegal move from L1 to K1 (GROUNDBARRIER).
Crash comes @ 10:58
A similar problem was solved once:
Toggle SpoilerFlugente helped sevenfm: Flugente wrote on Wed, 17 September 2014 23:00Yes, but that would only fight the symptoms. The problem isn't that we have a group of size 0 that wants to make an invalid move - the problem is that somewhere a group of size 0 was created, and it was ordered to do a invalid move.
You can apply this patch to your exe - it will fix this case of th error - but finding the problem would be better. You could recreate that by loading an older savegame, or around the time the fighting in the SAM took place, and see wether any group is getting such odd values.
I'm not sure if this patch will work for me, or do I need a different one?
Here's my save: http://www.filedropper.com/l1tok1illegalmove
Report message to a moderator
|
Private 1st Class
|
|
|
|
|
|
Re: Bugs: 2014 Official 1.13 Release (7435) with 7609 Update[message #340231 is a reply to message #340215]
|
Thu, 26 March 2015 22:47
|
|
Flugente |
|
Messages:3507
Registered:April 2009 Location: Germany |
|
|
Hmm. This is a very odd error. The group basically arrives at L1 correctly... and then decides to follow its waypoints. Which would be perfectly normal, if those weren't all garbled up. The game tries to fix that by coming up with somewhat good values, which have the nasty sideeffect of leading the group into the ocean, at which point the game decides to hang itself.
Could you uploa a savegame from that campaign, say, 4-8 hours or so earlier? I need to find the place where the waypoints get all messy in ordder to truly fix this...
For now, this savegame is your savegame with the offending group condemned to stay in their sector, which should keep your campaign ongoing. Unless I've uploaded the wrong one, inform me then (and still post what I've asked about earlier, please).
[Updated on: Thu, 26 March 2015 23:03]
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.Report message to a moderator
|
|
|
|