Hey, we ran a Gold Coast - Surfers Paradise - QLD Australia track this week and the sun started to set at about 3:30 in the afternoon, when in real life did not set until ~6pm. The GDB file has the following: Latitude = -28° // degs from Equator (range: -90 to 90, positive is Northern Hemisphere) Longitude = 153 Altitude = 10.60 NorthDirection = 180 // the direction of North in degrees (range: 0 to 359) RaceDate = October 21 // default date for the race july 27 TimezoneRelativeGMT = 8.0 // hours compared to Greenwich Mean Time (should be negative to the West) //DSTRange=(1.0, 1.0, 0, 9999) // (start day 1.0-367.0, end day 1.0-367.0, start year, end year); multiple lines allowed RaceDate is correct. Timezone incorrect as it should have been 10.0, however that would have moved the time even earlier, e.g. 1:30pm finish. Time Scale was set to 1. Could the degree symbol in the Latitude row through it out? "Latitude = -28°"
Bet that was fun! The timezone will do it. You're setting the time in that timezone - so earlier will make the location "time" later. (E.g. if you're racing at 3pm at GMT+0, that'll be 1am at the track physical location)
the degree symbol probably not helping either, lat and long should be in the order of; Lat: -27.984929 Long: 153.426260
"TimezoneRelativeGMT = 8.0 // hours compared to Greenwich Mean Time (should be negative to the West)" I read this to be GMT +8, GMT +8 is earlier than GMT +10, which is where we are racing. When we set the time in the mod file, won't it then take it from the track file. so if I say the race starts at 870 minutes, that is 2:30pm for the location of GMT + 8? Loads of fun -
Yes, basically a WA time zone, one alternative is to create a "correct" gdb file and add it to a mas file and create an update to the track.
G, if you are just going to throw out random numbers..... lol! Hope you guys can groupthink a solution.
i dont think the line: NorthDirection = 180 // the direction of North in degrees (range: 0 to 359) is used anymore, does it get ignored or can it throw out the calculations ? as this was from the RF1 conversion.
It's not in the any of the S397 ones I've checked, so could probably delete or REM out. One that could probably be added is the line; FormationSpeedKPH = This sets the pace car speed on FCY's and rolling starts? so would help for offline races, if it's not in there the default is 150KPH. Probably a figure of around 80 to 100kph would be suitable?
Actually I’ve been thinking about the FormationSpeedKPH line, if it’s not in the gdb then it can be set at any speed via a rfm, downside is that if it’s not in the rfm then 150kph it will be (the default)
Probably worth checking the NorthDirection to see if it works. I'd expect S397 tracks to just be oriented correctly so don't need it - 3rd party tracks have been wrong in the past. Won't affect sunset times though, just the direction
I use this data for my circuits and they work well. Older circuits may have erroneous data. As an example I give you the Fernando Alonso Museum Circuit: Latitude = 43.4288780 // degs from Equator (range: -90 to 90, positive is Northern Hemisphere) Longitude = -5.8313017 // degs from GMT (-180 to 180, positive is East) Altitude = 158 // meters above sea level RaceDate = 284 // default date for the race TimezoneRelativeGMT = -1.0 // hours compared to Greenwich Mean Time (should be negative to the West) (Coordenadas sacadas de Google Maps: 43.428878044498745, -5.8313017689795)
Pretty sure the numbers are correct, I think the degree sign might have thrown it out and made it Northern Hemisphere. I checked Japan, which was to the west of the 28 degrees (v's -28°) and their sunset was 4:30pm.
Latitude is north-south, though sunset will change due to summer/winter. I don't think the degree symbol will stop it reading the number though. And, I still think the timezone is the main factor.
I totally agree. To my understanding that parameter is what assures you that the sun is at the required altitude for the time of day. Latitude and Longitude positions the sun on the horizon in the correct orientation.
I think the race date and timezone, in combination with the session start time, sets the "world position" (or sun position; same thing, different reference). Having the race start at 14:30 at GMT+8 is the same as a 16:30 start at GMT+10. The physical location of the track is separate. You could, if you wanted, use the timezone of central Africa and have the track location in Japan. 2pm certainly won't look like 2pm because that's the time on the other side of the world. The game sets the world time based on the various date and time inputs, then sets the sun (and other celestial bodies???) position based on the track location. I imagine it even takes the oblate spheroidal shape of Earth into account, because the approximation isn't so hard to calculate. I don't think the symbol will be an issue because basically all number reading functions are using the C atoi() function, or some derivative of it (I include atof() here, though i don't know the history), and while it will stop when it finds an unexpected character it will still return what it found to that point, if the format is ok. Not to labour the point, but are you certain it is no longer supported? Quite often modded tracks in rF1 weren't oriented correctly, assuming they will be in rF2 would be a leap of faith...
previously it sounded like you were saying it was just the timezone, but now it sounds like it is the combination of both. Track time was 14:30 GMT+8, but Long/Lat was at GMT+10. so 16:00 finish was in fact an 18:00 finish. And Sunset was 17:58 for GMT+10 location.
Yeah, the timezone doesn't work in isolation, the location is also factored in. I figured the location was right. So it's possibly wrong by around half an hour - which would actually line up pretty well with the equator. So I could be wrong on the symbol not breaking it
