Are dynamic maps possible? Thread - Dominions 4: Thrones of Ascension

I'm curious if anybody knows the answers to these questions:

Q1. Is it possible to change the appearance of the map mid-game? Does doing this require changing the map file or the .trn file?

Q2. Is it possible to extract information from the .trn file about the scales in the provinces that are visible to the player whose .trn file it is?

If the answer to both these questions is yes, then somebody could set up a script to run between turns that would make a dynamic map that visibly changes as the scales change in provinces. E.g., as a province gains cold scales in winter, snow could appear on the landscape, and it could melt again when the province warms up. Or as a province gets growth scales, lots of plants could be visible growing on it, and they could dwindle again if it gets death scales. I think it really would improve immersion in the game if a territorial war between Abyssia, Pangea and Niefelheim really looked like it involved three very different dominions.

There might also be interesting potential for dynamic maps to allow a sort of fog of war, e.g., rendering provinces that aren't currently visible as monochrome pen and ink drawings or under misty clouds, while rendering provinces that are visible more vibrantly and clearly.

Dynamic maps could also display national borders in a more interesting way, e.g., by drawing colored boundary lines on the map, sort of the way that cultural boundaries appear on the map in Civ4 and Civ5.

This is probably more work than I'd want to undertake alone, but it would be a neat project if someone wanted to take it on.

iirc it's possible to change map stuff on a server which will then affect all the players, I don't know if you can change the map image though.

For Q1/ Unfortunately it isn't possible
For Q2/ I don't know but it would be nice to have some kind of new "map filters" who display Heat and others Scales yes (maybe dominions 5?)

1. Appearance of the map changes if you edit the map image file on each client computer. However, it needs to keep the white province dots in the same places, so adding/removing/moving provinces is not going to work (unless, sometimes, if they move very little)
2. I think some people had an idea how to read .trn files for Dominions 3, but it sure wasn't public knowledge.

Thus: Yes, it's possible, but mostly in theory.

On #2: Some people hacked the turn files years ago. Some used it to cheat. Therefore, those who know how and didn't cheat kept it to themselves. Best if we just stay away from turn file hacking. Once you can read turn files, you can write them. And well, if you can write your own turn files the possibilities aren't very nice.

Maerlande wrote: On #2: Some people hacked the turn files years ago. Some used it to cheat. Therefore, those who know how and didn't cheat kept it to themselves. Best if we just stay away from turn file hacking. Once you can read turn files, you can write them. And well, if you can write your own turn files the possibilities aren't very nice.

Is there no checksum on the turn files? I did some investigations with the Dom 3 newlords files last year; the ability to read them (which I developed) did not equate to the ability to write them. I still needed to figure out how to calculate a valid checksum on them (could be a simple CRC-16 over all the bytes in the file, but I didn't investigate) as well as a special guard byte which seemed to be used to make the hacking of pretender titles harder.

Also, I wonder how good the cheat detection is. The game state is stored in the ftherland file, afaik. If a specially-crafted turn file is submitted and it would put the game into a state not reachable from the state stored in the fthrland file, then hopefully cheat detection would catch this in quite a few of the most obvious cases.

As a side note: Dom 4 may have been deliberately hardened against certain kinds of cheats. The changes to alchemy come immediately to mind. Moving pretender titles out of newlords and into fthrland also precludes title hacking, which could cause erroneous guessing about pretender builds.

I have no idea how the game is *actually* set up, but it seems like it *should* be set up in such a way that each player's .trn files don't include any "classified" information that that player doesn't have legitimate access to. Otherwise cheaters could hack the file and learn things they weren't supposed to be able to learn. Similarly it *should* be that .2h files can't be written in a way that causes anything illicit to happen. E.g., one possible design would have the .2h file just include a list of the clicks/keystrokes the player made, and then the host computer could process for itself what those clicks and keystrokes would do. If that's how it worked, then there'd be no way you could cheat by somehow creating your own .2h file -- at worst you could automate some tasks by having a script put fake keystrokes in the file that you didn't actually have to stroke yourself. (The net effect would be exactly the same as using macros, which some people do.) I don't think this is actually the format of information in .2h files, but it illustrates that .2h files *needn't* allow any possibility for cheating.

If things are indeed as I think they should be, then hacking .trn files shouldn't give anyone an opportunity to cheat. At worst it would give them the opportunity to view information presented in a different format than how the game presents it. (Technically, that's exactly what "dynamic maps" would do, e.g., presenting cold scales by showing snow on the trees rather than making you click the province first to see that it has cold scales.) That would be an issue if the game intentionally camouflaged some information behind visual effects (like the way cloaked units are camouflaged in Starcraft). But as far as I know, Dominions makes any information that it presents be clearly and unambiguously available to the player (albeit with a bunch of clicks sometimes). If all the information in the .2h is available to the player in-game anyway, then letting people know how to parse that information themselves shouldn't pose any risk.