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: The Imp
« on: February 17, 2018, 04:33:42 AM »

Follow good programming practices is one thing. But nobody write code without bugs. Everyone is making them.
This is why the BWS is constantly requested to share their info on what's bugging the mods... you are actually in place to uphold these coding features/standards, but have not realized it... at least to what I can tell.
Posted by: me
« on: February 16, 2018, 06:44:37 PM »

There is nothing to suggest the_bigg did "this".
I was kinda teasing him a bit there; trying to bait him out into a response.  I like the_bigg. He did a fine job. Then again, so did you.
Posted by: Wisp
« on: February 16, 2018, 01:28:16 PM »

The previous WeiDU author/maintainer -- Giovanni/Bigiani/Rosellini/Fettucini (or whatever his name is, I forget) -- decided to conflate the two and made it such that your washing machine can not only wash your clothes, but also accidentally wash your dishes.
There is nothing to suggest the_bigg did "this". Whoever did "this" may not even have realised it would affect FILE_EXISTS_IN_GAME, because of the absolutely ridiculous way FILE_EXISTS_IN_GAME was implemented. It used to be implemented by cooption of the code that loads files from the override and/or biffs (i.e., if the file loads, it exists). I don't know if this code was originally written to look for files that could not be found in the override/biffs like they were normal files, or if that was added later, but arguably it was a bad idea regardless, because it also breaks the semantics for COPY_EXISTING.
Posted by: AL|EN
« on: February 16, 2018, 05:51:43 AM »

FILE_EXISTS and FILE_EXISTS_IN_GAME is like a dish washer and a washing machine.

Two different functions with two different purposes.

The previous WeiDU author/maintainer -- Giovanni/Bigiani/Rosellini/Fettucini (or whatever his name is, I forget) -- decided to conflate the two and made it such that your washing machine can not only wash your clothes, but also accidentally wash your dishes.

If you're a programmer, you would expect a function to do exactly what it claims to do. Not additional/unwanted/unrelated/undocumented things. Because that will lead to a slippery slope and bad things will happen.
Follow good programming practices is one thing. But nobody write code without bugs. Everyone is making them. But because of this ridiculous weidu auto-update function, even slightest change can have huge impact on all old mods. It puts enormous pressure at the head of the developer. And it shouldn't be like that. And it should be changed ASAP.

You should be angry at the BG2 Fixpack (and those other mods) instead for not updating. Not WeiDU.

You omit one thing: modders didn't change their weidu version which is included inside mod package. It's weidu which did it by itself, without possibility to prevent it ( --no-autoupdate cannot be used ). So it's not their fault that weidu xxx change the way how things works. It's the auto-update fault.
Posted by: me
« on: February 15, 2018, 09:10:40 PM »

Holy shit, people, I understand your desire to perch yourself on the high horse of "the problem is not on our side, it was sloppy modding all along", but in fact you're just admitting you're incapable of maintaining backwards compatibility and basically ruining 15+ years of modding for the sake of claiming people did things wrong. Who cares, things worked well for fuck's sake and now they don't because it is WeiDU that changed, not TobEX or anything!

FILE_EXISTS and FILE_EXISTS_IN_GAME is like a dish washer and a washing machine.

Two different functions with two different purposes.

The previous WeiDU author/maintainer -- Giovanni/Bigiani/Rosellini/Fettucini (or whatever his name is, I forget) -- decided to conflate the two and made it such that your washing machine can not only wash your clothes, but also accidentally wash your dishes.

If you're a programmer, you would expect a function to do exactly what it claims to do. Not additional/unwanted/unrelated/undocumented things. Because that will lead to a slippery slope and bad things will happen.

You should be angry at the BG2 Fixpack (and those other mods) instead for not updating. Not WeiDU.
Posted by: Perkele1
« on: February 13, 2018, 01:33:36 PM »

@enderandrew it has not been deprecated, it's another command altogether (see the reply from Mike). The mods are using the wrong string. Weidu is not bugged, it fixed this. Hence the mods depending on it breaks, creating this mess now.

So, technically Weidu is not in the wrong, please don't spread incorrect things :) but everyone modding with tobex involved is at mercy of Wisp right now, never the less.
Posted by: Creepin
« on: February 13, 2018, 01:25:46 PM »

If no one should use FILE_EXISTS_IN_GAME, the command should be officially deprecated.
You missed the point. FILE_EXISTS_IN_GAME is a valid command having its own valid sphere of responsibility. Turned out though that previous WeiDU in fact allowed a little bit more than was officially stated. The issue at hand is the policy for applying correct changes that prevents wrongly coded mods from being installed as good as before.
Posted by: enderandrew
« on: February 13, 2018, 12:24:38 PM »

If no one should use FILE_EXISTS_IN_GAME, the command should be officially deprecated. I've got an old BWP install with most every mod available for it installed. I could grep through all the TP2 files to see who is using it. Likewise, I'm about to create a mega-BWS install with everything available there and also check to see which mods are using it there.

While Weidu should try not to break existing commands without properly deprecating them, modders could also update their code.

I do propose a Weidu change for the next update. Put in the documentation that FILE_EXISTS_IN_GAME is being deprecated. Look for FILE_EXISTS_IN_GAME in TP2 files and treat it as FILE_EXISTS. The problem is then solved.
Posted by: Creepin
« on: February 13, 2018, 05:16:48 AM »

Wisp is aware about this fundamental problem with "auto-overwrite all setup-xxx.exe". It cannot be disabled because it can make re/uninstalling mods impossible. Weidu needs new solution to execute stack operations. You can read about it here: http://forums.pocketplane.net/index.php/topic,29657.msg338626.html
It's a pity I haven't seen that thread before. I, too, am sure that WeiDU auto-update could have been reasonable at times of updating Weidu from v.8 to v.12 to fix some gaping holes of malfunctioning code, but by now when WeiDU is (almost?) polished it's surely outlived its usefullness. Allowing the mod to always be installed under the version of WeiDU it was written on and tested with should have made issues like the one discussed here impossible.
Posted by: AL|EN
« on: February 13, 2018, 05:03:26 AM »


Wisp is aware about this fundamental problem with "auto-overwrite all setup-xxx.exe". It cannot be disabled because it can make re/uninstalling mods impossible. Weidu needs new solution to execute stack operations. You can read about it here: http://forums.pocketplane.net/index.php/topic,29657.msg338626.html

This situation only shows how devastating it can be and IMHO fixing this problem should have highest priority.

The claims that 'it can be resolved mod-side' is just half of the truth. It's possible to modify code, but nobody will do it without permission so old mods won't be ever fixed. Because of that, 'Perkele1' request new fixes for BWSFixpack. It's too much work and it makes BWSFixpack responsible for 'fixing all problems of IE-modding' I believe that BWSFixpack is not a place for providing 'temporary' fix for weidu problems, which can be solved just by releasing new version. Which I hope will be released and the problem will gone. Until next time.
Posted by: Creepin
« on: February 13, 2018, 12:39:47 AM »

Let's be civilised here, shall we? :)
No. Irresponsibility on such scale deserve no civility. If Wisp made a fork that would affect no others experience unless they explicitly wanted to, no one would say a thing, he is not our slave and is not obliged by law to support WeiDU. However considering actual situation players have no realistic way to say "I don't like where things are going to so I'll stay with the older, stable version", this is why not breaking anything that worked, no matter by the virtue of being good or being workaround-ish hackjob, should be paramount factor of any changes.

and let's be honest also, it can't be said that this is the fault of Weidu. It's the coding in the mods which are to blame.
Let's be honest here: not a single modder in the sane mind sat down to write tp2 with a goal "I want to write a good clean WeiDU code". People write tp2 with the single goal: to make sure the content they had will be added to the game corrrectly. To this end it doesn't matter whether someone approve your code or call it "sloppy": as long as the content happened in game, it was a coding reaching its goal. Furthermore, modders used functionality provided by the WeiDU tool, and frankly it should not been their obligation to guess after using each function they found working fine whether it worked fine because of tool developers intent or because of tool developers oversight.
Posted by: Perkele1
« on: February 12, 2018, 06:16:53 PM »

Let's be civilised here, shall we? :) and let's be honest also, it can't be said that this is the fault of Weidu. It's the coding in the mods which are to blame. That said, it's honestly not very wise to dismiss this so fast. I really hope Wisp reconsiders. Let's let him answer though before getting all riled up.
Posted by: Creepin
« on: February 12, 2018, 04:15:16 PM »

Probably not for a while. It's not a regression in documented behaviour and it can be resolved mod-side, so I won't push a new release just for this.
Holy shit, people, I understand your desire to perch yourself on the high horse of "the problem is not on our side, it was sloppy modding all along", but in fact you're just admitting you're incapable of maintaining backwards compatibility and basically ruining 15+ years of modding for the sake of claiming people did things wrong. Who cares, things worked well for fuck's sake and now they don't because it is WeiDU that changed, not TobEX or anything!

If you're set in your decision could we expect at least disabling of auto-update of other Setup-XXX to 24300, or letting people to actually, you know, install mods is no longer your concern?
Posted by: Perkele1
« on: February 12, 2018, 06:53:16 AM »

Thank you Mike. Yes, I think I do understand the situation well now. I just can't edit the thread title because I post as guest.

What I said in my last post is true however, do you not think so as well? I really do think this warrants a quick revert (even though I understand that it's not a fix and also that nothing is wrong with weidu).

Wisp, if you do not agree that this is serious enough after evaluating my points, can you please elaborate why?
Posted by: Mike1072
« on: February 11, 2018, 08:24:11 PM »

FILE_EXISTS_IN_GAME is for checking the existence of a file in the game .bifs and override folder.

FILE_EXISTS is for checking the existence of a file in the file system (e.g. the root game directory and mod folders).

Apparently, some mods in some cases used FILE_EXISTS_IN_GAME to check for files in the file system, and it worked, but it was never supposed to.  Those mods can and should switch to FILE_EXISTS for that purpose.  If they do so, they will work now, and they will continue to work even if the buggy behaviour of FILE_EXISTS_IN_GAME is restored at some point.