Recent Posts

Pages: [1] 2 3 ... 10
WeiDU / DEST_x variables not properly set when destination is a directory
« Last post by Angel on June 17, 2019, 05:02:15 PM »
With COPY and COPY_EXISTING, if the destination is given as a directory with no filename (commonly "override"), variables DEST_RES and friends are set to "override" instead of the file being written to as one would expect.

Even within the scope you have specified, this is a much larger request than I think you realise. As I said, there's no 10-20 lines about it (if you want something with useful granularity). If you get impatient waiting, I suggest you follow the code yourself. WeiDU always starts in Main.main ( If you are installing a mod, control rather quickly flows to Tpwork.handle_tp and after that it gets convoluted.
Thanks, that's good start. I won't get impatient so if there is anything more you can add, please do.

You are going to have to point me to it. I don't remember anything that fits your description.
Please explain how backup system works via pseudo-code or logic diagram. Does weidu monitor the files difference inside overdrive between components to get list of things which are modified? Or does every function which modify game resource is contributing to the 'backup file list'?
WeiDU / Re: Remove the BACKUP keyword from the required
« Last post 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.
WeiDU / Re: Remove the BACKUP keyword from the required
« Last post 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.
WeiDU / Re: Remove the AUTHOR keyword from the required
« Last post by AL|EN on June 17, 2019, 05:45:08 AM »

But it's only ONE if/switch statement:
Code: [Select]
if (AUTHOR keyword is present) {
} else {
    %MOD_AUTHOR% = ""
How such trivial thing can the weidu internal logic more complicated?
Keto / Keto v5 with native EET compatibility available!
« Last post by jastey on June 17, 2019, 03:13:59 AM »
With many thanks to k4thos, Keto updates to v5 with native EET compatibility!

Thank you to Kulyok for updating the download's page!
Kelsey / Kelsey v5 with EET compatibility!
« Last post by jastey on June 17, 2019, 03:13:13 AM »
With many thanks to k4thos, Kelsey updates to v5 with native EET compatibility!

Thank you to Kulyok for updating the download's page!
WeiDU / Re: Question to STATE_WHICH_SAYS
« Last post by jastey on June 16, 2019, 02:44:23 PM »
Thank you!
WeiDU / Re: Traify not coping with crossplatform OUTER_SPRINTs
« Last post by jastey on June 16, 2019, 02:43:48 PM »
Cool. Thanks, I'll try that next time. (I do have the feeling I am posting something like this every two years or so. Sorry if this is the case.)
WeiDU / Re: LABEL discussion
« Last post by Wisp on June 16, 2019, 12:57:38 PM »
Yes, I mistyped. It was late.
Pages: [1] 2 3 ... 10