FS#1847 - Qeustion Marks appearing on map and buttons

Attached to Project: OpenTTD
Opened by Chris (Chris) - Tuesday, 11 March 2008, 17:21 GMT
Type Bug
Category Interface
Status Closed
Assigned To No-one
Operating System Windows
Severity High
Priority Normal
Reported Version trunk
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Problem Version: r11359
Compiler: Visual Studio 2008 Professional

When I am compiling r12359 Source without modifications I see a lot of question marks. I had the same problem with my current ChrisIN r11485 and first thought it's a ChrisIN problem, but now I even see these question marks on an unmodified, up to date source. Any ideas?

I deleted everything from /data except the files which are really necessary
I removed everything from /lang except the files created by the compiler for the current build
I removed the .cfg file so the game recreates a clean file
I removed any non original files from the directory OpenTTD seen in the screenshot

Problem, see screenshot attached.

Hope anyone can help :)
This task depends upon

Closed by  Loïc GUILLOUX (glx)
Saturday, 15 March 2008, 22:43 GMT
Reason for closing:  Fixed
Additional comments about closing:  In r12375. Thanks for the patch.
Comment by Yorick (yorick) - Tuesday, 11 March 2008, 17:22 GMT
Have you tried to download openttd.grf again?
Comment by Loïc GUILLOUX (glx) - Tuesday, 11 March 2008, 17:22 GMT
Are you using svn to get the source?
Comment by Chris (Chris) - Tuesday, 11 March 2008, 17:24 GMT
I deleted openttd.grf and recopied the latest file version in the /data dir yep.

I am using SVN Repository to get the source code (TortoiseSVN). The green icon verifies that I have a clean checkout in this folder with no modifications.
Comment by Yorick (yorick) - Tuesday, 11 March 2008, 17:26 GMT
The revision detection should be able to work with TortoiseSVN, shouldn't it?
Comment by Loïc GUILLOUX (glx) - Tuesday, 11 March 2008, 17:27 GMT
Then you seem to have a problem with determineversion.vbs. It should create src/rev.cpp from src/, replacing some placeholders with the correct data fetched from TortoiseSVN.
Comment by Yorick (yorick) - Tuesday, 11 March 2008, 17:33 GMT
It seems like a problem with openttdw.grf:
locks, canals, foundations, up&down buttons are all in it.
Comment by Loïc GUILLOUX (glx) - Tuesday, 11 March 2008, 17:34 GMT
@Yorick: no it's a problem in rev.cpp
Comment by Chris (Chris) - Tuesday, 11 March 2008, 17:59 GMT
The revision detection never worked for me on Windows with MSVC. My modified ChrisIN rev.cpp with hardcoded revision works but not the original file with auto detection. But that is not related to this problem anyway.

Just re-downloaded the latest beta .zip to get the .grf file instead of using the one from SVN Repository, but that didn't solve the issue. Even when I download a fresh install I get this error, that is very strange, and I was thinking this is a problem of ChrisIN for weeks now. Maybe I should have checked a clean checkout prior to trying to fix ChrisIN and see if I got the same problem there which in fact is the case :/

Comment by Chris (Chris) - Tuesday, 11 March 2008, 18:00 GMT
When I use the beta .exe I don't have the problem. So this is an issue with MSVC building maybe?
Comment by Yorick (yorick) - Tuesday, 11 March 2008, 18:02 GMT
Are you using 64-bit? Another bug said that that a problem for failing revision check.
The grf from the beta could be different than the one from SVN, because it gets updated.
In your hardcoded rev, do you update _openttd_newgrf_version aswell?
Comment by Jean-Francois Claeys (Belugas) - Tuesday, 11 March 2008, 18:03 GMT
nope, it works well with me.
The grf is not the problem.
The revision detection is
Just for sake of convenience, try to install svn. Don't need to use it, just... install it.
I have both (tortoise + svn) and it's a winning combination.
Maybe it will solve the problem.
Or maybe it's the VB script that fails, like you blocked VBS processing?
Comment by Loïc GUILLOUX (glx) - Tuesday, 11 March 2008, 18:03 GMT
The issue is you have a wrong value in rev.cpp line 37.
In it is : uint32 _openttd_newgrf_version = 0 << 28 | 6 << 24 | 0 << 20 | 0 << 19 | (@@REVISION@@ & ((1 << 19) - 1));
In rev.cpp @@REVISION@@ should be replaced by the actual revision.
Comment by Chris (Chris) - Tuesday, 11 March 2008, 18:05 GMT
So you mean the missing _openttd_newgrf_version is the problem? I will try your solution :)

I am using a 64-bit OS (due to too much RAM for 32-bit) but the compiler is 32-bit and I am building a 32-bit version respectively.
Comment by Yorick (yorick) - Tuesday, 11 March 2008, 18:07 GMT
If you are really using a 64-bit OS, then  FS#1831  could have to do with it.
Comment by Loïc GUILLOUX (glx) - Tuesday, 11 March 2008, 18:08 GMT
Ho you didn't say you were on win64 :)
Your problem is indeed known (check  FS#1831 ). We probably can't do anything about it.
Comment by Chris (Chris) - Tuesday, 11 March 2008, 18:15 GMT
Yo the 0 here "... (0 & ((1 << 19) - 1));" is the probem. Installing 32-bit TortoiseSVN (that was 64-bit as well) in addition to the 64-bit version made MSVC create a correct rev.cpp file (this must be deleted before rebuilding as a little side note, which is a little disturbing but ok). And last but not least, the graphic bug is fixed so this topic here can be marked as solved :)

Back to ChrisIN updating *yay*
Comment by Chris (Chris) - Tuesday, 11 March 2008, 18:17 GMT
P.S. I really absolutely have super zero clue ;) what the version of TortoiseSVN has to do with MSVC revision detection :) anyway, it's fixed with 32-bit SVN.
Comment by Loïc GUILLOUX (glx) - Tuesday, 11 March 2008, 18:19 GMT
It's all explained in  FS#1831 . determineversion.vbs ran from MSVC fails to retrieve the installation path of tortoise because of some windows registry magic.

For your information, the grf checks for OTTD version greater than 0.6.0 r11432 and having 0 in @@REVISION@@ make it fails.
Comment by Sylvain Devidal (MagicBuzz) - Tuesday, 11 March 2008, 22:15 GMT
I see on you screenshot you use Windows Vista.

This new version of Windows produce many strange things with files updated by the programs.
In fact, Microsoft decided the Program Files folder was a protected system folder, and not any program should be able to write in it.

As a result, you might find a folder in your profile named "VirtualStore". In this folder, you'll find the OpenTTD folder, containing any updated version off any file. So even when you cleanup the program folder, you don't really cleanup the files used by the game itself. Feel free to delete the OpenTTD folder in the VirtualStore folder.

On an english system it's here :

c:Users<you screen name>AppDataVirtualStoreProgram Files

Next, check in your "My Documents" folder. You'll see many files used by OTTD in a folder named "OpenTTD".
Last time I tried to compile (on Windows XP), I was surprised to not find any GRF or CFG file in my Program Files folder... And found everything in this folder.

I'm pretty sure everyone here is true : your openttd.grf is ok, but the file the program uses is just not the one you checked ;)
Comment by Chris (Chris) - Tuesday, 11 March 2008, 22:46 GMT
It's not a Vista issue as we figured out already, it's a 64-bit issue specific to TortoiseSVN because it creates the Registry entries in another Key than it is searched for later.

I can't really follow what you write there. This VirtualStore is non existent and also all OpenTTD files are solely in my OpenTTD folder on a second drive and it has 0 registry entries, as I just copied the original files (required from TTLDX) off the disc and extracted the OpenTTD stuff to this dir.

The problem here was that the 64-bit Version of TortoiseSVN doesn't work as intended (no matter if you use XP x64 or Vista x64 or Server 2k3/2k8 x64 ;)
Comment by Hugo van der Wijst (Jafinto) - Saturday, 15 March 2008, 19:20 GMT
I've looked in to this in the last few days and I think I found a solution.

The problem is described better then I did in  FS#1831  at
Registry Redirector: In the case of the registry redirector, 64-bit Windows actually maintains two separate HKEY_LOCAL_MACHINESoftware trees. One is used by native 64-bit apps, the other is for 32-bit apps. This allows a 32-bit application to see a system image and resources that make it believe that it's running on a standard 32-bit version of Windows; obviously a 32-bit app wouldn't understand the hardware changes in a 64-bit system.

I've written a patch, but this is the first time I try something in VBS, so I might have done things wrong. I've tried to comply to the coding style of the document, but I might have named some things wrong. I blame Microsoft though: that API is quite complicated :p.

Some links for references:
Comment by Hugo van der Wijst (Jafinto) - Saturday, 15 March 2008, 19:39 GMT
By the way, an easy work around that I didn't post earlier is executing the vbs script via explorer and don't execute it in Visual Studio (right click openttd in the solution explorer, unfold Build Events, select Pre-Build Event and select Yes at Exclude From Build). Just don't forget to rerun the script every time you update source :p
Comment by Zdeněk Sojka (SmatZ) - Saturday, 15 March 2008, 22:06 GMT
Chris, can you test provided patch?