5286 replies to this topic

[Quorwyf]

Iwdification is up to beta 5

[Roxanne]

Iwdification is up to beta 5

updated BWS

[Quorwyf]

This is a better link to the G3 tweaks anthology v4. The version BWS grabs doesn't have the setup-cdtweaks.exe and instead has a package.bat

 

https://github.com/G...cdtweaks-v4.exe

 

 

hm...both versions give me a

 

"ERROR: End_of_file

Romance Cheats (Tweaks Anthology) was not installed due to errors."

 

in BWS.

 

Tested the archive and its not corrupt.

Edited by Quorwyf, 12 February 2018 - 12:30 PM.

[Roxanne]

Yes that is infinitely helpful Roxanne, thanks!

 

Listen BWS guys, if I go through the tp2s and check which mods need to have it's string changed, can someone here with access to the BWP Fixpack github make the changes to the mods in there? That way, it will be solved for all users permanently both now, and also after the upcoming Weidu update without further changes needed. It is also a fix anyway, because the affected mods actually use the wrong string, and Weidu recently changed the behavior so that the wrong string no longer works. Apparently even BG2 Fixpack is guilty of this.

 

Wisp will revert to the old behavior in Weidu in next version but we don't know when that will be. So we might as well BWP fixpack this to be the correct string anyway, right?

 

So we're going to need someone to add this to the BWP Fixpack. Who will do this? It's a simple matter of replacing a string such as this:

REQUIRE_PREDICATE FILE_EXISTS_IN_GAME ~tobex_ini/tobexcore.ini~ @29              // This component requires TobEx

With this:

REQUIRE_PREDICATE FILE_EXISTS ~tobex_ini/tobexcore.ini~ @29              // This component requires TobEx

in only a few select mods.

 

More info in this thread: http://forums.pocket...ic,29740.0.html

After you have read this http://www.shsforums...n/?hl=official, all of it, you may reconsider your statement:

 

So we're going to need someone to add this to the BWP Fixpack. Who will do this? It's a simple matter of replacing a string

Technically easy does not mean you will find someone, unless you do it yourself and get those hounds on your trail.

[The Imp]

Help me help you. I'll provide what needs to be replaced and where. You guys put that in. I guess I can always just do it in my own files to fix my own installation, but that seems a waste of effort, considering the state of the BWS right now.

No saatana sitten tekee... elikkä mä oon varma että jos ja kun joku näkee ja osaa tehdä muutokset jotka on tarpeen, niin ne kyllä tulee tehdyks. Itseasiassa BWP oli alunperin ihan vaan näiden patchien yhtymä. Mutta sun täytyy tehdä se research. Hihihihih. Jep, suomaalainen täälläkin, . Takas Enkuks.

 

So I would advice you to open the .tp2 files with Notepad++, take up the tp2 files name, and the code line number, the coded line and the alternative, post them in a separate thread in this forum, and take it from there.

 

This will help the BWS team to get it to work.

Edited by The Imp, 12 February 2018 - 11:56 PM.

[Roxanne]

@Roxanne

Thanks for the link. I read it (or as much as I could stomach anyway) and I fail to see your point. Why should I care about any of that? And why should you? It's just a bunch of bickering about stuff that has always been bickered about on these boards.

Can't we get back to at least having the BWS functional again? That's what this thread is about, yes? I have never input a single thing into Fixpack, so I don't know how to do it. But you and others do (Alien do you read this?). Help me help you. I'll provide what needs to be replaced and where. You guys put that in. I guess I can always just do it in my own files to fix my own installation, but that seems a waste of effort, considering the state of the BWS right now.

Just to make clear

BWS and BWFixpack are open to anyone. They are hosted on Bitbucket and Github and both have tutorials for everyone to add/propose/modify their contents. You make a commit there with the changes you see necessary, and if it is valid, it will be merged into the download version.

There is no *boss* and no *secretary* for those tools, there are just a couple of modders who have done this already and may help you out with their know-how.

But it is you who wants to make a contribution and nobody keeps you from doing this.

And if BGT part of BWS is in the shape it is in, it is because those still using it made no effort to put their updates into BWS.

Edited by Roxanne, 13 February 2018 - 12:06 AM.

[Creepin]

You make a commit there with the changes you see necessary, and if it is valid, it will be merged into the download version.
...
There is no *boss* and no *secretary* for those tools

I don't get it: isn't the one who decide on his own discretion what deemed to be valid and what is not is, effectively, the "boss" of BWS?

[Roxanne]

You make a commit there with the changes you see necessary, and if it is valid, it will be merged into the download version.
...
There is no *boss* and no *secretary* for those tools

I don't get it: isn't the one who decide on his own discretion what deemed to be valid and what is not is, effectively, the "boss" of BWS?

A *Council of Seven* (BWS example) or Eight (BWFixpack) gives some assurance that there is some objective assessment. Any database needs some people who take care, just like the forum here needs some administrators/moderators.

 

PS - all of this is visible to anyone who visits the repositories, including who changed what when and why. Also documents discussions if there was no consent or contributions were rejected.

 

It is all open books for anyone interested. No cowled figures acting in the dark.

Edited by Roxanne, 13 February 2018 - 02:19 AM.

[Creepin]

Council of Seven

Thank you, I was not aware of that.

It is all open books for anyone interested.

Sadly this requires more than cursory knowledge of the principles of github/bitbucket/whatever operations.

Edited by Creepin, 13 February 2018 - 02:30 AM.

[Roxanne]

Council of Seven

Thank you, I was not aware of that.

It is all open books for anyone interested.

Sadly this requires more than cursory knowledge of the principles of github/bitbucket/whatever operations.

 

Sadly it requires no knowledge at all to throw stones at those who spend some effort to acquire such competence...

[Creepin]

Sadly it requires no knowledge at all to throw stones at those who spend some effort to acquire such competence...

Surely those good people spent their effort for some other goal than gaining protection from stones, right? Or else their effort was just misplaced and wasted.

[The Imp]

I suggest either to add noupdate switch to that setup as well or better just remove that section all together since it seems dabus added it for the sole purpose of updating the weidus before the installation starts. This solution would improve the BWS and cause all mod setups to be ran at it's original version, unless I'm missing something. Thoughts?

You miss the fact that the weidu.exe's that all the setup-modname.exe's are need to know what the others have dene before the install or the whole thing goes up the kaboom style. And they don't, if they are different versions, or coded to the current standard, aka the last version. That's why the autoupdate is there in the first place. And why the weidu.exe is made by a single guy at a time who's responsibility it is to also upkeep the code standard ... so there's no recursion errors.

Edited by The Imp, 13 February 2018 - 08:53 AM.

[enderandrew]

I agree that creating temporary workarounds for Weidu bugs in the Fixpack doesn't seem like a great approach.

If someone wants to submit new fixes otherwise to the Fixpack but is purely intimidated by using Github, presumably they could update their proposed fixes elsewhere and ask someone else to kindly commit them.

 

As for the bickering in the other thread, it only has me shaking my head. Everyone here has a shared love of Infinity Engine games and a desire to see them expanded with mods.

 

People actively maintaining their mods want to be kept in the loop if there are bug reports and fixes. That seems reasonable.

Not everyone has an email address listed in the author field. It is hard to assume or know something is still being actively maintained if there is no contact information listed there.

 

A reasonable compromise seems to be that any active modder who wants to be notified should be providing accurate contact information, and if that information exists, people should be using it to share bug reports or fixes they have. That really doesn't seem very difficult. Is there anyone who wouldn't agree to that?

[enderandrew]

@enderandrew

This time mods are not responsible for the issue so no one needs to be notified to fix anything. As for the rest of you post, you will be surprised when you read this: http://www.shsforums...ices-discussion

I read and referenced that thread.

As for the Weidu/Tobex issue, it does seem like while semantically you can't say mods are completely to blame because they were using a valid command which has now retroactively broken with a Weidu update. However, it does look like there is a simple fix for the issue by updating the Fixpack to use FILE_EXISTS instead of FILE_EXISTS_IN_GAME. I get that new releases of Weidu should try to avoid breaking old mods and should try to preserve backwards compatibility. If they don't want anyone using FILE_EXISTS_IN_GAME, then they should document that and officially deprecate that command.

How difficult would it be to do a replace all FILE_EXISTS_IN_GAME/FILE_EXISTS on the Fixpack and call it a day?

The Fixpack is actively maintained. So a simple solution is within grasp.

[The Imp]

As for the Weidu/Tobex issue, it does seem like while semantically you can't say mods are completely to blame because they were using a valid command which has now retroactively broken with a Weidu update. However, it does look like there is a simple fix for the issue by updating the Fixpack to use FILE_EXISTS instead of FILE_EXISTS_IN_GAME. I get that new releases of Weidu should try to avoid breaking old mods and should try to preserve backwards compatibility. If they don't want anyone using FILE_EXISTS_IN_GAME, then they should document that and officially deprecate that command.

Are yousure that it's weidu and not the mods that break themselves by using the WRONG command ... and weidu retroactively just fixing itself for the correct usage of the command. As you can read, CamDawg says, the MOD is using the wrong command.

[Creepin]

How difficult would it be to do a replace all FILE_EXISTS_IN_GAME/FILE_EXISTS on the Fixpack and call it a day?

Last time that I read WeiDU manual I got an impression that FILE_EXISTS and FILE_EXISTS_IN_GAME works differently and therefore could be used for different purposes with a different result in mind. This post seem to support the conclusion. How on earth can you replace one with another and hope things will work?

the mods that break themselves by using the WRONG command

While there's no arguing that Fixpack should have used correct command, there's an outstanding separate issue that mods were working and now they don't. That simple. That bad.

Edited by Creepin, 13 February 2018 - 11:05 AM.

[enderandrew]

As for the Weidu/Tobex issue, it does seem like while semantically you can't say mods are completely to blame because they were using a valid command which has now retroactively broken with a Weidu update. However, it does look like there is a simple fix for the issue by updating the Fixpack to use FILE_EXISTS instead of FILE_EXISTS_IN_GAME. I get that new releases of Weidu should try to avoid breaking old mods and should try to preserve backwards compatibility. If they don't want anyone using FILE_EXISTS_IN_GAME, then they should document that and officially deprecate that command.

Are yousure that it's weidu and not the mods that break themselves by using the WRONG command ... and weidu retroactively just fixing itself for the correct usage of the command. As you can read, CamDawg says, the MOD is using the wrong command.
 

 
 
If the command exists in Weidu, then it is available for people to use. If you don't want people to use the command, then deprecate it and remove it.

You can't blame someone for using something that is made available and in the documentation.

I think it makes sense to change the usage in Fixpack now as the quick and easy solution, but Weidu should also deprecate the command as well in the long run.

Last time that I read WeiDU manual I got an impression that FILE_EXISTS and FILE_EXISTS_IN_GAME works differently and therefore could be used for different purposes with a different result in mind. This post seem to support the conclusion. How on earth can you replace one with another and hope things will work?

You are correct. The command is in the documentation and it serves two different purposes. But when the regression was reported to Weidu devs, they're saying they never intended for the command to really work and they don't want people using it. Again, I'm arguing they should properly deprecate it then. But since we know it is currently broken in the current version of Weidu and the Weidu devs don't intend to fix it, the Fixpack needs to change which command they are using.

Edited by enderandrew, 13 February 2018 - 11:39 AM.