belugas wrote:One way to make it less confusing is to prefix the commit log with the name of the project.
Or you could just svn log only the interesting folder. When I want to see the changes to Patch's trunk, I cd into my ttdpatch checkout and $ svn log. And it automagically shows me only the changes that were applied to trunk. If I want NFORenum, I svn log from that folder, and I magically! get the NFORenum commits.
If you are not ready to work a bit for your ideas, it means they don't count much for you.
OpenTTD and Realism? Well... Here are a few thoughs on the matter. He he he he
------------------------------------------------------------
Music from the Bloody Time Zones
Well, my point was that when I did an SVN Update on GrfMaker I got the message about a new revision number, but not a single log line. Now that I know how it works, it's no problem, but it's still a bit irritating...
Both svn and Tortoise SVN report "At revision: $REVISION", even if no changes were made, and even if the specified revision is the same as the previously-current revision.
OK, fine, I understand all that. No need to clarify further.
My point, though, was that it showed a new revision number for GrfMaker (116), while the log only showed info up to 113. That was a bit confusing at the time, as I then didn't know that the revision number was shared through the whole repository. Now I do, and there is no problem.
@PikkaBird:
Sorry, I could only find pb_nars from 5th of April 2006, and it works flawless.
So I can only guess: You have to apply grf2html on the encoded pb_nars.grf, not the nfo.
GRF2HTML verursachte einen Fehler durch eine ungültige Seite
in Modul <Unbekannt> bei 0000:00000000.
Register:
EAX=00000000 CS=0000 EIP=00000000 EFLGS=00000000
EBX=00000000 SS=0000 ESP=00000000 EBP=00000000
ECX=00000000 DS=0000 ESI=00000000 FS=0000
EDX=00000000 ES=0000 EDI=00000000 GS=0000
Bytes bei CS:EIP:
Yawn - finally I can reproduce that error.
It does not happen on XP nor linux/wine, but on win98 with every grf that contains an image. (I do not have other versions of windows).
As it is some problem in the pngdelphi library I do not yet know a solution to fix it (except to switch to free pascal and use libpng).
As a work-around you can run grf2html with the '--nodata' option. That will skip the data files (images, bounding-box previews and binary included files), but the rest will be ok.
New release in first post.
Read the changelog there.
TrueLight and I succeeded in porting Grf2Html to Free Pascal. So there is now also a binary for linux. Note that Free Pascal supports a couple of platforms, so you have chances, that it will also compile on your system, if you are neither on windows nor linux.
Very well done Frosch and all others involved, it works very well for me.
I used it to remind myself how my newsignals GRF was supposed to work (not many comments in code).
One or two things however...
Firstly I would suggest is that instances of: (Var1A"always -1") and 0xnnnnnnnn, can be replaced with just the number, as it seems a rather long-winded way of decoding it (although more literal).
I noticed this as I tend to use it quite a lot in my NFO code, (found 13 in that GRF...)
Also I see that in varaction2 dumps, sometimes numbers are zero padded to 0x000000nn for example and sometimes they are not, it would probably be easier to read and more consistent if they were all not zero padded.
Oh, sorry, I don`t live in USA or in Britain, sometimes I make mistakes...
And about programm- I try to make it work, appears black window of command-line for a moment, and disappears. That`s all...
