yorick wrote:

Have you tried to download openttd.grf again?

This comment was imported from FlySpray: https://bugs.openttd.org/task/1847#comment3653

glx wrote:

Are you using svn to get the source?

This comment was imported from FlySpray: https://bugs.openttd.org/task/1847#comment3654

Chris wrote:

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.

This comment was imported from FlySpray: https://bugs.openttd.org/task/1847#comment3655

yorick wrote:

The revision detection should be able to work with TortoiseSVN, shouldn't it?

This comment was imported from FlySpray: https://bugs.openttd.org/task/1847#comment3656

glx wrote:

Then you seem to have a problem with determineversion.vbs. It should create src/rev.cpp from src/rev.cpp.in, replacing some placeholders with the correct data fetched from TortoiseSVN.

This comment was imported from FlySpray: https://bugs.openttd.org/task/1847#comment3657

yorick wrote:

It seems like a problem with openttdw.grf:
locks, canals, foundations, up&down buttons are all in it.

This comment was imported from FlySpray: https://bugs.openttd.org/task/1847#comment3658

glx wrote:

@yorick: no it's a problem in rev.cpp

This comment was imported from FlySpray: https://bugs.openttd.org/task/1847#comment3659

Chris wrote:

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 :/

This comment was imported from FlySpray: https://bugs.openttd.org/task/1847#comment3660

Chris wrote:

When I use the beta .exe I don't have the problem. So this is an issue with MSVC building maybe?

This comment was imported from FlySpray: https://bugs.openttd.org/task/1847#comment3661

yorick wrote:

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?

This comment was imported from FlySpray: https://bugs.openttd.org/task/1847#comment3662

Belugas wrote:

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?

This comment was imported from FlySpray: https://bugs.openttd.org/task/1847#comment3663

glx wrote:

The issue is you have a wrong value in rev.cpp line 37.
In rev.cpp.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.

This comment was imported from FlySpray: https://bugs.openttd.org/task/1847#comment3664

Chris wrote:

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.

This comment was imported from FlySpray: https://bugs.openttd.org/task/1847#comment3665

yorick wrote:

If you are really using a 64-bit OS, then #1831 could have to do with it.

This comment was imported from FlySpray: https://bugs.openttd.org/task/1847#comment3666

glx wrote:

Ho you didn't say you were on win64 :)
Your problem is indeed known (check #1831). We probably can't do anything about it.

This comment was imported from FlySpray: https://bugs.openttd.org/task/1847#comment3667

Chris wrote:

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

This comment was imported from FlySpray: https://bugs.openttd.org/task/1847#comment3668

Chris wrote:

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.

This comment was imported from FlySpray: https://bugs.openttd.org/task/1847#comment3669

glx wrote:

It's all explained in #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.

This comment was imported from FlySpray: https://bugs.openttd.org/task/1847#comment3670

MagicBuzz wrote:

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:UsersAppDataVirtualStoreProgram 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 ;)

This comment was imported from FlySpray: https://bugs.openttd.org/task/1847#comment3672

Chris wrote:

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 ;)

This comment was imported from FlySpray: https://bugs.openttd.org/task/1847#comment3673

Jafinto wrote:

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 #1831 at http://www.codeproject.com/KB/system/64BitOSAndPortingIssues.aspx
Quote:
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:
http://msdn2.microsoft.com/en-us/library/aa393067(VS.85).aspx
http://msdn2.microsoft.com/en-us/library/aa390788(VS.85).aspx

Attachments

• 64-bit_svn_patch.patch (3.68 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/1847#comment3685

Jafinto wrote:

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

This comment was imported from FlySpray: https://bugs.openttd.org/task/1847#comment3686

SmatZ wrote:

Chris, can you test provided patch?

This comment was imported from FlySpray: https://bugs.openttd.org/task/1847#comment3688

glx closed the ticket.

Reason for closing: Fixed

In r12375. Thanks for the patch.

This comment was imported from FlySpray: https://bugs.openttd.org/task/1847