Ask here - I maintain the pack, but the GUI guts is other people. As I understand it, the GUI writes the files in the graphics folder over the corresponding files in use, and then optionally does the same to saved regions. In recent versions of the GUI, it also 'remembers' the way each of the GUI-changeable init options were set and restores their state after overwriting the init files (note that some options are silently changed, this is sometimes annoying but also covers the changes to point to the correct tileset).



Regarding raw mods... this makes changing graphics harder, because many graphics packs use altered raws that point to different tiles - so you can't just copy them into each folder. Some graphics are raw-compatible - for example, Spacefox (and maybe Ironhand?) are based on Phoebus raws, so some you can just copy. I'm pretty sure there are actual utilities designed for people modding that make this kind of thing easier, but I've never needed them... so I'll just point you here.



Quote from: Snaake on April 09, 2014, 04:21:15 pm When I tell LNP to install a tileset/update savegames, what exactly does it actually do during those commands?

When installing graphics, the GUI will delete and replace the entire DwarfFortress/data/art folder, replace init.txt, d_init.txt and colors.txt in the DwarfFortress/data/init folder, delete the DwarfFortress/raw/graphics folder and copy/replace the contents of the tileset raw folder on top of the DwarfFortress/raw folder (including sub directorys).



Updating save games will delete the DwarfFortress\data\save\region*\raw\graphics folder and copy/replace the contents of the DwarfFortress/raw folder on top of the DwarfFortress\data\save\region*\raw folder (including sub directorys).



[where region* refers to every folder in the save directory, except the 'current' folder.]



As for preserving GUI settings when changing graphics, after replacing init.txt and d_init.txt, the GUI will modify the new files to match the settings currently displayed on the GUI.



string current_creature

array locations

get locations of string "CREATURE:"

i=1



do

at location i, store string between "[CREATURE:" and next "]" in current_creature

find string "[CREATURE_TILE:'" after location 1

take character between "[CREATURE_TILE:'" and "']" and replace with graphics_set_creature_tile(current_creature)

i=i+1

while i < size(locations)



It just seems to me that especially since the GUI remembers the GUI-changeable settings, it should also be able to not change anything else than absolutely necessary, i.e. the 4 font options, GRAPHICS:YES/NO, and the tile settings (pillar, sky, tracks...).The same goes for graphics tilesets (i.e. the ones with creature tile characters, I don't know if it's also for just the no-graphics tilesets): assuming each creature has exactly one CREATURE_TILE tag (and a quick ctrl-f with creature_ocean_new.txt confirms this for that file, at least), why overwrite all the raws when you could just a script changing that one tag? Something like the following, using pseudocode:Doesn't masterwork already do some script replacement stuff? Of course it's highly possible that Meph just has multiple sets of the raws stored, and has tried to keep divide so them that each separately changeable portion of masterwork is in it's own raw files. Hm, the graphics sets may require significant work from tileset makers though, so I guess that's somewhat wishful thinking though...I'm sorry if I seem whiny, but after my recent frustration I just feel that at least the inits wouldn't need to be overwritten, since one could just do a simpler "replace SETTING1:whatever_the_old_value_is with SETTING1:value_for_this_new_graphics_set" kind of script for the stuff you do need to change. Installing a graphics pack can also change at least one GUI-changeable setting, truetype fonts (which is interesting, because it can actually be toggled on/off while in-game with F12, too). The truetype fonts I understand though, but why change stuff like the NICKNAME settings? Anyway, you could add a warning/notice/explanation about the overwriting behavior and exactly which files are overwritten, in a readme file at least?I'd be happy to discuss this with the actual GUI people (not that my coding expertise would be that helpful...), but is there an actual separate thread for it/who are they? Couldn't find a thread with a search or two in the utilities forum, and I doubt they're going to notice if I just randomly make a new thread there (someone else who can help might, but it still seems like it would be a pretty hit-or-miss kind of attempt).Other than the above complaints, thanks for the great work with PELNP/PEDFSP/whatever the acronym is.It's really handy having all the bugfixes already installed/in dfhack.init, all the utilities collected in one place etc.P.S. I guess I should consider writing a script for my own changes, to do the specific small changes I want with a doubleclick. Might actually just barely be withing my coding/regexp skills...