Sorry for the slow progress and the lack of updates. The introduction of localizations is making things more complicated than anticipated. Right now, I'm trying to figure out how to make the software capable of accessing all the files for new and older IE games respectively in a flexible (soft-coded) way. Considering that BG2:EE is on the way and that there might be any number of official and inofficial IE games (e.g. GemRB projects) in the future, this seems like the only sensible approach. What this means is that the way in which the software gains access to game resources (where to look for which files in what order) will be completely configurable. The plan is to have presets for all the official IE games (BG, IWD, PS:T, etc...), while providing the ability to setup new configurations for currently unknown titles.
OK, I have implemented a very simple markup language for encoding and decoding game environments. An environment defines which directories are part of the game and which files within those directories to look out for.
specifically this is defined: Langages: ... 0 - English ... 1 - German ... and the default language as English ([code]0[/code]), which means that files not found in localized directories will be searched for in directories that belong to the default language. This seems to mirror BG:EE's behaviour.
GAME: ... is not visible to the user ([hide]true[/hide]) ... can be searched by CHITIN.KEY for BIF files([root]true[/root]) ... is independent of the language ([code]-1[/code]) ... is not an override ([prior]-1[/prior]) ... has the subdirectories "lang" and "music"
lang: ... is visible to the user ([hide]false[/hide]) ... cannot be searched by CHITIN.KEY for BIF files([root]false[/root]) ... is independent of the language ([code]-1[/code]) ... is not an override ([prior]-1[/prior]) ... has the subdirectory "en_US"
en_US: ... is visible to the user ([hide]false[/hide]) ... can be searched by CHITIN.KEY for BIF files([root]true[/root]) ... is localized as English ([code]0[/code]) ... is not an override ([prior]-1[/prior]) ... has the subdirectory "Sounds" ... has the files "dialog.tlk" & "dialogf.tlk"
Sounds ... is visible to the user ([hide]false[/hide]) ... cannot be searched by CHITIN.KEY for BIF files([root]false[/root]) ... is localized as English ([code]0[/code]) ... is an override directory with priority 5 ([prior]5[/prior]) ... only "wav" files will remain in this override, all others will be displayed elsewhere ([s:keepext][]wav[/][/s:keepext])
music ... is visible to the user ([hide]false[/hide]) ... cannot be searched by CHITIN.KEY for BIF files([root]false[/root]) ... is independent of the language ([code]-1[/code]) ... is not an override ([prior]-1[/prior]) ... contains "mus" files ([s:ext][]mus[/][/s:ext]) ... contains sub-directories which contain "acm" files ([s:subext][]acm[/][/s:subext])
USER ... is not visible to the user ([hide]true[/hide]) ... cannot be searched by CHITIN.KEY for BIF files([root]false[/root]) ... is independent of the language ([code]-1[/code]) ... is not an override ([prior]-1[/prior]) ... has the subdirectory "save"
save ... is visible to the user ([hide]false[/hide]) ... cannot be searched by CHITIN.KEY for BIF files([root]false[/root]) ... is independent of the language ([code]-1[/code]) ... is not an override ([prior]-1[/prior]) ... contains sub-directories which contain any these files: BALDUR.BMP, BALDUR.GAM, BALDUR.SAV, etc...
I will of course include an editor for these environments.
The point is that this makes it possible to have different rules for different games.
EDIT: [ is actually < and ] is actually >, but the forum software won't display them.
I hope this tool will be out in the near future. I'm so looking forward to making a few changes to BG. Btw will there be an option to add things like damage resistances to armor? I always found it weird in D&D that instead of damage reduction you get such strange damage avoidance to damage stat.
@salomonkane I'm not sure what exactly you mean with "inter & -retro-compatible", but I can guess. To a very significant degree compatibility will depend on WeiDU. The basic idea for this tool (now that I've had time to think more carefully about this stuff), is that there will be TWO ways of interaction with source material using this tool: 1.) Direct editing You take one or more files, edit them to your liking and be done with it. This approach is not something that I would call modding, because the result is not a mod (ie. the result would only be guaranteed to work for YOU). For personal use, this is perfectly fine. 2.) Projects Anything other than directly overwriting existing files should be done in a project. You import files from the source material to a project. Any operation performed on those files will be logged by the tool. At any point, installable WeiDU code can be assembled from that project and will be applicable by everyone. That's the basic idea, anyway.
Therefore, the maximum in compatibility will ALWAYS depend on what WeiDU is capable of. I hopefully can, and probably will, write certain macros for WeiDU to make sure it does stuff my way*, but if e.g. WeiDU can't find certain files, there's nothing I can do about it. As for "intercompatible", that depends on what you mean by that.
@LordSoverign I don't even wanna guess as to how long it'll take to get anything functional published. Sorry.
* E.g.: WeiDU's 2da editing capabilities are arse-backwards, AFAICT. Instead of editing rows and lines by ID/name WeiDU only provides functions for editing it by index. Which is a horrible way of editing text-based files, because you can never be sure that any given index corresponds with a specific value. Even worse, the fact that indexing exists suggests that the 2da table is being parsed value by value, so why limit functionality to such a primitive and ultimately unreliable feature? /soapbox
Sorry if this bothers you, but, Could you, please, clarify some aspects of your Project :
a) Concept and the name of the editor ? b) Transversal functions and specific tasks ? c) Limitations of the tool ? d) Requirements (software/harware, and human) ? d) For which public : players, modders ? e) Use : for what kinds of mods ? f) Compatibility with other existing tools, platform compatibility (original BG edition, EE, Infinity Engine Games) ? g) Ergonomics : in Command Line, WeiDu, with UI, in WYSIWYG, User-Friendly ? h) Multilanguage ?
@salomonkane, this project is basically in its beginning stages. Give @klatu a break. He's not going to know the answers to many of these questions yet.
To answer your questions generally, it looks like this will be a tool in line with Near Infinity. If you think about it that way I think most of your questions will t a basic level be answered.
Creating a Modding Tool purpose, needs and goals Near Infinity vs KlatuTool,
@Kaeloree do not be so omnipotent ^^, so let everyone to appreciate the questions and give the replies appropriate, however thank you for the explanation and the link to NI : ). This allows me to raise the question about the differences provided about the current project : So @klatu, What common points and differences with NI ?, Thank You .
@salomonkane Don't sweat it, I'm not bothered. But @Keloree is correct, this is still mostly conceptual.
But I'll try to answer your questions anyway: a) Concept and the name of the editor ? b) Transversal functions and specific tasks ? It's supposed to become a fully functional, extendable, IE modding suite. That means you get access and editing capabilities for IE file formats on several levels. There will be editors for different tasks: editing specific bytes of files, patching files with custom WeiDU code or otherwise definable rules, editing files on a more abstract level (like NearInfinity), even wizards for creating new files or setting up common tasks. I chose Netbeans for this because it (almost) enforces a modular design pattern. So once I feel confident that the core of the project is stable I will most likely make it public on a code repository like Github, so that other people can provide their own modules and funcionality to the tool. As I alluded to earlier, the main goal is for this tool to become a one stop shop for general modding purposes. So instead of a dozen tools that all do different things, like area editing, bam editing, dialogue creation, you only need one single application that logically assembles all your files into a single mod that can be distributed to other people without ever having to touch a single line of code. As for "Transversal functions ", all I can say is that English is not my primary language and I have no idea what you mean by that term. Until I, or someone else, comes up with something spiffy I'll call it whatever the hell I want. c) Limitations of the tool ? That depends, as I said earlier, on WeiDU itself. If possible I will try to supply my own macros for extending WeiDU functionality when necessary, but the concept is the same: Either add, replace or patch files. How precise the editing will be kind of depends on the modder and the kind of files s/he is working on. Some file formats lend themselves to a more high-level approach (like any kind of image format), while other formats are best dealt with on a (quasi-)source level (scripts, IDS, etc...). d) Requirements (software/harware, and human) ? Java SE JRE 1.7 (the latest atm), system requirements as per NetBeans, at least two fingers, maybe an eye? d) For which public : players, modders ? Yes. e) Use : for what kinds of mods ? Erm, that really depends on the modder. I will not enforce any kind of limitations as to the content of the mods (even if I think they stink). The rest depends on what the software will be capable of in the end. f) Compatibility with other existing tools, platform compatibility (original BG edition, EE, Infinity Engine Games) ? This is why WeiDU will be an integral part of the tool. Again, compatibility largely depends on WeiDU. If WeiDU lacks some crucial functionality, I will contact the current maintainers for support. g) Ergonomics : in Command Line, WeiDu, with UI, in WYSIWYG, User-Friendly ? There will most likely not be a command line, because that would simply be WeiDU anyway. The primary impulse that drove me to start this project was that the main tool for writing mods IS command-line. It's powerful when it comes to general patching while preserving mod-compatibility. But WeiDU in and of itself doesn't let you make mods. You first have to learn an increasingly complex programming language and you need to be rather intimately familiar with the IE file formats you're working with (e.g. writing dialogues for any IE game right now is a pain the ass, because WeiDU does not provide any kind of abstraction or visual input for the dialogues you're working on). Which leads to the sad fact that only the technically adept will ever write mods at all, while many great mods will forever remain in development purgatory because their authors have no time or energy to learn WeiDU and its intricacies. As a few people in this very thread have alluded to, other games have very easy to use editors, like NWN. They still require some expertise, but in general these editors are very accessible and allow for creation of conent on a much larger scale than what is typical for BG mods, e.g.
What common points and differences with NI ? Well, not that many commonalities, really. Some functionality will be almost the same (direct editing), but I've yet to see a mod that is written purely in NI.
TLDR: This will be a visual editor for IE games, with the option to generate WeiDU mods, w/o having to know WeiDU.
Disclaimer: The above is pure conjecture. None of it is a reality yet. I plan to make it so, but I can always fail. At least there is certainty in that.
First of all I have to say that I'm really impress. Your screenshots are amazing and I'm looking forward to this tool.
Are you planning to release it as portable software like NearInfinity ?
For "portable" I mean a program that does not write anything in the Windows register and doesn't put files outside of the main program folder (unless exported by the user, e.g. in "override" etc.)
@Erg I'm not sure. NetBeans makes this rather difficult. It provides the option to distribute installers for Windows, Linux, Max OS X and Solaris. Perhaps I will find a way to make it truly portable in the future, but atm I don't know if it's even possible.
This is something that will only become relevent when the project is near release anyway, so I'm not gonna worry about it now.
No Problem. It would be great if you could release it also as portable software (I'm just very fond of them), but I really appreciate what you are doing and I will definitely use your tool anyway.
I understand how easy it is to get derailed on a project, but just to encourage you, some of us out here remember and are still hoping it will come to pass.
1. Is this project open source? 2. If so, is it on GitHub or Google Code? 3. What's preventing the program from being portable? Isn't it written in Java with Swing? 4. Will it include scripting possibilities, for automation of modding tasks?
Point is, I miscalculated. Real-life makes demands of me that I can't meet without sacrificing projects like these. Maybe I'll come back to this project at some point, but right now (and for the past year, really), no such sacrifice is/was possible.
This project isn't dead, just yet. But it's on hold, as you may have guessed...
Maybe I'll come back to this project at some point (I hope I do), but until then, maybe I can tide you over with a little mod of mine that, personally, I can't do without: (see attachment)
Comments
Right now, I'm trying to figure out how to make the software capable of accessing all the files for new and older IE games respectively in a flexible (soft-coded) way. Considering that BG2:EE is on the way and that there might be any number of official and inofficial IE games (e.g. GemRB projects) in the future, this seems like the only sensible approach.
What this means is that the way in which the software gains access to game resources (where to look for which files in what order) will be completely configurable. The plan is to have presets for all the official IE games (BG, IWD, PS:T, etc...), while providing the ability to setup new configurations for currently unknown titles.
Happy holidays, everyone!
An environment defines which directories are part of the game and which files within those directories to look out for.
An example: this would describe the following directories: specifically this is defined:
Langages:
... 0 - English
... 1 - German
... and the default language as English ([code]0[/code]), which means that files not found in localized directories will be searched for in directories that belong to the default language. This seems to mirror BG:EE's behaviour.
GAME:
... is not visible to the user ([hide]true[/hide])
... can be searched by CHITIN.KEY for BIF files([root]true[/root])
... is independent of the language ([code]-1[/code])
... is not an override ([prior]-1[/prior])
... has the subdirectories "lang" and "music"
lang:
... is visible to the user ([hide]false[/hide])
... cannot be searched by CHITIN.KEY for BIF files([root]false[/root])
... is independent of the language ([code]-1[/code])
... is not an override ([prior]-1[/prior])
... has the subdirectory "en_US"
en_US:
... is visible to the user ([hide]false[/hide])
... can be searched by CHITIN.KEY for BIF files([root]true[/root])
... is localized as English ([code]0[/code])
... is not an override ([prior]-1[/prior])
... has the subdirectory "Sounds"
... has the files "dialog.tlk" & "dialogf.tlk"
Sounds
... is visible to the user ([hide]false[/hide])
... cannot be searched by CHITIN.KEY for BIF files([root]false[/root])
... is localized as English ([code]0[/code])
... is an override directory with priority 5 ([prior]5[/prior])
... only "wav" files will remain in this override, all others will be displayed elsewhere ([s:keepext][]wav[/][/s:keepext])
music
... is visible to the user ([hide]false[/hide])
... cannot be searched by CHITIN.KEY for BIF files([root]false[/root])
... is independent of the language ([code]-1[/code])
... is not an override ([prior]-1[/prior])
... contains "mus" files ([s:ext][]mus[/][/s:ext])
... contains sub-directories which contain "acm" files ([s:subext][]acm[/][/s:subext])
USER
... is not visible to the user ([hide]true[/hide])
... cannot be searched by CHITIN.KEY for BIF files([root]false[/root])
... is independent of the language ([code]-1[/code])
... is not an override ([prior]-1[/prior])
... has the subdirectory "save"
save
... is visible to the user ([hide]false[/hide])
... cannot be searched by CHITIN.KEY for BIF files([root]false[/root])
... is independent of the language ([code]-1[/code])
... is not an override ([prior]-1[/prior])
... contains sub-directories which contain any these files: BALDUR.BMP, BALDUR.GAM, BALDUR.SAV, etc...
I will of course include an editor for these environments.
The point is that this makes it possible to have different rules for different games.
EDIT: [ is actually < and ] is actually >, but the forum software won't display them.
Cheers!
Creating a Modding Tool
a) Inter & Retro Compatiblity, BG.EE vs BG Vanilla, vs Infinity Engine Games Series
Hi @klatu,
This tool will be -inter & -retro-compatible with BG Vanilla/BGT/I.E. Games Series, Isn't it ?
b) BAM Editor, BAM files (Alpha-Blending), BAM Workshop (I,II)
"I promise to take a look at BAM Workshop(s). We'll see what I can do."
That would be Great ! : )
T.Y. .
Source :
Possible creation of a toolset for the Enhanced Infinity engine?
http://forum.baldursgate.com/discussion/3472/possible-creation-of-a-toolset-for-the-enhanced-infinity-engine/p1
Flipbook animation transparency
http://forum.baldursgate.com/discussion/comment/12068/#Comment_12068
Creature Bam Files
http://forum.baldursgate.com/discussion/11651/creature-bam-files#latest
I'm not sure what exactly you mean with "inter & -retro-compatible", but I can guess.
To a very significant degree compatibility will depend on WeiDU. The basic idea for this tool (now that I've had time to think more carefully about this stuff), is that there will be TWO ways of interaction with source material using this tool:
1.) Direct editing
You take one or more files, edit them to your liking and be done with it. This approach is not something that I would call modding, because the result is not a mod (ie. the result would only be guaranteed to work for YOU). For personal use, this is perfectly fine.
2.) Projects
Anything other than directly overwriting existing files should be done in a project. You import files from the source material to a project. Any operation performed on those files will be logged by the tool. At any point, installable WeiDU code can be assembled from that project and will be applicable by everyone.
That's the basic idea, anyway.
Therefore, the maximum in compatibility will ALWAYS depend on what WeiDU is capable of. I hopefully can, and probably will, write certain macros for WeiDU to make sure it does stuff my way*, but if e.g. WeiDU can't find certain files, there's nothing I can do about it.
As for "intercompatible", that depends on what you mean by that.
@LordSoverign
I don't even wanna guess as to how long it'll take to get anything functional published. Sorry.
* E.g.: WeiDU's 2da editing capabilities are arse-backwards, AFAICT. Instead of editing rows and lines by ID/name WeiDU only provides functions for editing it by index. Which is a horrible way of editing text-based files, because you can never be sure that any given index corresponds with a specific value. Even worse, the fact that indexing exists suggests that the 2da table is being parsed value by value, so why limit functionality to such a primitive and ultimately unreliable feature? /soapbox
By the way. Your work is much appreciated and I am looking forward to it!
purpose, needs and goals
@klatu,
Sorry if this bothers you, but,
Could you, please, clarify some aspects of your Project :
a) Concept and the name of the editor ?
b) Transversal functions and specific tasks ?
c) Limitations of the tool ?
d) Requirements (software/harware, and human) ?
d) For which public : players, modders ?
e) Use : for what kinds of mods ?
f) Compatibility with other existing tools, platform compatibility (original BG edition, EE, Infinity Engine Games) ?
g) Ergonomics : in Command Line, WeiDu, with UI, in WYSIWYG, User-Friendly ?
h) Multilanguage ?
T.Y. .
Bonus ; ) :
Implementation, Resources , Procedure, Deadline, Modality of Evaluation, Criteria Validation .
To answer your questions generally, it looks like this will be a tool in line with Near Infinity. If you think about it that way I think most of your questions will t a basic level be answered.
@klatu, following with interest.
purpose, needs and goals
Near Infinity vs KlatuTool,
@Kaeloree do not be so omnipotent ^^, so let everyone to appreciate the questions and give the replies appropriate, however thank you for the explanation and the link to NI : ).
This allows me to raise the question about the differences provided about the current project :
So @klatu,
What common points and differences with NI ?, Thank You .
Source :
Near Infinity :
http://forums.pocketplane.net/index.php?PHPSESSID=702729ff9b1887c9384a9bd07d2b6628&topic=28162.0
Don't sweat it, I'm not bothered.
But @Keloree is correct, this is still mostly conceptual.
But I'll try to answer your questions anyway:
a) Concept and the name of the editor ?
b) Transversal functions and specific tasks ?
It's supposed to become a fully functional, extendable, IE modding suite. That means you get access and editing capabilities for IE file formats on several levels. There will be editors for different tasks: editing specific bytes of files, patching files with custom WeiDU code or otherwise definable rules, editing files on a more abstract level (like NearInfinity), even wizards for creating new files or setting up common tasks.
I chose Netbeans for this because it (almost) enforces a modular design pattern. So once I feel confident that the core of the project is stable I will most likely make it public on a code repository like Github, so that other people can provide their own modules and funcionality to the tool.
As I alluded to earlier, the main goal is for this tool to become a one stop shop for general modding purposes. So instead of a dozen tools that all do different things, like area editing, bam editing, dialogue creation, you only need one single application that logically assembles all your files into a single mod that can be distributed to other people without ever having to touch a single line of code.
As for "Transversal functions ", all I can say is that English is not my primary language and I have no idea what you mean by that term.
Until I, or someone else, comes up with something spiffy I'll call it whatever the hell I want.
c) Limitations of the tool ?
That depends, as I said earlier, on WeiDU itself. If possible I will try to supply my own macros for extending WeiDU functionality when necessary, but the concept is the same: Either add, replace or patch files. How precise the editing will be kind of depends on the modder and the kind of files s/he is working on. Some file formats lend themselves to a more high-level approach (like any kind of image format), while other formats are best dealt with on a (quasi-)source level (scripts, IDS, etc...).
d) Requirements (software/harware, and human) ?
Java SE JRE 1.7 (the latest atm), system requirements as per NetBeans, at least two fingers, maybe an eye?
d) For which public : players, modders ?
Yes.
e) Use : for what kinds of mods ?
Erm, that really depends on the modder. I will not enforce any kind of limitations as to the content of the mods (even if I think they stink).
The rest depends on what the software will be capable of in the end.
f) Compatibility with other existing tools, platform compatibility (original BG edition, EE, Infinity Engine Games) ?
This is why WeiDU will be an integral part of the tool. Again, compatibility largely depends on WeiDU. If WeiDU lacks some crucial functionality, I will contact the current maintainers for support.
g) Ergonomics : in Command Line, WeiDu, with UI, in WYSIWYG, User-Friendly ?
There will most likely not be a command line, because that would simply be WeiDU anyway. The primary impulse that drove me to start this project was that the main tool for writing mods IS command-line. It's powerful when it comes to general patching while preserving mod-compatibility. But WeiDU in and of itself doesn't let you make mods. You first have to learn an increasingly complex programming language and you need to be rather intimately familiar with the IE file formats you're working with (e.g. writing dialogues for any IE game right now is a pain the ass, because WeiDU does not provide any kind of abstraction or visual input for the dialogues you're working on). Which leads to the sad fact that only the technically adept will ever write mods at all, while many great mods will forever remain in development purgatory because their authors have no time or energy to learn WeiDU and its intricacies.
As a few people in this very thread have alluded to, other games have very easy to use editors, like NWN. They still require some expertise, but in general these editors are very accessible and allow for creation of conent on a much larger scale than what is typical for BG mods, e.g.
What common points and differences with NI ?
Well, not that many commonalities, really. Some functionality will be almost the same (direct editing), but I've yet to see a mod that is written purely in NI.
Bonus ; ) :
Implementation, Resources , Procedure, Deadline, Modality of Evaluation, Criteria Validation .
Uuhhhm...
TLDR:
This will be a visual editor for IE games, with the option to generate WeiDU mods, w/o having to know WeiDU.
Disclaimer: The above is pure conjecture. None of it is a reality yet. I plan to make it so, but I can always fail. At least there is certainty in that.
First of all I have to say that I'm really impress. Your screenshots are amazing and I'm looking forward to this tool.
Are you planning to release it as portable software like NearInfinity ?
For "portable" I mean a program that does not write anything in the Windows register and doesn't put files outside of the main program folder (unless exported by the user, e.g. in "override" etc.)
I'm not sure. NetBeans makes this rather difficult. It provides the option to distribute installers for Windows, Linux, Max OS X and Solaris.
Perhaps I will find a way to make it truly portable in the future, but atm I don't know if it's even possible.
This is something that will only become relevent when the project is near release anyway, so I'm not gonna worry about it now.
Sorry.
No Problem. It would be great if you could release it also as portable software (I'm just very fond of them), but I really appreciate what you are doing and I will definitely use your tool anyway.
*sigh*
Um... I'm curious if this tool will be released?
It was pretty quite here recently.
1. Is this project open source?
2. If so, is it on GitHub or Google Code?
3. What's preventing the program from being portable? Isn't it written in Java with Swing?
4. Will it include scripting possibilities, for automation of modding tasks?
It's been a while...
Point is, I miscalculated. Real-life makes demands of me that I can't meet without sacrificing projects like these.
Maybe I'll come back to this project at some point, but right now (and for the past year, really), no such sacrifice is/was possible.
This project isn't dead, just yet. But it's on hold, as you may have guessed...
Maybe I'll come back to this project at some point (I hope I do), but until then, maybe I can tide you over with a little mod of mine that, personally, I can't do without: (see attachment)