Home » PLAYER'S HQ 1.13 » JA2 Complete Mods & Sequels » Stracciatella Project (Platform Independent JA2) » Bug in shop keeper interface
Bug in shop keeper interface[message #261508] Fri, 03 September 2010 21:52 Go to next message
public1983

 
Messages:127
Registered:February 2006

There is a bug in the latest svn version. If you put the money, you got for selling in a shop keeper interface, to your account, it remains at the cursor. Also the shop keeper interface does not refresh properly. In Cinnamon this bug does not happen. Has anyone solved this problem already? Is there a way to get back older versions of the source code somewhere? It seems to me, that this bug has to do with the sgp part of the code, but not for sure...
Re: Bug in shop keeper interface[message #261521] Sat, 04 September 2010 00:09 Go to previous messageGo to next message
mgl

 
Messages:254
Registered:December 2007
Location: France
sunshine
If 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.

sunshine
Also 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.

sunshine
Is 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.

Re: Bug in shop keeper interface[message #261550] Sat, 04 September 2010 15:57 Go to previous messageGo to next message
public1983

 
Messages:127
Registered:February 2006

Nice. I got used to ignoring the tactical refresh problem. Do you know which revision introduced these bugs? It must be possible to determine the changes that do not work. I have not been following the progress of stracciatella for quite some time.

Edit1: The shop keeper interface bug came with r6755, which I found by bisection. The display problem has been introduced before.

Edit2: I fixed the bug by reverting the change of r6755. There must be some missunderstanding of the ja2 design when exchanging the interface flags for screen indicators. This kind of work is exhausting. I do not plan on looking at the other problem very soon. The most time consuming part of this would be again the determination of the revision which introduced the problem.

[Updated on: Sat, 04 September 2010 22:27] by Moderator

Re: Bug in shop keeper interface[message #261610] Sun, 05 September 2010 00:36 Go to previous messageGo to next message
mgl

 
Messages:254
Registered:December 2007
Location: France
sunshine
Do you know which revision introduced these bugs?

No, but from emails I sent to Tron, I had problems with the tactical screen in august 2009, not in the first quarter. The mouse regions on the mercs faces were wrong and clicking on them had no effect. The dirty rectangles were probably a minor bug compared to that.

I think the time matches the revisions you found. It was a time of major changes in Stracciatella with a better working editor, data files converted to lower case, enemies could climb roofs ... After that, development was halted. It could explain why some bugs were ignored.


sunshine
Edit2: I fixed the bug by reverting the change of r6755. There must be some missunderstanding of the ja2 design when exchanging the interface flags for screen indicators.

I watched the differences and understand what you mean (I suppose that it's the refresh problem in the shopkeeper interface which was fixed). It could mean that the dirty rectangles on the tactical screen are marked to be redrawn but not redrawn for the same reason of flags vs screen ids. It could be worth to undo the changes from 6754 too.

Re: Bug in shop keeper interface[message #261629] Sun, 05 September 2010 10:17 Go to previous messageGo to next message
public1983

 
Messages:127
Registered:February 2006

Well I will not look at r6754 any soon. I try to look only at easy to fix and visible bugs and that from time to time. I am not capable of carrying on Trons code optimization, for I have little more than half a year with significant spare time to look at Jagged Alliance 2.

Further bugs I found so far are
1. 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
3. spike does not enter the club for summoning kingpin when the player wants to fight
4. underground flares do not ignite
5. LOS display non functional
6. br's price calculation for price with final digit 5 displays the digits 5 and 0 on top of each other
7. br's delvery queue contains empty entry
8. prone stance impossible at certain orientations at certain maps next to an obstacle
9. civilians seem to be missing in early game, e.g. the brothel guard in san mona
10. buttons (end turn, goto map, change team) are drawn on top of mapscreen after tactical defeat

The first five seem to be introduced by the stracciatella changes. Is anything of that already adressed by other people using the svn version?

Edit: Bug no. 2 started with r6158.

Edit2: Fixed bug 1 and 2 by undoing the changes of r6158.

Edit3: I do not mean r6158, but r5158.

[Updated on: Tue, 07 September 2010 23:05] by Moderator

Re: Bug in shop keeper interface[message #261819] Mon, 06 September 2010 23:49 Go to previous messageGo to next message
mgl

 
Messages:254
Registered:December 2007
Location: France
sunshine
1. 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.


sunshine
3. 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)!


sunshine
5. LOS display non functional

Tron explained it in this thread: Missing cover/los graphic


sunshine
9. 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.

Re: Bug in shop keeper interface[message #261908] Tue, 07 September 2010 21:35 Go to previous messageGo to next message
public1983

 
Messages:127
Registered:February 2006

The revision which introduced the display bug is r5158. Sorry for the typo. Shame on me, copy and paste dublicated it! It's where Tron changed Quote:
Pass width and height instead of right and bottom to RegisterBackgroundRect().


Thanks for the hint on the cover display. I will check that.

Edit: My installation was an early version. I applied a patch and now the cover display is fine.

[Updated on: Tue, 07 September 2010 23:03] by Moderator

Re: Bug in shop keeper interface[message #261991] Wed, 08 September 2010 20:40 Go to previous messageGo to next message
mgl

 
Messages:254
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)
 								{

Re: Bug in tactical real time[message #262000] Wed, 08 September 2010 23:24 Go to previous messageGo to next message
public1983

 
Messages:127
Registered:February 2006

Thanks. I will try that out.

In the meantime I have played a bit and stumbled upon an annoying because leathal bug. Events like bleeding and bomb ticking happen in no-time in non-hostile sectors. That means, if a merc is wounded, it is almost impossible to bandage him, before bleeding to death. Furthermore, what gave me the hint, timed bombs explode instantly. So neither Kingpin nor the Hicks can be surprised by a series of timed explosions because the demolition man explodes instantly.

Edit: About the patch... How can I apply it without interference with my other modifications? Should I delete only the important files and check-out the repository? Or has Tortoise some function to let you decide what to change at check-out? I have not yet used SVN productively.

[Updated on: Wed, 08 September 2010 23:30] by Moderator

Re: Bug in tactical real time[message #262005] Thu, 09 September 2010 00:28 Go to previous messageGo to next message
mgl

 
Messages:254
Registered:December 2007
Location: France
sunshine
Events like bleeding and bomb ticking happen in no-time in non-hostile sectors.

That must be rather new because I destroyed portions of the wall around the Cambria High School and some walls at Tixa in real time in my game and I always had the time to move to a safe place, even with the fastest timer. An I always can pick my mercs one by one and ask them to bandage themselves once a battle is over and the game goes back to real time.

But I have seen the tactical screen in real time go very fast, with mercs walking faster than if they were running. I think that the bomb timer would have detonated immediately too in such a case.


sunshine

Edit: About the patch... How can I apply it without interference with my other modifications? Should I delete only the important files and check-out the repository? Or has Tortoise some function to let you decide what to change at check-out? I have not yet used SVN productively.


If you want to keep a copy of your 8 files to r5157, you should backup them or make a copy of your working copy. Delete them from the copy and update the copy to the latest svn revision (you may have to use "svn switch" instead of "svn update"). All the changes you could have done to any other source file unrelated to the display bug should be merged by svn. Add the "(INT16)" cast to the new "Render_World.cc" file and see. If it works, you don't need those 8 files anymore.

Of course, you shouldn't delete the 8 files rolled back to r5157 before you check out the repository if you have written any code unrelated to the display bug in them. For example I have changed some code in "Render_World.cc" for the items outline in the tactical screen and I can't destroy it and download a fresh revision (5157 or current), otherwise my changes are lost, I have to "update" it to keep my changes.

Re: Bug in tactical real time[message #262049] Thu, 09 September 2010 19:53 Go to previous messageGo to next message
public1983

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

Re: Bug in tactical real time[message #262054] Thu, 09 September 2010 23:05 Go to previous messageGo to next message
mgl

 
Messages:254
Registered:December 2007
Location: France
sunshine
4. underground flares do not ignite

I tried them in the San Mona mine today an they worked (r7072) !?


sunshine
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?

It was noticed but I couldn't reproduce it at will. I will try what you said.


sunshine
Edit4: I have found a patch. Somehow there is a vital line commented out in GameScreen.cc:

It looks too easy ... But you never know. For example everything was there to make the enemies climb roofs but it was included by mistake in a block of code to ignore if I remember well what Tron said.

I will try your fix too but I would like to know on which revision you applied it: the files from r6753 with screens managed by flags or the ones from the current revision with screens managed by "id" ?

Re: Bug in tactical real time[message #262098] Fri, 10 September 2010 11:46 Go to previous messageGo to next message
public1983

 
Messages:127
Registered:February 2006

mgl
I will try your fix too but I would like to know on which revision you applied it: the files from r6753 with screens managed by flags or the ones from the current revision with screens managed by "id" ?


The timing-bug is reproducible with cinnamon so it is independent of r6753. My patch is tested to be working with r7072.

I will check the flares again. I postponed it, because they rather matter in scifi mode and I actually play in realistic.

Edit: The flares are ok in Liquorice and broken in Walnut. Looks like one of those revision detections again. Let's see...

Edit2: mgl
I tried them in the San Mona mine today an they worked (r7072) !?
Are 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.

[Updated on: Fri, 10 September 2010 22:04] by Moderator

Re: Bug in tactical real time[message #262151] Fri, 10 September 2010 23:18 Go to previous messageGo to next message
mgl

 
Messages:254
Registered:December 2007
Location: France
sunshine
Are 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.


sunshine
The timing-bug is reproducible with cinnamon so it is independent of r6753. My patch is tested to be working with r7072.

sunshine
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 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.

Re: Bug in tactical real time[message #262210] Sat, 11 September 2010 14:46 Go to previous messageGo to next message
public1983

 
Messages:127
Registered:February 2006

mgl
I'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?

mgl
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.

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.

mgl
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.
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".

mgl
While 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

Re: Bug in tactical real time[message #262264] Sat, 11 September 2010 20:42 Go to previous messageGo to next message
mgl

 
Messages:254
Registered:December 2007
Location: France
sunshine
So this might cause a different (type-casting?) behaviour of the compiler, doesn't it?

No.


sunshine
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".

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.


sunshine
The 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

mgl
While 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


Re: Bug in tactical real time[message #263404] Thu, 23 September 2010 23:25 Go to previous messageGo to next message
mgl

 
Messages:254
Registered:December 2007
Location: France
Back to the topic, on the "deposit money" problem in the shopkeeper interface, the function "EndItempointer()" has the code to manage it (I don't remember in which file it is). The code is activated if the current screen ("guiCurrentScreen" variable) is "SHOPKEEPER_INTERFACE_SCREEN". Unfortunately, the "current screen" is the Yes/No message box which asks if you really want to deposit money. When the screens were managed with flags, a memory of the shopkeeper interface existed there and the code tested it rather than the current screen.

Re: Bug in tactical real time[message #277186] Sun, 03 April 2011 15:30 Go to previous message
misanthropos

 
Messages:13
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( );
+
}
}

Previous Topic: Strac on OpenPandora console - Portable JA2!
Next Topic: ja2 stracciatella development
Goto Forum:
  


Current Time: Mon Jun 26 01:24:12 EEST 2017

Total time taken to generate the page: 0.00854 seconds