Wrye Bash Wizards : IV

» Wed Mar 30, 2011 1:26 pm

This is mostly for the modders in the house. I'm keeping this a separate thread from the Wrye Bash thread so as not to clutter it up.

To start off, I'm fairly pleased with Wrye Bash's wizards. It was a "first" attempt at a language interpreter (first = after two rewrites) and it met all of my objectives.
That being said, I'm sure there are some areas that it can improved in. Got gripes? Got ideas? Got things you really wish were available for wizards? This is were to let me know. I want you feedback! I want your criticism!

Now, keep in mind the underlying goals here:

THE UNBREAKABLE RULE: Don't do anything that cannot be done manually through the default BAIN interface. This doesn't mean that if you can't do it, it wont get added; but there will have to be a way to add it into the default interface as well.
Ease of use for the user. This mostly applies to the UI side of wizards, like the different screens available, and what is shown on them.
Ease of use for the modder. It has to be easy for wizard writers to do their job, and for someone else to read that wizard to figure out what it's doing. It also should be easy to lean how to make a wizard do what you want, without anything extra other than the language reference. This is one of the areas that I don't have much idea on. I wrote the language, so I'm already stuck in my ways (more or less)... but some of you other guys might be missing different constructs, or don't like the way the language syntax is, etc. Let me know!
Built in functions, etc. Another area I'm polling for ideas on. I've more or less run out of ideas here, except when the occasional feature gets added to BAIN, adding an appropriate function to the wizards as well.
Backwards compatability: newer versions of Bash will have to be able to execute older wizards. So no breaking changes. I'm willing to give on this, with a compelling enough argument, but remember I will also have to write something to convert old syntax wizards into new syntax wizards.

Now, for the ideas: [New][Currently being worked on][Finished]

[Lojack] User defined functions: Something along the lines of this syntax:

Spoiler
Function MyFunction( argument, argument, etc )
...code here...
EndFunction
[Lojack] Shader package editing (I'm already working on this one). Basically, the idea is, if you put a .vso or .pso file in the right folder structure in an installer, Wrye Bash will recognize it and automatically insert it into the applicable sdp. My current idea is, say you want to replace BOLT.pso in shaderpackage019.sdp. You would put your replacement in "YourPackage\Shaders\shaderpackage019.sdp\BOLT.pso" Other thoughts on this are welcome.
[Arthmoor][andalaybay]: Look into setting "Auto-anneal/Install Wizards" to ON by default. Done: changed to ON by default. I also added a new checkbox to the Finish page, so even if this isn't on, the user can choose to install the package after the wizard.
[Arthmoor][andalaybay]: Figure out if it's still a good idea not to enable mods by default after installing.
[andalaybay]: Allow the wizard to make changes to INI files, to allow configuring it from within the wizard.
- Done: http://oblivionworks.svn.sourceforge.net/viewvc/oblivionworks/Programs/Wrye%20Bash/Mopy/wizards.html#EditINI
- Note that the tweak only gets automatically applied if the target INI resides in the same installer as the wizard.
- I might need to change the naming scheme on the generated tweak file, to not get overridden
- I might possibly allow tweaks to Oblivion.ini to get applied as well
[alt3rn1ty]: Fix the slowdown caused by extracting images for wizards. This is most noticable when a solid archive is used. EDIT: BAIN will now extract all images in the package at the beginning of the wizard. This will slow down initial execution a little (noticeable on large files, or archives will a lot of images), but improve dialog responsiveness. Currently BAIN doesn't try to determine which images to extract, it just does them all. This saves time for solid archives, but probably makes it slower for non-solid archives. The best comprimise I could come up with, but suggestions are always welcome.
[Surazal]: Ability to retrieve folder names. OBMM syntax is
Spoiler
For Each DataFolder [RecurseSubfolders] [SearchString]

Allows you to process the BAIN sub packages without having to hardcode all the folder names. This means I can add new folders without having to change the script and reduces typo issues.
[Surazal]: Ability to retrieve file names. OBMM syntax is
Spoiler
For Each DataFile [RecurseSubfolders] [SearchString]

I use this capability to derive an associated ESP name by manipulating the file name string. For example, if the sub package contains "Better Cities Full Vwalk.esp" I can derive "Better Cities Full.esp" and check if it is installed in order to determine whether the sub package should be activated.
[Surazal]: Ability to execute script contained in a variable. Syntax is:
Spoiler
Exec(lines)

Runs a string as if it were part of the script. Can be used with variables and loops to dynamically construct option menus.
[Surazal]:Ability to change file names during installation. OBMM syntax is
Spoiler
CopyDataFile

The end result is that a descriptive KF file name is copied to a standard KF file name that is referenced in the ESPs that use the animation.
Example: CopyDataFile "Mur_Zik 25% faster sixy walk with facial expressions.kf" to "0FemaleVariableWalk_Gorgeous.kf"
We already have support for renaming esm's and esp's, although it's not very well tested so there may be a few bugs. It wouldn't be hard to extend this to data files, but I do want to be sure it's working right before more people start using it.
[myk002][alt3rn1ty]: Enabling the "Previous" button. A bit trickier than it might seem at first, because the wizard screens are dynamically generated. There isn't a clear "Previous" page. An option would be to remember the user's answers for each page, then restart the script from the beginning, supplying those answers up to the point that the "Previous" page is reached.
[alt3rn1ty][Metallicow]: Resizable wizards!
[Metallicow][alt3rn1ty: Now make them remember their previous size - Done. Wizards remember both their previous size, and position now.
[wrinklyninja]: Make it more obvious that you can double click on an image to see it in full. I can have the cursor change to a magnifying glass, that should help.
[Arthmoor]: Detect if a mod is active via Wizard function.
- Implemented with the GetEspmStatus function.
[alt3rn1ty]: Allow SelectOne dialogs to show an image and text in the 'Description' box, even when no default option is specified.
[Metallicow]: Message box and Display Image.

Lets get those creative juices flowing.

» Wed Mar 30, 2011 12:22 am

I've only poked at this stuff on the surface and tested it with the RAEVWD wizard. While I was doing that, I was confused at first that nothing seemed to happen after hitting the checkbox to apply the chosen options after going through the wizard. It would be nice if instead of simply falling out to the BAIN interface it actually installed what you had selected without the user having to go the extra step to right click the package and select install.

You've already mentioned shader editors, which IMO would be the last bastion of resistance from the OBMM holdouts.

» Wed Mar 30, 2011 7:50 am

Well the other big one for us OBMM holdouts is the ability to configure the mod through the script. I believe there are plans in place to have BAIN wizards modify the ini file of a mod, correct? So while installing the mod, the user can also answer questions to get it configured for him too, like OBMM scripts do.

In addition to it automatically installing the selections from the wizard, as Arthmoor requested, I would also like it to activate the plugins! I can't tell you how often I install a mod, exit WB, load my game and then wonder why nothing is working. I use BOSS to sort my load order, so if I don't have to rebuild my bash patch, I don't go to the mods tab. And I've had issues with users coming to me complaining about things not working and it's because the mod didn't actually get activated, so I know I'm not the only one who does this!

» Wed Mar 30, 2011 6:09 am

Yes, let me also second automatic activation of installed mods. The user surely wants to do this or they wouldn't have bothered, yes?

» Wed Mar 30, 2011 7:18 am

I have a few slight moans on the topic - But first I would like to mention the work http://www.tesnexus.com/downloads/file.php?id=37230 who is open to requests

Moans - Just two from a user viewpoint; And both related to the same thing ... Screenshots

a) Could the wizard window by made bigger to accommodate them, or is it restricted by a lowest common denominator screen size? - For example AWLS screenshots even though pre-processed to resize them for presentation some get chopped around the edges in presentation and the user does not quite see the images as intended.

B) Execution of the wizard seems to seriously slow down when Screenshots are involved, It feels like the extracting of the relevant files and pre-processing of the images is the culprit in the slow-down. I tried re-sizing all of the images in awls once with no .jpg compression for each and a lower resolution for each to fit in the window quicker ... resulted in no difference in execution.

~ It would be nice if instead of simply falling out to the BAIN interface it actually installed what you had selected without the user having to go the extra step to right click the package and select install.

It does If you select 'Auto-Anneal/Install Wizards' in the main Installers menu, it will automatically install upon wizard completion.

» Wed Mar 30, 2011 2:56 pm

I've only poked at this stuff on the surface and tested it with the RAEVWD wizard. While I was doing that, I was confused at first that nothing seemed to happen after hitting the checkbox to apply the chosen options after going through the wizard. It would be nice if instead of simply falling out to the BAIN interface it actually installed what you had selected without the user having to go the extra step to right click the package and select install.

In addition to it automatically installing the selections from the wizard, as Arthmoor requested, I would also like it to activate the plugins! I can't tell you how often I install a mod, exit WB, load my game and then wonder why nothing is working. I use BOSS to sort my load order, so if I don't have to rebuild my bash patch, I don't go to the mods tab. And I've had issues with users coming to me complaining about things not working and it's because the mod didn't actually get activated, so I know I'm not the only one who does this!

Yes, let me also second automatic activation of installed mods. The user surely wants to do this or they wouldn't have bothered, yes?

I don't know if you guys know, but there is an option in the BAIN menu: Right click on a column header or open space->"Auto-anneal/Install Wizard". It's disabled by default, maybe we should look into having it enabled by default?

As for the auto-enable esps/esms, I'll have to look into that. I recall there being a reason behind why it was done this way, I'm just not sure.

Well the other big one for us OBMM holdouts is the ability to configure the mod through the script. I believe there are plans in place to have BAIN wizards modify the ini file of a mod, correct? So while installing the mod, the user can also answer questions to get it configured for him too, like OBMM scripts do.

Good one there. That was something I had thought over before, but didn't think of it when I was writing this.

» Wed Mar 30, 2011 7:41 am

I have a few slight moans on the topic - But first I would like to mention the work http://www.tesnexus.com/downloads/file.php?id=37230 who is open to requests

Moans - Just two from a user viewpoint; And both related to the same thing ... Screenshots

a) Could the wizard window by made bigger to accommodate them, or is it restricted by a lowest common denominator screen size? - For example AWLS screenshots even though pre-processed to resize them for presentation some get chopped around the edges in presentation and the user does not quite see the images as intended.

B) Execution of the wizard seems to seriously slow down when Screenshots are involved, It feels like the extracting of the relevant files and pre-processing of the images is the culprit in the slow-down. I tried re-sizing all of the images in awls once with no .jpg compression for each and a lower resolution for each to fit in the window quicker ... resulted in no difference in execution.

Missed your post while I was typing!

a) It could be bigger. Or I could look into the method used to resize the pictures. I could see about allowing the wizard to be resizable as well.
B) This can be a problem if the BAIN package is packed as a solid archive. 7z has to read through the whole archive to the point where the image is, just so it can extract it. Then, each time BAIN runs into a new image to extract, it does this again. Some possible options: Pre-parse the wizard file, getting all of the images that will need to be extracted, and pull them out all at once. This will slow down the load up time if there are any images to extract, but once they're extracted, it should be fine. Other than that, the only suggestion I can offer is for mod packagers to not use solid compression if they are worried about slowdowns when the images are first extracted. Note that this problem also affects extracting the wizard.txt file, you can notice some packages take a while for the wizard to startup.

EDIT: Also another thing I remembered in response to a). You can double click on the image to open the image in the system's associated program. It's not very obvious, but there you have it.

» Wed Mar 30, 2011 5:53 am

I'd like to second/third/nth all the current suggestions, they're all things I was going to put down myself as being important.

Regarding the above on images in Wizards, I think that being able to double-click to view the image in a larger size is enough, but perhaps add a small note that it is possible below the image window?

As for solid vs. non-solid archives, I'd be happy to make non-solid archives, but 7-zip's default is solid, and I've got to go through additional dialogs to make it non-solid. It's a much longer process and I for one can't really be bothered when the alternative is a right-click and hitting "add to 'archive name.7z'"... I don't know of any way to change the default.

» Wed Mar 30, 2011 4:49 am

When making a 7z archive, use the "add to archive" option from the right-click menu. The "Solid block size" selector has an option for non-solid. Once you change that, 7z defaults to that the next time you use it.

The downside is that non-solid compression means larger file sizes. Testing on just our loose resources for AN, the solid pack file is 153MB and the non-solid pack file is 173MB. Pretty significant, especially for those of us with limited bandwidth.

» Wed Mar 30, 2011 8:09 am

@Lojack: I saw your comments about editing the ini file. Don't forget, that even though we call them ini files, they are really batch scripts. We have to set them up so that the game can read them with RunBatchScript.

So the syntax is:

set QuestName.VariableName to xx

That may still line up with what you are saying, but we don't have headings in these files. If we put them in, we'd have to stick a semi-colon in front so the game treats it like a comment.

So for example, here's a sample from Oblivion XP:

Set ObXPSettings.attributePointsPerLevel 	to 13		; 13Set ObXPSettings.skillPointsPerLevel 		to 48		; 48Set ObXPSettings.trainingSessions		to 5		; 5Set ObXPSettings.trainingCostMult		to 10		; 10

» Wed Mar 30, 2011 11:12 am

There are some features in OBMM that I find really useful and make me use it for my mods...

Ability to retrieve folder names
OBBM Syntax: For Each DataFolder [RecurseSubfolders] [SearchString]

Allows you to process the BAIN sub packages without having to hardcode all the folder names. This means I can add new folders without having to change the script and reduces typo issues.
Ability to retrieve file names
OBMM Syntax: For Each DataFile [RecurseSubfolders] [SearchString]

I use this capability to derive an associated ESP name by manipulating the file name string. For example, if the sub package contains "Better Cities Full Vwalk.esp" I can derive "Better Cities Full.esp" and check if it is installed in order to determine whether the sub package should be activated.
Ability to execute script contained in a variable
OBMM Syntax: ExecLines

Runs a string as if it were part of the script. Can be used with variables and loops to dynamically construct option menus.
Ability to change file names during installation
OBMM Syntax: CopyDataFile

I know this one has problems with the BAIN installation philosophy, but I have mentioned it because it is one of OBMM's features I use to allow animation file configuration via a menu driven interface. The end result is that a descriptive KF file name is copied to a standard KF file name that is referenced in the ESPs that use the animation.

Example: CopyDataFile "Mur_Zik 25% faster sixy walk with facial expressions.kf" to "0FemaleVariableWalk_Gorgeous.kf"

» Wed Mar 30, 2011 12:56 am

@Surazal: yeah, renaming is tricky. from an installer point of view, it is a one-way operation -- if a file gets overwritten, how would we anneal it? We could keep the state to remember what installer name mapped to which installed file name, but that could get messy. Maybe what is needed here is something like a BCF wizard that would do the mapping into another installable package, which would have a normal, non-renaming wizard to run?

@lojack: I played around with getting the wizard window to resize properly:

--- Mopy/belt.py        (revision 890)+++ Mopy/belt.py        (working copy)@@ -130,13 +130,14 @@ #--------------------------------------------------- class InstallerWizard(wiz.Wizard):     def __init__(self, link, subs):-        wiz.Wizard.__init__(self, link.gTank, -1, _('Installer Wizard'))+        wiz.Wizard.__init__(self, link.gTank, -1, _('Installer Wizard'), style=wx.RESIZE_BORDER)         #Hide the "Previous" button, we wont use it         self.FindWindowById(wx.ID_BACKWARD).Hide()

but I had trouble getting the window to respect a minimum window size, regardless of where I called SetMinSize(). It would expand properly, but it would allow the window to be resized too small, and cut off widgets.

edit: seeing that diff reminded me of something -- I remember a request from the forums to enable the "Previous" button.

» Wed Mar 30, 2011 5:59 am

~ I remember a request from the forums to enable the "Previous" button.

Do you mean as in go back - Thats something I forgot to ask about earlier, get three quarters way through a slow wizard like awls and realise you just selected the wrong choice on the last question ... Only option is cancel and start again.

"Do you use Bomrets SI Pack?" - Yes ... wait, no thats something else aaaagh!

B) This can be a problem if the BAIN package is packed as a solid archive.

Thanks for that Lojack, going to try re-packing my BAINs' idc, I think most of them are solid archives at the moment.

» Wed Mar 30, 2011 1:21 pm

Gettin the wizard window to resize is my biggest concern. Or it at least needs to be bigger. The images scaling right also was another.
One thing I do miss from OBMM is the small mod pics in the corner for each OMOD. Maybe add a small panel or whatever to the installers tab to display a small scaled pic from inside the archive.
Screenshot with no extention would be fine, just as OBMM does. Maybe have it reside in the Wizard Images folder...?

Other than that, I think everything else for the moment has been proposed.

Thanks for continuing to improve Wizard script.

Side note: Oh, and TES4WizBAIN v0.02 is out. No known bugs yet.

» Wed Mar 30, 2011 1:41 am

Figure out if it's still a good idea not to enable mods by default after installing.

The only one I can think of that I have installed where I would not want all esps at the moment is Cobl (it doesn't have a wizard but for arguments sake), which has them all in Core files sub-package.

In my case I do not use Cobl Races.esp - However after a wizard is done installing, a simple de-select in the esp filter box and anneal finishes that job off.

Moving on to the mods tab from there, a re-build of the bashed patch is now required, and any mods ticked these days are automatically picked up to be de-selected if they are deemed to be mergeable .....

So as far as I can see theres no need not to select them if the intention was to install anyway.

» Wed Mar 30, 2011 7:57 am

I'd like to second/third/nth all the current suggestions, they're all things I was going to put down myself as being important.

Regarding the above on images in Wizards, I think that being able to double-click to view the image in a larger size is enough, but perhaps add a small note that it is possible below the image window?

As for solid vs. non-solid archives, I'd be happy to make non-solid archives, but 7-zip's default is solid, and I've got to go through additional dialogs to make it non-solid. It's a much longer process and I for one can't really be bothered when the alternative is a right-click and hitting "add to 'archive name.7z'"... I don't know of any way to change the default.

When making a 7z archive, use the "add to archive" option from the right-click menu. The "Solid block size" selector has an option for non-solid. Once you change that, 7z defaults to that the next time you use it.

The downside is that non-solid compression means larger file sizes. Testing on just our loose resources for AN, the solid pack file is 153MB and the non-solid pack file is 173MB. Pretty significant, especially for those of us with limited bandwidth.

I'm not pushing for non-solid compression, because it really does save a lot of space on larger downloads. I was just pointing out the drawback (slowdown of wizards). But - ease of use for the modder, so I'm looking at ways to speed it up when solid compression is used.

@Lojack: I saw your comments about editing the ini file. Don't forget, that even though we call them ini files, they are really batch scripts. We have to set them up so that the game can read them with RunBatchScript.

So the syntax is:

set QuestName.VariableName to xx

Yeah, I'm thinking use the same command, but Bash will be able to tell if it's an INI or a script, and adjust accordingly. Also, I suppose rearrange the ordering of the arguments, so the Heading is last and optional

Ability to retrieve folder names
OBBM Syntax: For Each DataFolder [RecurseSubfolders] [SearchString]

Allows you to process the BAIN sub packages without having to hardcode all the folder names. This means I can add new folders without having to change the script and reduces typo issues.
Ability to retrieve file names
OBMM Syntax: For Each DataFile [RecurseSubfolders] [SearchString]

I use this capability to derive an associated ESP name by manipulating the file name string. For example, if the sub package contains "Better Cities Full Vwalk.esp" I can derive "Better Cities Full.esp" and check if it is installed in order to determine whether the sub package should be activated.

These are a bit harder, but doable. I'll add them to the list

Ability to execute script contained in a variable
OBMM Syntax: ExecLines

Runs a string as if it were part of the script. Can be used with variables and loops to dynamically construct option menus.

Another good one, I can add that as well.

Ability to change file names during installation
OBMM Syntax: CopyDataFile

I know this one has problems with the BAIN installation philosophy, but I have mentioned it because it is one of OBMM's features I use to allow animation file configuration via a menu driven interface. The end result is that a descriptive KF file name is copied to a standard KF file name that is referenced in the ESPs that use the animation.

Example: CopyDataFile "Mur_Zik 25% faster sixy walk with facial expressions.kf" to "0FemaleVariableWalk_Gorgeous.kf"

Like you said, this one is a bit tricky. We already have support for renaming esm's and esp's, although it's not very well tested so there may be a few bugs. It wouldn't be hard to extend this to data files, but I do want to be sure it's working right before more people start using it.

@lojack: I played around with getting the wizard window to resize properly:

--- Mopy/belt.py        (revision 890)+++ Mopy/belt.py        (working copy)@@ -130,13 +130,14 @@ #--------------------------------------------------- class InstallerWizard(wiz.Wizard):     def __init__(self, link, subs):-        wiz.Wizard.__init__(self, link.gTank, -1, _('Installer Wizard'))+        wiz.Wizard.__init__(self, link.gTank, -1, _('Installer Wizard'), style=wx.RESIZE_BORDER)         #Hide the "Previous" button, we wont use it         self.FindWindowById(wx.ID_BACKWARD).Hide()

but I had trouble getting the window to respect a minimum window size, regardless of where I called SetMinSize(). It would expand properly, but it would allow the window to be resized too small, and cut off widgets.

Ok, I'll take a look and see if I can come up with anything.

edit: seeing that diff reminded me of something -- I remember a request from the forums to enable the "Previous" button.

Do you mean as in go back - Thats something I forgot to ask about earlier, get three quarters way through a slow wizard like awls and realise you just selected the wrong choice on the last question ... Only option is cancel and start again.

"Do you use Bomrets SI Pack?" - Yes ... wait, no thats something else aaaagh!

The "Previous" button thing is a bit trickier than it might seem at first (I'm sure you've looked at it myk002). Because the wizard screens are dynamically generated, there isn't a clear "Previous" page. An option would be to remember the user's answers for each page, then restart the script from the beginning, supplying those answers up to the point that the "Previous" page is reaced. That could work.

Gettin the wizard window to resize is my biggest concern. Or it at least needs to be bigger. The images scaling right also was another.
One thing I do miss from OBMM is the small mod pics in the corner for each OMOD. Maybe add a small panel or whatever to the installers tab to display a small scaled pic from inside the archive.
Screenshot with no extention would be fine, just as OBMM does. Maybe have it reside in the Wizard Images folder...?

Other than that, I think everything else for the moment has been proposed.

Thanks for continuing to improve Wizard script.

Side not: Oh, and TES4WizBAIN v0.02 is out. No known bugs yet.

I'll look into it. But then we again run into the problem of extrating images. I suppose it could be a popup menu option, like "Extract Package Image" or something or other, to tell Bash to extract said image for use in the UI, or not.
Oh, and conrats :clap:

Great stuff guys, I'll add it to the OP now.

» Wed Mar 30, 2011 10:48 am

@lojack: I played around with getting the wizard window to resize properly:

--- Mopy/belt.py        (revision 890)+++ Mopy/belt.py        (working copy)@@ -130,13 +130,14 @@ #--------------------------------------------------- class InstallerWizard(wiz.Wizard):     def __init__(self, link, subs):-        wiz.Wizard.__init__(self, link.gTank, -1, _('Installer Wizard'))+        wiz.Wizard.__init__(self, link.gTank, -1, _('Installer Wizard'), style=wx.RESIZE_BORDER)         #Hide the "Previous" button, we wont use it         self.FindWindowById(wx.ID_BACKWARD).Hide()

but I had trouble getting the window to respect a minimum window size, regardless of where I called SetMinSize(). It would expand properly, but it would allow the window to be resized too small, and cut off widgets.

I just tinkered around with this, and I had no problem with setting it to:

wiz.Wizard.__init__(self, link.gTank, -1, _('Installer Wizard'), style=wx.DEFAULT_DIALOG_STYLE|wx.RESIZE_BORDER)

So I think I'll be adding it in, once I also get the images to resize as well.

» Wed Mar 30, 2011 1:52 pm

And this correctly stops the window from being sized too small?

» Wed Mar 30, 2011 12:29 pm

And this correctly stops the window from being sized too small?

Yes...at least I haven't been able to break it.

Along those lines, I've just committed a few changes to the svn.

1) I changed the way image resizing is calculated, so now the whole image will be shown no matter what. This can leave empty space to the left/right or above/below, but everything can be seen now
2) Made the wizard dialog resizeable. Images in the SelectOne/SelectMany windows will resize with it.
3) Made the cursor change to a magnifying glass when it's over an image, to clue into the fact that it can be double-clicked or middle-clicked to open

Hopefully this improves things. Next stop is probably to work on extracting all the images at the beginning, to speed up execution when solid compression is used.

» Wed Mar 30, 2011 10:17 am

Yes...at least I haven't been able to break it.

Along those lines, I've just committed a few changes to the svn.

1) I changed the way image resizing is calculated, so now the whole image will be shown no matter what. This can leave empty space to the left/right or above/below, but everything can be seen now
2) Made the wizard dialog resizeable. Images in the SelectOne/SelectMany windows will resize with it.
3) Made the cursor change to a magnifying glass when it's over an image, to clue into the fact that it can be double-clicked or middle-clicked to open

Hopefully this improves things. Next stop is probably to work on extracting all the images at the beginning, to speed up execution when solid compression is used.

Absolutely Perfect. Exactly what I was wanting. Now to remake my Wizard Images a bit nicer, the way they should have been.
And I can see the end of those long named patches. Wooohooo! No more confusion on which patch it selected.

» Wed Mar 30, 2011 2:35 am

Not sure if this is really entirely wizard related or BAIN in general. But....

Any chance of being able to edit the comments field for an installer to use for short instructions? It's been asked for before but I figured I may as well ask again while attention is focused in this general direction

» Wed Mar 30, 2011 9:42 am

Not sure if this is really entirely wizard related or BAIN in general. But....

Any chance of being able to edit the comments field for an installer to use for short instructions? It's been asked for before but I figured I may as well ask again while attention is focused in this general direction

Also, I have askeded before that there should be a simple way to save user comments. In my opinion they should not be overwritten by a wizard. That would F-bomb most users off, considering their thoughts will be demolished.

Although, I have proposed/supported a save user comments feature. Discussion of features will have to be visualized/explained before it would ever be implemented. A simple Idea, But diverse in usage.
Open your mind. I can't format this the way I would like, be imagine a programmmers whatever.

So Think... Then think some more. Etc....

Never be afraid to sit awhile and think.
If you get tired of waiting, sit some more.
If you sit you might as well think.
If you think too much you might come up with solutions(errors)

Else you may have ignored the answer...
Or even maybe misunderstood it.
Or understood it completely.

Metallicow

» Wed Mar 30, 2011 10:16 am

Not sure if this is really entirely wizard related or BAIN in general. But....

Any chance of being able to edit the comments field for an installer to use for short instructions? It's been asked for before but I figured I may as well ask again while attention is focused in this general direction

Also, I have askeded before that there should be a simple way to save user comments. In my opinion they should not be overwritten by a wizard. That would F-bomb most users off, considering their thoughts will be demolished.

Although, I have proposed/supported a save user comments feature. Discussion of features will have to be visualized/explained before it would ever be implemented. A simple Idea, But diverse in usage.

You're right it is more of a BAIN feature, but no reason not to bring it up really. Like Metallicow said, it's been brought up before in various iterations of what to actually use the Comments window for. It's something that will have to be thought on for a while, maybe we need to change up the UI to add an area for modder's instructions or something.

I'm hesitant to do too much in the BAIN UI area though, since myk002 is working on a great improvement there with some asynch-io that should make the BAIN page way more responsive and user friendly.

» Wed Mar 30, 2011 7:56 am

Re SDP Editing: You can write a wrapper around the ShaderDisasm.dll library the comes bundled with OBMM - If I recall correctly, it has the stuffing to inject new shader records.

» Wed Mar 30, 2011 2:41 pm

Re SDP Editing: You can write a wrapper around the ShaderDisasm.dll library the comes bundled with OBMM - If I recall correctly, it has the stuffing to inject new shader records.

Not too usefull there. The dll exports almost no usefull functions...however I did homebrew my own based on the source code, so all good.