More support for custom tracks in GP4
Issue #5
resolved
hi SDI
I really like the trackmanager function in GPxPatch, and I wonder whether it could be extended, so it also puts the following things in place in gp4 - the correct string in the track selection menu (maybe using another piece of GP4Info in the .dat) - the trackmap-.gpi in the track selection menu (eg name-according-to-GP4Info-prefix.gpi) - the loadingscreen-.bmp (eg from name-according-to-GP4Info-prefix.bmp) - setting the starting light position (maybe using another piece of GP4Info in the .dat)
that way, as far I see it at the moment, every aspect of inserting a custom track in gp4 could be done with GPxPatch, by simply inserting the trackname.dat in the desired slot in the trackset. no other tools or action needed.
and maybe all those custom files (including the .wad) could be placed in a single sub-directory of gpxdata, or even a completely arbitrary directory, instead of being scattered allover the gp4 installation. eg GPxPatch could look for the files in the same directory where it loads the .dat, if not found there look in the original place, if not found there neither take the default.
I could help out with information which .gpi is which slot in gp4 and things like that ...
best regards addie
Comments (12)
-
reporter
-
reporter
Put cornerdata in <prefix>.txt with sections for each language. Make it structured.
-
reporter
Patch cornerdata dots (number or corners, and tooltip and position for each).
-
reporter
maybe you could implement them, and also some "set default/global"-feature to set all dots in one go, so its done, and we dont think about whether it should be done or not anymore :) IF you do, I'd suggest the following: 1) gp4 setting is default (dimensions and transparency) 2) in the .ini new defaults could be set 3) in the .ini the inidividual properties of individual points could be set, to overwrite the default (.ini or gp4)
-
reporter
and when talking about windows, maybe the "track set"-window should be wider now, to allow longer paths to be visible, eg "C:\Documents and Settings\user1\Desktop_dvTracks\grauholz2013\package\grauholz2013.dat" :))
or the window could be higher, and have the tracks from 01 .. 17 in a single column ...
-
reporter
there is yet one other rather odd issue with track specific files, we already mentioned it IRC. dont know what could be an appropriate practical solution.
in gp4 we have different weather and one speciality of gp4 is, the "folks" in gp4 look different in dry and wet weather. gp4 loads different textures if it rains. and the odd thing is, those "wet weather folks" (ATX_W_x.tex, x: 1..12) are loaded EXCLUSIVELY from ./MAPS/prefix, where all other textures incl the "dry weather folks" (ATX_D_x.tex) are loaded from the .wad exclusively AFAIK. in pau this is not a problem, because pau has no "folks" at all, but in other tracks the "wet weather folks" are missed, if they are not there. gp4 does not crash though, but it shows white areas where the folks are supposed to be.
one more minor problem with the directory ./MAPS/prefix is, if it includes .tex-files that are NOT included in the .wad, gp4 may crash. actually this may happen with published pau with the "dry weather folks". as mentioned, pau has no "folks", so there are no "folks"-textures included in the .wad (because I wasnt aware of that problem then). but in every original ./MAPS/trackname-directory there are all "folks"-textures included. so if a person decides to run pau old fashioned, by renaming a couple of names in and around the .wad, so say replacing original hungaroring2001, gp4 takes ./MAPS/hungaroring2001 in account when loading pau, and paff! OK, I'll prevent that one in the next release by just including the "dry weather folks"-textures in the .wad also.
but the "wet weather folks"-issue is still there for custom tracks including "folks". now I dont know what to suggest -having the files ATX_W_x.tex (x: 1..12) next to the .dat also, and loading them from there first place -have gp4 loading them from the ./MAPS/trackname-directory of the original-track of the used slot -some other way -leaving the issue alone
what would you say ?
-
reporter
I did some tests with melbourne in wet weather and my results were:
-
no problem dry tex = not in wad, not on disk wet tex = not in wad, on disk
-
white areas dry tex = not in wad, not on disk wet tex = not in wad, not on disk
-
crash dry tex = not in wad, on disk wet text = not in wad, on disk
-
no problem dry tex = in wad, on disk wet text = not in wad, on disk
'1.' and '2.' are expected, dry tex seems to be ignored, and wet tex is only loaded from disk (from maps\melborne2001), but shows white areas if not loaded. But 3. is unexpected, as dry tex is not really ignored. It looks like the presence on disk forces loading it from the wad (because 4. fixes it), which fails and crashes.
I also did some tests in dry weather. In all cases the wet tex had no influence:
-
no problem dry tex = in wad, not on disk
-
white areas dry tex = not in wad, not on disk
-
crash dry tex = not in wad, on disk
These results confirm the above results. The conclusions are: - in dry weather, only the dry tex is loaded - in wet weather, both dry and wet tex are loaded. Probably because weather is variable, and the crowd (this is game's terminology for 'folks') might change when the weather turns dry? - the dry tex is always loaded from the .wad - if the dry tex is not in the .wad, it is skipped (white areas), unless it's still on disk, then the game crashes - the wet tex is always loaded from disk, presence in the .wad has no influence - if the wet tex is not on disk, it is skipped (white areas)
It's quite hard to see in the code how it handles these files, and would take a lot of time to reverse engineer. So I would choose the easiest option here. As the files are not that big, always including the dry tex files in the custom track wad sounds like the best solution.
The only problem is that the wet tex files need to be installed in the maps\prefix dir. So I might take a look at patching the game to look for them in the .dat's dir first. If you want to customize the dry/wet tex files, you need to include the dry tex in both the .wad and on disk.
-
-
reporter
- changed status to open
Some more track specific settings in gp4.exe.
-
reporter
- pit lane lines.
- tarmactex tone
- exceptions for specific slots
-
reporter
Progress bar color and hide progress bar in .ini.
-
reporter
Track specific marks file (maps\resources\marks.mr*).
-
reporter
Track specific track map scaling (maps\resources\trackmaps\trackmaps.dat).
- Log in to comment
yes it is (to me actually a key feature of GPxPatch). having a separate file for it sounds like a good idea to me too (eg name-according-to-GP4Info-prefix.md3). would be very handy when tuning the magic-data. there you make a certain change, testdrive, more changes, testdrive, maybe some dozen of times. it would be even more direct and time saving than having editing facilities for the magic data in the builder, which of course already would be more direct than inserting it with CMagic. and of course CMagic also is very much appreciated !
however it should work the same way it does now, where the magic-data is loaded at track load time, after clicking "drive" in gp4 that is. I noticed the gp4info-data is loaded "only" at gp4.exe launch, which is OK to me. but the magic-data really should be loaded at track-load time, or even at "return to cockpit" time, but the latter probably is not possible as the .dat is not loaded then neither, is it ?
in the meantime I recalled some more track relevant things not yet covered, though they are details not really important to me. if you click "info" on the "circuit select"-window, you have two windows "info" and "track data" ...
on both, the horizontal position of the caption of the track-map (see green bar in the screenshots further down). in the 2nd screenshots the "problem" is visible. if this track would be in the silverstone slot, the whole text would be visible. maybe the position even could be calculated from the length of the string to be posted.
on the "track data" window, the number and position of the numbers blended over the track-map. in the 2nd screenshots that "problem" is visible also. there the numbers are completely unrelated to the map, and I wasnt able to find the position data of those number-images so far.
the text on the left side of both windows. it can be edited in the .gps-files in MenuData/PC/GP2001. maybe the whole text of the "info"- and the "track data"-window could be in another separate file name-according-to-GP4Info-prefix.gps.