Home » PLAYER'S HQ 1.13 » JA2 Complete Mods & Sequels » Stracciatella Project (Platform Independent JA2) » Bug in shop keeper interface
|
|
| Re: Bug in shop keeper interface[message #261521]
|
Sat, 04 September 2010 00:09  
|
|
 mgl |
 |
Messages:255
Registered:December 2007
Location: France |
|
|
sunshineIf you put the money, you got for selling in a shop keeper interface, to your account, it remains at the cursor.
I noticed it a long time ago but never investigated. The money may even be credited to your account while it still remains on the cursor and can be credited a second time in the tactical screen when you leave the shopkeeper, I don't remember. The problem may simply be that the cash item on the cursor is not destroyed when clicked on the "add to account" button.
sunshineAlso the shop keeper interface does not refresh properly.
I have refresh problems in the tactical screen since the first quarter of 2009. For example, animations like crows eating a corpse are displayed over the mercs status bars, items taken on the cursor from the merc inventory stay on the inventory while they are on the cursor, parts of the items (red and green stars, status bars) are displayed over the long description of the gun (right click on gun). There is a problem with the dirty rectangles, maybe a request to update them is missing. Sometimes I have the impression that the update request is not triggered because there is no mouse or keyboard event to pump out of the events queue.
sunshineIs there a way to get back older versions of the source code somewhere?
The svn repository should let you download the revision that you want.
Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
| Re: Bug in shop keeper interface[message #261819]
|
Mon, 06 September 2010 23:49
|
|
| mgl |
|
Messages:255
Registered:December 2007
Location: France |
|
|
sunshine1. tactical bars next to merc faces are not drawn if animations happen at the same place of the clipped tactial map
2. ammo numbers are not displayed in tactical inventory if animations happen at the same place of the clipped tactial map
[...]
Edit: Bug no. 2 started with r6158.
Edit2: Fixed bug 1 and 2 by undoing the changes of r6158.
Bug 1 is the bars and the name for me, in the single merc panel. And I think I have snapshots of blank dirty rectangles overlapping the merc stats too.
Although r6158 updates two requests to mark the merc panel as dirty in the file "Weapons.cc", it doesn't seem obvious to me that the changes can cause the display problem.
sunshine3. spike does not enter the club for summoning kingpin when the player wants to fight
It happens to me too, but it's rare.
Boxing fights are madnes in my game: once you are on the ring, you have to leave it and start the fight outside to fetch your opponent, who will otherwise not enter the ring. He will then enter the ring and fight back if you enter the ring too. You can use firearms to defeat him and you're never paid. Kingpin must avoid a precise gridno on his path when he comes or the game will enter an endless loop. If you end a fight with a knock out, the boxers will crouch but never stand up and the game will enter an endless loop. But everything is fine in a new game (and was fine for several months)!
sunshine5. LOS display non functional
Tron explained it in this thread: Missing cover/los graphic
sunshine9. civilians seem to be missing in early game, e.g. the brothel guard in san mona
At least two other persons reported about this but I have never seen it myself. On the other hand, I am playing with the same game since march 2009 and only start new games to test things, not to play.
Report message to a moderator
|
|
|
|
|
|
|
| Re: Bug in shop keeper interface[message #261991]
|
Wed, 08 September 2010 20:40
|
|
| mgl |
|
Messages:255
Registered:December 2007
Location: France |
|
|
Maybe you can try the following patch on the current subversion release to fix the display problem on the bars and stacked items of the mercs panel in the tactical screen.
It simply forces a comparison between signed ints rather than between unsigned and signed ones, where you need to have in memory half a page of C book and addendum and errata to understand what the compiler will do with the comparison.
It seems to work for me. And it seems that the problem was "gsVIEWPORT_WINDOW_END_Y - sYPos", maybe it can become negative (which means a very big number when seen as a positive integer if the compiler decides to cast it to an unsigned number).
tactical_display_merc_bars.diff:
Index: Build/TileEngine/RenderWorld.cc
===================================================================
--- Build/TileEngine/RenderWorld.cc (revision 7072)
+++ Build/TileEngine/RenderWorld.cc (working copy)
@@ -1188,7 +1188,7 @@
sXPos += pTrav.sOffsetX;
sYPos += pTrav.sOffsetY;
- INT16 const h = MIN(uiBrushHeight, gsVIEWPORT_WINDOW_END_Y - sYPos);
+ INT16 const h = MIN((INT16) uiBrushHeight, gsVIEWPORT_WINDOW_END_Y - sYPos);
RegisterBackgroundRect(uiDirtyFlags, sXPos, sYPos, uiBrushWidth, h);
if (fSaveZ)
{
Report message to a moderator
|
|
|
|
|
|
|
|
|
| Re: Bug in tactical real time[message #262049]
|
Thu, 09 September 2010 19:53
|
|
| public1983 |
 |
Messages:125
Registered:February 2006 |
|
|
Your patch works. Great! Thanks for caring about Trons work, while he is absent.
The problem with timing in real-time seems to be limited to sectors, which are entered without battle. To reproduce it, just hire Red and Gus, flee from Omerta and plant a bomb in the prairie. It will explode instantly. Or shoot at Gus. He will bleed very fast. I have changed nothing in this system, so it must be inherent with r7072.
Edit: I have just compiled a fresh svn update. The bug is reproducible. Should I publish a savegame? Maybe I look at the code and see.
Edit2: I can reproduce the bug with Cinnamon. That is strange. Should it have crept in so early and still unnoticed?
Edit3: Somehow the time compression is not cancelled when HandleStrategicTurns() updates the time.
if ( giTimeCompressMode == TIME_COMPRESS_X1 || giTimeCompressMode == 0 ) //Not true, when the bug happens.
{
uiCheckTime = NUM_REAL_SEC_PER_TACTICAL_TURN;
}
else
{
// OK, if we have compressed time...., adjust our check value to be faster....
if( giTimeCompressSpeeds[ giTimeCompressMode ] > 0 )
{
uiCheckTime = NUM_REAL_SEC_PER_TACTICAL_TURN / ( giTimeCompressSpeeds[ giTimeCompressMode ] * RT_COMPRESSION_TACTICAL_TURN_MODIFIER );
}
else
{
abort(); // XXX HACK000E
}
}
Edit4: I have found a patch. Somehow there is a vital line commented out in GameScreen.cc:
void EnterTacticalScreen(void)
{
...
- //SetGameTimeCompressionLevel( TIME_COMPRESS_X1 );
+ SetGameTimeCompressionLevel( TIME_COMPRESS_X1 );
...
}
[Updated on: Thu, 09 September 2010 20:33] by Moderator Report message to a moderator
|
Sergeant
|
|
|
|
|
|
|
|
| Re: Bug in tactical real time[message #262151]
|
Fri, 10 September 2010 23:18
|
|
| mgl |
|
Messages:255
Registered:December 2007
Location: France |
|
|
sunshineAre You working with Linux? I use Windows. Maybe this can explain the different appearance of bugs. I suspect Tron has not really tested with Windows.
I'm on Linux. I think bbun is on Mac OS X, Tron on BSD.
sunshineThe timing-bug is reproducible with cinnamon so it is independent of r6753. My patch is tested to be working with r7072.
sunshineTo reproduce it, just hire Red and Gus, flee from Omerta and plant a bomb in the prairie. It will explode instantly. Or shoot at Gus. He will bleed very fast.
I can't reproduce it at will. I tried more than 10 times but the bug never happened.
But in my current game, the helicopter took my mercs after a battle on the road southwest of Balime and dropped them in Tixa, which is owned by me, and the real time was accelerated when I loaded the tactical screen there. But when I reloaded from the latest save to try again, everything was fine.
If you manage to trigger the bug each time or most of the time, it may be because we don't load A9 and flee the sector to A10 the same way. I clicked on the time compression button to load A9. All what I did in the sector was select all the mercs with the "=" key and double click on the right edge so that they run there and traverse to A10.
While I was doing the tests, I checked the bug in "FindReplacementMagazine()" that you reported in this thread.
Report message to a moderator
|
|
|
|
|
| Re: Bug in tactical real time[message #262210]
|
Sat, 11 September 2010 14:46
|
|
| public1983 |
|
Messages:125
Registered:February 2006 |
|
|
mglI'm on Linux. I think bbun is on Mac OS X, Tron on BSD.
So this might cause a different (type-casting?) behaviour of the compiler, doesn't it?
mglBut in my current game, the helicopter took my mercs after a battle on the road southwest of Balime and dropped them in Tixa, which is owned by me, and the real time was accelerated when I loaded the tactical screen there. But when I reloaded from the latest save to try again, everything was fine.
Just as the patch suggests. When you enter a sector in time-compression and without the battle interface, it is not cancelled. For me the bug is also persistent after reloading.
mglIf you manage to trigger the bug each time or most of the time, it may be because we don't load A9 and flee the sector to A10 the same way. I clicked on the time compression button to load A9. All what I did in the sector was select all the mercs with the "=" key and double click on the right edge so that they run there and traverse to A10. Did You enter A10 in tactical screen? In this case, the time compression is not triggered, because the game blends over to the next sector. Leaving to the west is what I meant with "in the prairie".
mglWhile I was doing the tests, I checked the bug in "FindReplacementMagazine()" that you reported in this thread. Could You reproduce it?
The trip flares cease to function with r5901 under windows. I will see if it is easy to fix.
Edit: It is. There is a typo at Build\Tactical\FOV.cc
+ if (gubWorldRoomInfo[marker] != NO_ROOM || TypeRangeExistsInRoofLayer(marker, FIRSTROOF, FOURTHROOF) == NULL)
- if (gubWorldRoomInfo[marker] != NO_ROOM || TypeRangeExistsInRoofLayer(marker, FIRSTROOF, FOURTHROOF))
{
gpWorldLevelData[ marker ].uiFlags |= MAPELEMENT_REVEALED;
if( gfCaves )
{
RemoveFogFromGridNo( marker );
}
}
Before the change of the return type of TypeRangeExistsInRoofLayer from bool to struct-pointer it was
...
- if (gubWorldRoomInfo[marker] != NO_ROOM || !TypeRangeExistsInRoofLayer(marker, FIRSTROOF, FOURTHROOF))
...
so a check for NULL seems to be appropriate. No guaratee that this is good style though.
[Updated on: Sat, 11 September 2010 15:03] by Moderator Report message to a moderator
|
Sergeant
|
|
|
|
| Re: Bug in tactical real time[message #262264]
|
Sat, 11 September 2010 20:42
|
|
| mgl |
|
Messages:255
Registered:December 2007
Location: France |
|
|
sunshineSo this might cause a different (type-casting?) behaviour of the compiler, doesn't it?
No.
sunshineDid You enter A10 in tactical screen? In this case, the time compression is not triggered, because the game blends over to the next sector. Leaving to the west is what I meant with "in the prairie".
Yes, I escaped to A10 through tactical screen without going to strategic screen. Now I tried to escape to the south several times and still didn't manage to trigger the bug. I used the first compression level only (5 mins I think) to compress time.
sunshineThe trip flares cease to function with r5901 under windows. I will see if it is easy to fix.
I thought you meant the break lights.
I was so surprised to see the cave light itself like the city of "Stargate: Atlantis" while the mercs were exploring it!
The bug was so old that I had forgotten how it was before!
Edit 1,2: I think you should dedicate a new thread to the fix of this bug, or some people will probably miss it (if someone else plays stracciatella). "== NULL" or "!TypeRangeExists...()" are the same but I think Tron would prefer "!TyPeExists...()" while I would prefer "== NULL" . But don't care for that, Tron never takes a fix as it is but always rewrites it his way.
sunshine
mglWhile I was doing the tests, I checked the bug in "FindReplacementMagazine()" that you reported in this thread. Could You reproduce it?
Yes, I left a message in that thread.
[Updated on: Sun, 12 September 2010 09:04] by Moderator Report message to a moderator
|
|
|
|
|
|
|
| Re: Bug in tactical real time[message #277186]
|
Sun, 03 April 2011 15:30
|
|
| misanthropos |
 |
Messages:14
Registered:October 2009 |
|
|
Hi!
I have a fix for the Money issue. Is there any "official" svn/git - tree to submit patches?
Meanwhile here is the patch:
ja2-shopkeeper-money.patch
Index: Build/Tactical/Interface_Panels.cc
===================================================================
--- Build/Tactical/Interface_Panels.cc (revision 7072)
+++ Build/Tactical/Interface_Panels.cc (working copy)
@@ -3613,10 +3613,15 @@
//add the money to the players account
AddTransactionToPlayersBook( MERC_DEPOSITED_MONEY_TO_PLAYER_ACCOUNT, gpSMCurrentMerc->ubProfile, GetWorldTotalMin(), gpItemPointer->uiMoneyAmount );
+ EndItemPointer( );
+ // remove contents of the moving item because object still is money and usable
+ // you could add endlessly money to your bank account if not reset properly
+ memset( &gMoveingItem, 0, sizeof( INVENTORY_IN_SLOT ) );
+ SetSkiCursor( CURSOR_NORMAL );
// dirty shopkeeper
gubSkiDirtyLevel = SKI_DIRTY_LEVEL2;
- EndItemPointer( );
+
}
}
Report message to a moderator
|
Private
|
|
|
|
Goto Forum:
Current Time: Tue Apr 16 07:45:31 GMT+3 2024
Total time taken to generate the page: 0.02050 seconds
|
Blog
Search
Help
Members
Register
Login
Home
