The current method of registering mod content makes it very easy to mess up items when deleting existing content, leading to save file issues. Would you consider changing the way mod content is registered to a safer method, such as "modid:name", so that when a particular ID no longer exists, only that ID is deleted without affecting other content?
Should the method of registering mod projects be reconsidered
- Thread starter anmao
- Start date
Riamus
Well-known member
I agree with BFT2020. If you don't know what mods you want to use, try them in a test game first. See what you want or don't want before starting a real game. And if you thought you did want a mod and later decided you don't like it, you can still keep playing the game with the mod until you are ready to start another, or you can just start another. This game is intended to be played over and over, so losing a game isn't too critical even if it might be annoying.
The mod will be updated, and if fixes are made and something is removed, a new save is required. Single-player games usually don't have any problems, but for multiplayer games, starting a new save might waste a lot of people's efforts. However, if you don't start a new save, you'll face potential unknown or known issues.
Furthermore, internal updates shouldn't affect regular XML mod authors; DLL authors may be somewhat affected.
Riamus
Well-known member
Mods being updated normally work fine. And if they won't work, the author should make it very clear that the update requires a new save. You should obviously not install such an update if you don't plan to start a new save. Mod updates are not required or automatic, so there's no reason why that would be a reason to need to change anything with how mods work.
And in any case, you replied to the suggestion to just try mods first and decide what one(s) you want to use before starting a real game. Nothing in your reply relates to that. Regardless of any updates from the game or a mod, you can still try mods first and decide what to use before starting a real game. That can be done both in single player and on a server or P2P. And once you decide, don't update the game or mods during that save... at least not unless you keep a backup just in case something doesn't work.
BFT2020
Well-known member
So how is this scenario suppose to be handled?
- Modder releases mod with new content for the game.
- Game assigns an unique ID to the mod
- Modder updates the mod with new content and removes content
- Player installs the updated mod
- Does game give the mod a new unique ID and remove the ID for the previous version?
This option, the player will lose any items from the old mod that were kept in the updated mod
- Does the game keep the unique ID and update the IDs based on the updated mod?
This option, if content is added and removed, player will have items switching on them or removed
Since it is very likely for mod creators to add / remove custom items in their mods, both scenarios above is plausible. So the idea of adding an unique ID per mod doesn't address the main issue you are trying to solve. At that point, you would then be asking the game to start tracking individual items, determining if they should remain in the game, and then modifying the data for the world / players to ensure those items remain.
The alternative would then be to have modders create different versions of their mods whenever they update them so that updating them onto players' games / servers does not cause them to lose items when they post an update. Some modders might be willing to do that, but that is a lot of work for the modder when the easy solution is just to restart - especially if there are a lot of updates between when the mod was first installed.
I might be overthinking this, but I am an engineer and one of my primary tasks is to look at all scenarios and determine the pros / cons / effects downstream
Dead Smarty
Active member
Another point of concern: How many ID's can you create before the system collapse?
You are not overthinking it at all, personaly I think the extra load and effort is not worth it. As it is the start-up is already long enough, this will add another step of synchronisation slowing down starting up imho.
SylenThunder
Community Moderator / IT Guru
You can do this already. Just make a new desktop shortcut for the game executable. Then create safe folders for each mod.
In this example I have v1.0 for regular games, v2.0 for the internal testing I do, DF is Darkness Falls, and DZ is District Zero.
Notice my path is D:\SaveGames
So now to my desktop shortcut, I append the UserDataFolder argument.
"D:\Games\Steam Games\steamapps\common\7 Days To Die\7DaysToDie.exe" -UserDataFolder=D:\SaveGames\DZ
So to play with District Zero, I just start the client from that desktop shortcut.
Riamus
Well-known member
Yeah, that can be done. However, that isn't something the average player is going to understand or do. Having a mod loading screen in the game just like many other games do would be beneficial. Though once we have Steam Workshop support, that might not be needed, depending on how they implement it.
SylenThunder
Community Moderator / IT Guru
yeah, Workshop is planned, but we aren't going to see that for a couple of years yet. I have hopes that they will do an interface similar to Conan Exiles, but every time I have hopes like that, TFP manages to do something completely different.
zztong
Well-known member
I concur with Riamus and his assessment of the player base. One of my more frequent tech support questions for my modlet relates to getting a modlet installed correctly. As you no-doubt know, that's just putting a folder of content into the Mods folder. So I don't have a lot of confidence that users are going to understand making alternative User Data Folders and setting a command line argument in a shortcut.
I've tried talking people through making softlinks to alternative Mods folders as an alternative (really handy, actually) but it is beyond most users. They don't get the concept.
Yes, that's the full need and involves much more than just associating modlets with a game. While that much of a feature would be a partial step in the full workshop support direction. I completely understand it competes with other goals.
Perhaps my expression was flawed, and the English translation might not accurately convey my meaning. Let me describe the problem I want to solve in detail: When a mod updates, if it changes the item system – adding, removing, or replacing items – it can cause problems with players' inventories. For example, if I have items A, B, and C, and I replace B with D in the mod, then item B in the player's inventory will also be replaced with D instead of being deleted. If I add items D, E, and F, then the original items A, B, and C in the inventory are likely to be replaced with D, E, and F. Deleting an item has a very high probability of directly clearing the player's inventory. I'm wondering if these issues can be optimized by changing the way items are registered and saved, so that existing items are not affected by mod updates and transformed into other items. If an original item is deleted, it should simply be removed from the inventory, while other items remain unchanged. After all, it's not always necessary to start a new save file with every update.
I've written mods for Minecraft, and their item registration and data saving are quite well-developed. The mod ID is not a number or anything assigned by the game. For example, the original stone is 'minecraft:stone', where the original mod ID is 'minecraft'. The mod ID is defined by the mod author. Returning to 7 Days to Die, if I create a mod named 'A Test Mod', I can define the mod ID as 'atm', 'atestmod', or something completely unrelated. When giving items to the player, it would be like 'giveself atm:stone' to give the player one 'stone' item from the 'atm' mod. Saving would be in a similar format (example: {'slot:"1",item:"atm:stone",data:{"customname":"A Has Custom Name Stone
",color:“FFFFFF”},count:1”,creatime:123456789}). Changing to a similar system should effectively solve the problem I described above, but I'm unsure if it's feasible.
SylenThunder
Community Moderator / IT Guru
Not that I am aware of. I could probably scope the exe and uncover a few, but hard to say if half of what I found is even functional.
These are the ones I am familiar with.
- UserDataFolder = Sets the path for the User Data Folder where saves, logs, and worlds are kept. Default is in %appdata%\7DaysToDie
- configfile = Tells the client to read the config file presented for options. For many years this only worked to set the user data folder paths, and now there is an argument for that specifically so this argument is obsolete.
- logfile = Tells the client where to save the log file. This is useful if you want to store them in a different folder than the default. Mostly only used for the dedicated server, but I use it in conjunction with -UserDataFolder so I can separate my logs per what version I am playing.
- popupwindow = Allows a more true borderless Windows mode that can slightly improve performance with Exclusive mode enabled, and Windows "Optimizations for windowed games" enabled. Only really useful for low-end GPU's that are struggling with performance.
- skipnewsscreen = Set the value to "True" to skip the news screen pop when starting the client.
- skipintro = Doesn't really do anything yet, but will skip the intro video when it gets added.
Thank you.
I would like to see such things somewhere in the documentation. This is not often needed, but sometimes it is needed.