Post reply

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.
Name:
Email:
Subject:
Message icon:

Verification:
Type the letters shown in the picture
Listen to the letters / Request another image

Type the letters shown in the picture:
What color is grass?:
What is the seventh word in this sentence?:
What is five minus two (use the full word)?:

shortcuts: hit alt+s to submit/post or alt+p to preview


Topic Summary

Posted by: AL|EN
« on: July 26, 2019, 09:16:38 AM »

New way of defining mod folder is addressing the %MOD_FOLDER% re-definition. There are no other concerns that are not about making TP2 better.

Regarding 'wait for TP3', I don't know what other things you have on mind for TP3 so I'm simply using TP2 as base. Based on what you say about making TP2 obsolete, let's just assume that any kind of modernization ideas won't be implemented, shall we?
Posted by: Wisp
« on: July 21, 2019, 03:05:26 PM »

Okay, you did say this was for new mods and I focused exclusively on breaking cases for old mods. My apologies. It was not a very relevant objection.

MOD_FOLDER is already [1] preferably defined as the folder containing the TP2 file, if there is one; otherwise (toplevel TP2), it falls back to BACKUP. If I understand correctly, this addresses your problem with mods redefining MOD_FOLDER due to declaring a BACKUP outside of the mod folder itself, right? Are there other concerns here that are not about making TP2 better (vide infra)? Like things that cause problems for you.

Being unable to rely on BACKUP makes the logic more complicated and makes it harder for people to understand the documentation of MOD_FOLDER. I'm unpersuaded by arguments rooted in immutability, because (perhaps unfortunately), other features commonly used mutate the contents of the mod folder (such as HANDLE_*). For the rest of it, I say wait for the successor to TP2. I don't want changes to the TP2 format. I want it to slide into legacy status without making anything more complicated than it already is. I do not see any virtue in modernising TP2 while simultaneously planning to make it obsolete.

1. And by already I mean, will be, as of next version.
Posted by: DavidW
« on: July 20, 2019, 02:17:56 PM »

"dog in the fight" was just intended as a colorful way of saying that I don't mind one way or another; don't read anything into it.
Posted by: AL|EN
« on: July 20, 2019, 12:24:52 PM »

For this case, I being emotional here, sure, I'm not a "finite state machine". But being emotional doesn't make arguments less/more valid. I had to sit down and re-think what I actually didn't like during this conversation. It's the attitude: you first thought are concentrated at finding the ways to break 'old thing' and then you stop investigating the ways how to mitigate the problem. Then I spend time to find the solution only for you ignore the solution by theorizing "what could happen if the players install/re-install weidu mods using not-quite supported way". As somebody who's getting similar "no, nope, nada"-kind of answers all the time, it makes me feel disappointed and angry sometimes. Especially when I can't do anything with it. I failed to point at this during my rant.

Regarding the "no breaking changes" - sure, but just as DavidW said, it isn't a breaking change when you take the whole weidu ecosystem into consideration. What you did here is cherry-pick the theoretical case when the mods can break after update, then you ignore all other similar cases (weidu updates, designated random replace/change, tp2 changes etc) and use 'no breaking changes' argument as if other cases did didn't existed since begging of the weidu itself. You edge case are the same story as 'designated replace/change or tp2 name changes'. All of them are in the 'medium but acceptable flaw' pool.

Finally, I wouldn't call this a dog fight. We are in the same boat. Rethink and put cons/pros at the wage. If you still not convinced, create a pool and ask community for feedback so you hands will 'stay clean'. I'm sure that you can count on the support from mod authors/maintainers.
Posted by: DavidW
« on: July 20, 2019, 04:17:38 AM »

@Wisp: I don't have a dog in this fight (and I 100% agree with the principle of keeping WEIDU completely backwards-compatible) - but is this actually a breaking change? I always assumed that meant: a change in WEIDU such that the new version wouldn't install an old mod. But presumably taking a keyword off the REQUIRED list wouldn't do that. Old mods will all have BACKUP in, so they won't be affected. Of course, removing BACKUP is a new and exciting way that a mod update can break the game - but there have always been lots of those. (Changing BACKUP to something else, for instance.)
Posted by: Wisp
« on: July 18, 2019, 03:09:20 PM »

So, you are apparently getting emotional here. I apologise for wasting your time like this. I should have been more clear from the start: no breaking changes.

There are literal two mods left: Worldmap and Questpack
That's not even remotely true. The second mod I checked had a mod folder with a different tp2 name. I don't know what mods would be impacted by this, and you don't either. Good day.

Posted by: AL|EN
« on: July 18, 2019, 07:41:54 AM »

Yes, the user can avoid this by uninstalling the old version before extracting the new version, but if you think that is how it would reliably go down in the wild, I don't know what to tell you.
It's standard practice since long time, several mods/readmes/forum posts has guidelines that "you should always uninstall older version of the mod". Also, changing 'backup' is not one cause of the problem with 'overwriting old mod version > reinstall", designated numbers can be source of those problem as well. So such problems can occur even without 'backup' change. This argument is invalid.

weidu first try to detect 'old directory of the backup: modname\backup' and if found, use backup data from there
But the BACKUP information has been removed. WeiDU can't know what the old directory was. As you know, BACKUP could have be anything; modname/backup is not a reliable guess.

It is for the 99.9% cases. There are literal two mods left: Worldmap and Questpack, both can be fixed right now. The 'backup folder inside mod archive' problem plagued weidu mods since beginning, for some mod authors it is almost a tradition to forgot to remove 'backup' folder from mod archive. You have a chance to finally fix this goodam thing and yet you put more value into an "2-years old user installation problem" than fixing this for all mods once for all. Have some guts and just make justified change.
Posted by: Wisp
« on: July 17, 2019, 02:33:06 PM »

weidu first try to detect 'old directory of the backup: modname\backup' and if found, use backup data from there
But the BACKUP information has been removed. WeiDU can't know what the old directory was. As you know, BACKUP could have be anything; modname/backup is not a reliable guess.
Posted by: AL|EN
« on: July 16, 2019, 02:44:01 AM »

- define "BACKUP" location as "weidu_external\backup\%TP2_BASE_NAME%"

This is not a viable suggestion, because when you change the backup directory, you break the user's ability to uninstall the mod.

User has mod installed
User wants to upgrade to most recent version
User extracts new version into game directory
User tries to upgrade or uninstall old version
New TP2 looks for backup files in new directory when backup  files are located in old directory
Uninstall fails; game is potentially broken

Yes, the user can avoid this by uninstalling the old version before extracting the new version, but if you think that is how it would reliably go down in the wild, I don't know what to tell you.
A simple solution for this problem:
User has mod installed
User wants to upgrade to most recent version
User extracts new version into game directory
User tries to upgrade or uninstall old version
New TP2 looks for backup files in new directory when backup files are located in old directory weidu first try to detect 'old directory of the backup: modname\backup' and if found, use backup data from there
Uninstall fails; game is potentially broke uninstalling is fine, new installation use new default backup directory
Posted by: AL|EN
« on: June 17, 2019, 06:40:48 AM »

This seems overkill in any case. The vast majority of mods use BACKUP in the usual fashion. The exceptions are all new mods (all or virtually all by me) that keep to the modern convention of putting the tp2 file inside the mod folder. In the latter case you can determine the mod folder straightforwardly. The edge case would occur when someone uses a nonstandard BACKUP but adopts the old convention of putting the tp2 in the game directory.
Supporting all possible cases of proper WeiDU mods (except this impossible case, it should not exist IMHO) is not the overkill, IMHO. You correctly identified the edge case of old convention. The 'Worldmap' mod is the best example. As soon as those mods will be 'adjusted' and weidu remove support for such convention, I will follow.

Anyone who does that knows exactly what they are doing and deserves the consequences!
But if I use 'BACKUP' there are no consequences at all. If any, it would be PI to face consequences of not being able to install 'Worldmap' mod, which is unacceptable for me.
Posted by: AL|EN
« on: June 17, 2019, 06:25:32 AM »

Everyone can criticize my application and I encourage to do so. I need access to MOD_FOLDER in order to read the value of the mod folder which I need to copy into game directory. The QuestPack and Worldmap mod are ones who are coded that way. Indeed I would have less problems but it also means that those mods couldn't be copied properly > error at the installation attempt. There is no other way to get correct mod data folder than getting BACKUP keyword value (or forcing players to change mod/fill some extra stuff). I'm simply supporting everything which weidu supports currently. When weidu will establish one, default mod structure, I will follow.
I guess you at some earlier point extract the mod into the game directory? If so, why not do it again? Copying the mod seems unsafe; even if the mod's uninstalled, there's no way to know the instance was not altered during install, and presumably you are not coupling the copying to uninstalling the mod, should it be installed.
I appreciate that you mention about the 'copy mod after it has been installed' problem but I'm aware about it and it's not the case. Coping extracted mods from one place into game directory and then installing it doesn't modify mod source in any way. But i need to know what's the correct 'mod data folder' and the only fail-safe way to do it is to get it from 'BACKUP' value.


So regarding my request:

- the 'mod data folder' and the location of the weidu backup files are two different things so they need to be defined via two separate things
- first, is to separate the "%MOD_FOLDER%" variable from "BACKUP" keyword, I propose %TP2_BASE_NAME% because it will match well-established standard (it has nothing to do with PI but I can use it more effectively)
- second, is to define "BACKUP" keyword value also as well-established standard as default (it has nothing to do with PI but I can use it more effectively)

all of this can be done which doesn't break old mods, set things right from the start so the modders doesn't need to care about them.
Posted by: DavidW
« on: June 15, 2019, 07:17:47 PM »

This seems overkill in any case. The vast majority of mods use BACKUP in the usual fashion. The exceptions are all new mods (all or virtually all by me) that keep to the modern convention of putting the tp2 file inside the mod folder. In the latter case you can determine the mod folder straightforwardly. The edge case would occur when someone uses a nonstandard BACKUP but adopts the old convention of putting the tp2 in the game directory. Anyone who does that knows exactly what they are doing and deserves the consequences!
Posted by: Wisp
« on: June 15, 2019, 06:45:39 PM »

Everyone can criticize my application and I encourage to do so. I need access to MOD_FOLDER in order to read the value of the mod folder which I need to copy into game directory. The QuestPack and Worldmap mod are ones who are coded that way. Indeed I would have less problems but it also means that those mods couldn't be copied properly > error at the installation attempt. There is no other way to get correct mod data folder than getting BACKUP keyword value (or forcing players to change mod/fill some extra stuff). I'm simply supporting everything which weidu supports currently. When weidu will establish one, default mod structure, I will follow.
I guess you at some earlier point extract the mod into the game directory? If so, why not do it again? Copying the mod seems unsafe; even if the mod's uninstalled, there's no way to know the instance was not altered during install, and presumably you are not coupling the copying to uninstalling the mod, should it be installed.
Posted by: AL|EN
« on: June 09, 2019, 07:48:34 AM »

It's not for old mods and it's not a suggestion for modders to suddenly remove BACKUP keyword from existing mods. This time, my proposition is valid only for new mods, aka the ones who aren't yet released: if someone is creating new tp2 file, weidu should provide good value for BACKUP keyword.

If you think that's no gain, very well, define default "BACKUP" value as "%TP2_BASE_NAME%\backup" so modders can remove this keyword as preparation for tp3.

Edit: if I may be so bold: why does your thing even need access to mod internals like the location of the backup files or the value of the MOD_FOLDER variable? If you coded your thing to the well-established interface mods already have, it seems to me you'd be having fewer problems.
Everyone can criticize my application and I encourage to do so. I need access to MOD_FOLDER in order to read the value of the mod folder which I need to copy into game directory. The QuestPack and Worldmap mod are ones who are coded that way. Indeed I would have less problems but it also means that those mods couldn't be copied properly > error at the installation attempt. There is no other way to get correct mod data folder than getting BACKUP keyword value (or forcing players to change mod/fill some extra stuff). I'm simply supporting everything which weidu supports currently. When weidu will establish one, default mod structure, I will follow.
Posted by: Wisp
« on: June 08, 2019, 11:17:24 AM »

- define "BACKUP" location as "weidu_external\backup\%TP2_BASE_NAME%"

This is not a viable suggestion, because when you change the backup directory, you break the user's ability to uninstall the mod.

User has mod installed
User wants to upgrade to most recent version
User extracts new version into game directory
User tries to upgrade or uninstall old version
New TP2 looks for backup files in new directory when backup  files are located in old directory
Uninstall fails; game is potentially broken

Yes, the user can avoid this by uninstalling the old version before extracting the new version, but if you think that is how it would reliably go down in the wild, I don't know what to tell you.

If you want breaking changes, you are going to have to wait for the "TP3" thing. A parallel system that does not break the old system can do a lot more than tweaking the old system ever could.

Edit: if I may be so bold: why does your thing even need access to mod internals like the location of the backup files or the value of the MOD_FOLDER variable? If you coded your thing to the well-established interface mods already have, it seems to me you'd be having fewer problems.