-
Announcement
-
Simtropolis Returns! 05/26/2026
See here for details about our site recovery efforts.
-
Search the Community
Showing results for tags 'dbpf'.
Found 3 results
-
dbpf-grep is a basic command-line search tool for TGIs in DBPF files. It's decently fast, so you can use it to search for specific TGIs in a large Plugins folder very quickly. I also use it for getting a quick overview of files, for debugging load order problems, for writing sc4pac metadata, and for dealing with the NAM and its many files. I've also had plans to expand the functionality by a few other useful commands, but so far they haven't materialized, so I decided to release it as is for now.
-
I figured out how to parse some values out of the SimCity 4.cfg file, and I figured I'd post my findings here since I haven't seen this done before. Besides the directory subfile, the SimCity 4.cfg contains only one other (compressed) subfile with the type ID of a9dd6e06. This contains the last viewed region, last played city, and last used mayor name. The subfile itself appears to be filled with zeroes, with each of these values found at specific offsets. I'm sure graphical settings and such are encoded in this subfile too, but I haven't figured out how to parse those yet. The last city name can be found at offset 110 (0x06E) The last mayor name is at offset 622 (0x26E) And the last region name is at offset 3774 (0xEBE) All three of these values are null-terminated strings. So you read the string until you read 0x00, then terminate the string. These offsets should be correct if my DBPF decompression function is not broken, which it maybe potentially could be. The purpose of this is for the SimCity 4 multiplayer launcher, so it can automatically switch between region maps depending on what's found in the SimCity 4.cfg file. The code for this project is at https://github.com/kegsmr/sc4mp-client/. And here's my function to read these values from the CFG file (it can be found on the feature branch in core/dbpf.py): def get_simcity_4_cfg(self): data = self.decompress_subfile("a9dd6e06") self.simcity_4_cfg = {} data.seek(110) # 0x06E self.simcity_4_cfg["LastCityName"] = self.read_nullstring(data) data.seek(622) # 0x26E self.simcity_4_cfg["LastMayorName"] = self.read_nullstring(data) data.seek(3774) # 0xEBE self.simcity_4_cfg["LastRegionName"] = self.read_nullstring(data) return self.simcity_4_cfg
-
Nothing major, just throwing a fun fact out here. I've been looking at savegame-related stuff lately and found a weird quirk in how SC4 loads data. Almost every modder already knows that most game data (plugins, .dat files, savegames) is packaged as DBPF files. Here's what the SC4Devotion wiki has to say about them: This actually isn't true! For some absolutely insane reason, if a file doesn't start with "DBPF," the game will still scan through the entire file and try to load it by looking for this byte sequence: 80 9D 88 EC 8F 24 03 6C C9 A6 31 56 5B CF 77 22 If the game finds these magic bytes it'll try to load any data from that point on as a DBPF. This lets you do weird things like combine .dat and .jpg files. If you want an example, download the demo.jpg file I attached to this post and put it in your plugins folder. If it worked, you'll see this hastily made icon in your parks menu: Now as a novelty I think this is pretty funny, but I can't think of a practical reason for why anyone would do this. Here's what I think this could mean for modding though: it's a pretty solid confirmation that the game will waste time on non-game files like JPEGs that get stuck in plugin folders. This is inefficient since the game is forcing itself to fully scan every file in the Plugins folder for this kind of data. But it's possible to patch out this check so that the game only looks for the "DBPF" sequence at the start, and bails out early if it's not there. This could meaningfully improve load times for people with large plugin folders that still have JPGs, ZIP files and other non-game data in them. But since spinning hard drives are going out of style, this might not offer much improvement either. Anyway, here's the demo file I mentioned earlier: demo.jpg
.jpg.609d49f6a11f0f7d9252723057d15c58.thumb.jpg.164d9ea9f1e5a267c59c036806fa3562.jpg)
