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 bigg
« on: February 24, 2006, 08:33:55 AM »

I maintain confidence that the_bigg will not make a huge mess of anything, but I suggest that encouraging him to go power mad and balls everything up is not the way to go. :)
The modder uses \ in a wrong position in banterpack\dialogues.

"jokes" aside (har har), I don't believe that allowing people to make biffs in a stabler way is detrimental. So far, KD, A64 et all have used the unreliable AT_*EXIT to make biffs in the main component, which means that in a chain uninstall-reinstall sequence everything is fubared (there are at least 5 threads asking to break backwards compatibility in to AT_*EXIT for biffing purposes).

No matter if it is done via AT_* or via MAKE_BIFF, there is the chance of fubaring an install. However, MAKE_BIFF has the benefit that it works with chain installs/reinstalls. A professional modder will (probably) add a new component with safeguards (EG, instructions to RTFM). If the user doesn't RTFM, then it's his fault.

Finally, let nature take his own course: IF_EVAL died once BUT_ONLY step in, so if MAKE_BIFF is so bad I'm sure it'll die, too. The difference is that MAKE_BIFF doesn't add an additional layer of bugs as IF_EVAL does  ;)
Posted by: devSin
« on: February 24, 2006, 08:33:16 AM »

As a note: segfaults mean that there has been a problem in the OCaml compiler, since OCaml itself doesn't have pointers/manual memory assignment, and as such any hard crash is officially Not My (or Weimer's) Fault.
There have been segfaults in WeiDU that were definitely Wes' fault, and not just "OMG OCaml sux!!!"
Posted by: SimDing0™
« on: February 24, 2006, 08:14:20 AM »

I guess I am fine with the bigg adding MAKE_BIFF to WeiDU provided that he says something along the lines of Weimer-spiel's "Do not ever ever ever for your whole entire life and afterlife use this."
Weimer's "do not use" labels have always been a running joke since they typically mark the most useful features in WeiDU.

Quote
At the end of the day, if the bigg wants to release MAKE_BIFF, then it is up to him.  Do whatever.  :)
This is the worst thing I have ever heard. It is, in fact, *vastly gayer* than asserting that modmakers can do whatever they feel like, because poor WeiDU updates are detrimental to all of us. I maintain confidence that the_bigg will not make a huge mess of anything, but I suggest that encouraging him to go power mad and balls everything up is not the way to go. :)
Posted by: the bigg
« on: February 24, 2006, 07:49:26 AM »

As a note: segfaults mean that there has been a problem in the OCaml compiler, since OCaml itself doesn't have pointers/manual memory assignment, and as such any hard crash is officially Not My (or Weimer's) Fault.

WeiDU v190 and later will be compiled without the --unsafe flag. Installation might be slower (in my tests, it goes somewhat like 5 seconds -> 6 seconds with this change), but chances are there will be less segfaulting.
Posted by: Ascension64
« on: February 24, 2006, 03:15:29 AM »

WeiDU crashes, KD, not fails installation.
Posted by: King Diamond
« on: February 24, 2006, 03:12:11 AM »

Quote
MAKE_BIFF cannot really compare to --make-biff.  If you use MAKE_BIFF, and WeiDU segfaults after this command, some modding illiterate people will find it very hard to manually add the appropriate entry to WeiDU.log and restore their installation the easy way.  I would believe that more people would feel suspicious about leftover data to even trust such an uninstallation process.  If you use --make-biff, and DOS segfaults and quits cmd after this command, people can STILL UNINSTALL the WeiDU mod without problems. 

As far as I understand  ;) MAKE_BIFF is controlled by WeiDU for 100% that means that if something is going wrong and WeiDU is not able to complete that command successfully it will just rollback all the modifications (as it's being done in all faults in other actions right now) and finish with an initial prompt. So what this discussion is all about?  How to prevent user from launching "format c:"?  ::)
Posted by: Ascension64
« on: February 23, 2006, 11:29:11 PM »

I guess I am fine with the bigg adding MAKE_BIFF to WeiDU provided that he says something along the lines of Weimer-spiel's "Do not ever ever ever for your whole entire life and afterlife use this." and make people drink too much.  In the practical context, it is not necessarily that someone's f00bared code will segfault WeiDU to the point that the installation goes down the drain.  Rather, the current situation is that mods will be made, and other mods will also be made that will not be intended to have compatibility with the former set of mods.  Incompatibilities of this kind, of which adventerous people will love to try out due to mis- or non-information of the inherent risks of installing a mod in the first place, sets up a prone environment for WeiDU failure.  At this stage, I do agree that MAKE_BIFF in WeiDU will likely cause problems if used.

MAKE_BIFF cannot really compare to --make-biff.  If you use MAKE_BIFF, and WeiDU segfaults after this command, some modding illiterate people will find it very hard to manually add the appropriate entry to WeiDU.log and restore their installation the easy way.  I would believe that more people would feel suspicious about leftover data to even trust such an uninstallation process.  If you use --make-biff, and DOS segfaults and quits cmd after this command, people can STILL UNINSTALL the WeiDU mod without problems.  This is if, of course, chitin.key is backed up appropriately.  I do strongly agree that people are warned, either generally or specifically, about the risks of handling a mod in the first place, but I do not think that a special warning is necessary for even the most sensitive commands.  In fact, people should treat the most minor vulnerability as a worst-case scenario.  For example, a generic radioactive sign is put in places where radioactivity MAY be used.  The radioactivity used is often contained in a separate room, and much of the time is relatively harmless.  But whenever anyone enters the room, or uses radioactivity, it is treated as if it could cause permanent damage.

People may not agree about BIFFing anything, but in BGT-WeiDU I provide ample support for and warranty against this kind of failure.  If you do not know already, the cmdweidu.exe segfaults on --biff-get-rest, and as far as I know, this hasn't even been investigated at the OCamL code level.  But, you can STILL UNINSTALL.  I list potential code vulnerabilities and resolutions here (as of BGT-WeiDU v1.00 internal test):
  1. AT_NOW.  If DOS/cmdweidu.exe segfaults, WeiDU will still run through the rest of the installation, but FAIL is used to protect against any of the functions falling apart.  Note that this section evokes biff-get-rest and --traify-tlk into directories that don't exist in a vanilla BG2:ToB installation, so segfaulting only leaves behind junk that won't affect the game.
  2. --biff-get-rest during AT_INTERACTIVE_EXIT.  Known crashes and problems when IE-related CDs are in drives, or even when no CDs are in drives.  Described above - you can still uninstall.
  3. --make-biff during AT_INTERACTIVE_EXIT. No reported problems.  If there is a segfault during .biffing and chitin.key gets corrupt, again you can still uninstall.  chitin.key is restored.
  4. dialog.tlk corruption due to anything.  A manual backup is provided.  Uninstallation will prompt users to restore dialog.tlk.  Failing that, the readme has a whole FAQ question dedicated to restoring dialog.tlk.  All troubleshooting sections ask manual restoration of dialog.tlk.  The instructions are transparent.
  5. AT_UNINSTALL.  WeiDU will continue uninstallation even if DOS segfaults.  A number of junk will remain in certain game folders (i.e. data\).  chitin.key is still restored, and dialog.tlk is still prompted for restoration
  6. Disclaimer.  I note explicitly that users are downloading, opening, extracting, running, using the modification I release at their own risk.  I also state that I will not be responsible for any damage done to software, hardware, life as a result of any of the above actions performed on the modification.  If people think that --make-biff will compromise anything, then it is up to them to use it.  If people are such procrastinators that they do not take time to read the readme, then there is nothing I can do about them.  How many people read the commercial disclaimer in its entirety before pressing the next button during the installation of any commercially released software?  How many people do the same with EULA?  How many even read the installed readme?
  7. WeiDU uninstall segfault.  If the segfault occurs before AT_UNINSTALL (which runs after uninstallation of patched/copied files), then the net result is nothing happened.  If WeiDU segfaults during final outputting of dialog.tlk, a manual backup can be restored.  In most cases, since WeiDU updates WeiDU.log near the very end of uninstallation, a failed uninstall will still allow the user to uninstall anyway.

Have I put forward enough of a case to allow support for --make-biff in BGT-WeiDU?  I will not be using MAKE_BIFF.

BIFFing is important for the low-end user.  It can be as drastic as reducing download size.  Many people in the community may not experience any performance increase when BIFFing files.  Other people might find a performance increase.  It is not necessarily the method the game engine uses to read resources that determines this (although I don't dispute that there is an element of engine behaviour in this phenomenon), but also hardware, and even software, bottlenecks can determine the change.  I can refer to disk fragmentation to be one of them, hardware combinations as another, and software running in the background as yet another.  We don't have any right to tell people that they must defragment their disk, or disable antivirus software, or whatever.  We do have, however, have the option of telling people that they could experience performance issues if they don't do these things.  At a commercial level, it is more important to widen the target audience by providing support for idiots (not necessarily the complete idiots).  Since this is a hobby, the onus is much more on the user of the mods, but still, how much satisfaction would you get if you made a brilliant mod that nobody could use, no matter how exaggerated this example is?  I biff because of the slightest possibility that some users out there will have increased performance and so will increase the fanbase somewhat, but I also biff with the necessary precautions (as above).

Finally, just because we do/don't see reports of multi-coloured failures due to, or the good/bad effects of, BIFFing, or even other things, it doesn't mean that they aren't/are happening.  Active users will post on the forums.  New users may register and post on the forums.  Others may just read, not care, find their own way out of it, or whatever other solution.  I don't think you can justify the presence/absence of something just by having no reports on it, while sometimes you can't even justify the same thing because it (didn't) happen(ed) to you.  So, we can say that anything is possible, but you can at least try to make life easier for others by BIFFing, or introducing safeguards, or whatever.

At the end of the day, if the bigg wants to release MAKE_BIFF, then it is up to him.  Do whatever.  :)
Posted by: the bigg
« on: February 23, 2006, 01:57:44 PM »

(In fact, trying to create a non-existent creature via script simply does nothing. But yes, I acknowledge what you're saying, and still think it's going to be vastly less destructive than a KEY issue.)
Meh, you compile to an always running script HasSpell(THIEF_SET_SNARE_OR_HOWEVER_IS_IT_CALLED) and you get a segfault before you reach the point where you install Scriptable Spells, then - or something. I recall that trying to spawn a non-existing or broken file of type X will CTD, but I can't recall a specific X.
Posted by: SimDing0™
« on: February 23, 2006, 01:53:11 PM »

baldur.bcs tries to spawn a creature because the difficulty variable isn't set, while the .cre wasn't copied to the override. Automatic CTD.
(In fact, trying to create a non-existent creature via script simply does nothing. But yes, I acknowledge what you're saying, and still think it's going to be vastly less destructive than a KEY issue.)
Posted by: the bigg
« on: February 23, 2006, 01:14:48 PM »

You'll have to discuss with KD, A64 and HtP for that - I am in a neutral position, since WeiDU is a language, not a law-maker; I allow you to
Code: [Select]
COPY + ~bgmain.exe~ ~bgmain.exe~
  FOR (i = 0; i < SOURCE_SIZE; i+=1) BEGIN
    WRITE_BYTE i 0
  END
It's up to you to warn people of possible side effects.

And still, MAKE_BIFF is easier and more stable than AT_* can ever be. AT_EXIT commands are run in LIFO order, while AT_UNINSTALL commands are run in FIFO order, meaning that anything non-trivial is doomed to failure.
Posted by: CamDawg
« on: February 23, 2006, 01:10:39 PM »

I don't necessarily agree with Sim and Cam that TP2 MAKE_BIFF is evil; I don't see it any differently than some horribly coded BAT garbage that's forced to run at exit. I do agree that BIFFing is, in most cases, completely pointless. I've never seen a mod include anything that's even decent enough to be worth the effort.

This is a more accurate description of my position. I happen to think biffing, whether via a tp2 call or an external shell script, is not something a mod should be doing. Something with these consequences should, again, be an explicit and informed decision by the player. I don't see either of those conditions being satisfied by a mod, regardless of whether they use shiny tp2 commands or shell script grunge.
Posted by: the bigg
« on: February 23, 2006, 01:03:26 PM »

I had 1.4 Gb of files in the override once (I had at least ten NPCs and other Wav-heavy mods) and the game ran like shit. I biffed all WAV files and then it ran normally. So I'm not buying that WAV files in the override don't slow the game.

If a mod segfaults, you still have a fubared install - you have to either append manually the lines to weidu.log and uninstall it, or restore your game. Let's say that you get a segfault in Improved Difficulty System. baldur.bcs tries to spawn a creature because the difficulty variable isn't set, while the .cre wasn't copied to the override. Automatic CTD.
Posted by: devSin
« on: February 23, 2006, 01:00:49 PM »

At least on Windows, if the override size is > than 1 GB, the game will reduce to a crawl irregardless of your hardware. Thus, I listed the usual large files (WAV BAM, plus all area-graphic files, since TIS, WED, BMP and MOS must go in the same biff).
Fair enough, although normal WAVs are horrifically small, as are most WED, BMP, and MOS files. BIFFing them isn't going to "make your game faster" just because you're forced into BIFFing them with the TIS file, though.

I have no idea about the > 1 GB thing, though. I'd be more suspicious of atrocious numbers of files than file size, as the game surely maintains some sort of index (I don't see that they could do a fs check for x in the override for each and every resource loaded)?

(Not to mention .MVE files, which have to be biffed to work. Currently JZ handles this in a very unreliable way, since installs with INTERACTIVE and uninstalls with non-INTERACTIVE AT_* variants).
I don't necessarily agree with Sim and Cam that TP2 MAKE_BIFF is evil; I don't see it any differently than some horribly coded BAT garbage that's forced to run at exit. I do agree that BIFFing is, in most cases, completely pointless. I've never seen a mod include anything that's even decent enough to be worth the effort.

Once the files are accessed, there should be no difference in performance. Excepting odd behaviors in Windows, the only thing that should slow the game down is having to wait on the system to access each resource file separately, instead of accessing a single BIFF. The rest should be smooth sailing.

Quote
I don't. Given that there's never been a single complaint about the multitude of NPC mods that dump voicing or even song WAVs into the override, I think there's very little problem here.
Noted. I simply don't know when a WAV would be loaded (either the first time it plays, or pre-cached), unlike most graphics which are loaded with the area (TIS, BMP, MOS) or as-needed (BAM, some BMP, maybe some MOS). I also don't know how long they're retained, if at all (audio turnaround rates should be higher than images, I suspect).

EDIT: personally, if the audio file is small, I'd try referencing the sound from the creature file in one of the unused sound slots. That may get the game to load the sound early and hold on to it while the actor exists, and may reduce PlaySound() suckage. Maybe not...
Posted by: SimDing0™
« on: February 23, 2006, 12:45:10 PM »

I concede WAV files
I don't. Given that there's never been a single complaint about the multitude of NPC mods that dump voicing or even song WAVs into the override, I think there's very little problem here. (I do know that WAV files are loaded when required--it's this delay that makes PlaySound such a poor substitution for using proper ACM files.)
Posted by: the bigg
« on: February 23, 2006, 12:24:52 PM »

At least on Windows, if the override size is > than 1 GB, the game will reduce to a crawl irregardless of your hardware. Thus, I listed the usual large files (WAV BAM, plus all area-graphic files, since TIS, WED, BMP and MOS must go in the same biff).

(Not to mention .MVE files, which have to be biffed to work. Currently JZ handles this in a very unreliable way, since installs with INTERACTIVE and uninstalls with non-INTERACTIVE AT_* variants).