To the Modders :-)
Bhryaen
Member Posts: 2,874
I'm creating this thread as an entreaty to modders... folks like @Ascension64, @aVENGER, @devSin, @CamDawg, @demivrgvs, @erephine, @GrimSqueaker, @Balquo, @Galactygon, @Wisp... and to Miloch if you come by as well!
If nothing comes of this, so be it, but I'm creating it anyway as an entreaty because I feel it's a discussion for which there's a present imperative but scant few outlets at present (unless there's something already going on behind-the-scenes I don't know about, in which case... yea!). But since at present I've no idea what the devs have in mind for you guys, and you're a very talented lot of folks who sort of know your way around BG- so I've heard, anyway. And, seeing you all coming to this one forum and offering your services to the devs, I can't help but wonder how your talents could be applied to BGEE in the next few months before its release to make the most of this rather BG-historic moment.
Thus I'm just wondering what- if you could do anything to affect the development of BGEE, if you were allowed to have a go at the source code itself to provide for a new BG, if you could put all your yrs of experience with BG into play right now on BGEE for a lasting basis, if you could apply the skills you already have into forming the end result of BGEE... what would you do? And not only you as individuals, but you as a coordinated team.
Really I'm wondering what you could do with such an opportunity- whatever the full extent of that opportunity might ultimately ever be- but I'm at a loss as to what to make of that opportunity myself, and it seems to me- as a simple, dreamy-eyed BG-fan- to be an unmitigated missed opportunity to not engage you all as an outright assistance team if you're willing, particularly given how much help you could be. Frankly I just wish you all could take up some of the busywork from the devs so they can go a-scriptin' lots of new features and content, but that's just me. :-P And since I'm daring to just wonder aloud, I'm more asking what would you do- specifically even- i.e., rather than could, since, well, that's not certain yet? And, of course, I'm deviously counting on the devs noticing what you would/could do in the hopes that the devs might just go ahead and let you do it! >:-)
If nothing comes of this, so be it, but I'm creating it anyway as an entreaty because I feel it's a discussion for which there's a present imperative but scant few outlets at present (unless there's something already going on behind-the-scenes I don't know about, in which case... yea!). But since at present I've no idea what the devs have in mind for you guys, and you're a very talented lot of folks who sort of know your way around BG- so I've heard, anyway. And, seeing you all coming to this one forum and offering your services to the devs, I can't help but wonder how your talents could be applied to BGEE in the next few months before its release to make the most of this rather BG-historic moment.
Thus I'm just wondering what- if you could do anything to affect the development of BGEE, if you were allowed to have a go at the source code itself to provide for a new BG, if you could put all your yrs of experience with BG into play right now on BGEE for a lasting basis, if you could apply the skills you already have into forming the end result of BGEE... what would you do? And not only you as individuals, but you as a coordinated team.
Really I'm wondering what you could do with such an opportunity- whatever the full extent of that opportunity might ultimately ever be- but I'm at a loss as to what to make of that opportunity myself, and it seems to me- as a simple, dreamy-eyed BG-fan- to be an unmitigated missed opportunity to not engage you all as an outright assistance team if you're willing, particularly given how much help you could be. Frankly I just wish you all could take up some of the busywork from the devs so they can go a-scriptin' lots of new features and content, but that's just me. :-P And since I'm daring to just wonder aloud, I'm more asking what would you do- specifically even- i.e., rather than could, since, well, that's not certain yet? And, of course, I'm deviously counting on the devs noticing what you would/could do in the hopes that the devs might just go ahead and let you do it! >:-)
Post edited by Bhryaen on
5
Comments
Watch out for that typo in @erephine's nickname ;-)
For example: If file headers are being changed, we need to know that and the specifics of the changes. Any file format changes need to be communicated or nothing can be made to work with a new engine. Anyway, end of my two-cents until more information is made available.
developers are currently working with fixpackers to integrate bug fixes with their consent (see the Bugs section of the forum). They are also supposedly in touch with Erephine to integrate 1PP into BG:EE if legal issues can be solved to an extent that is satisfactory for both parties. I'm sure the devs will gladly cooperate with modders as soon as time allows (they're currently quite busy with bug fixing) :-)
Actually @AndreaColombo is right (and thanks for the spelling correction, Andrea!) that the devs are rather steeped in work with the modders who have come forward on the bugfix front, as can be seen in the "Bugs" forum. I definitely didn't intend this thread to gripe about the devs- or the modders for that matter. Both can't help but be more or less heroes to me at this point... The intention was simply to invite modders to sort of make a wish list- not just of things they'd like the devs to do, but of things they'd do to BGEE if they could in order to, say, making modding easier, make the source code flow right, that sort of thing. It's not as if there isn't enough on the plate already, but, well, I just wanted to lay some groundwork for a more substantial contribution by modders if it's even possible.
I was partly inspired by this post by @Demivrgvs on the thread "Keep BGEE as vanilla as possible" that sounded like modders might just have some extraspecialitious ideas on modder needs that even the devs can't fully anticipate or appreciate. It just seemed like a great foray into the possible directional structuring of BGEE to modder interests that can't help but be facilitated by modders themselves either making it fairly explicit what would do the trick or doing that trick themselves. This said, I'm a bit apprehensive about the "don't 'waste' your time on things we can easily do or have already done" since it's not guaranteed ahead of time that modders even will do so- even if they can- (I mean, it's not really a civic responsibility after all), and really, why should they have to, say, bugfix or provide new PC animations or add new game features when they can be made integral to BGEE itself? I'd rather instead that the devs don't "waste" their time doing things that modders might even be happy to do to BGEE instead, and most importantly... thereby tailored exactly to modders' needs and liking... :-)
Almost all of what I would want has already been amply addressed in the bug forum. Primarily, I'd love to see the engine bugs we couldn't touch in Fixpack (or in ToBEx) get addressed. Secondarily, if we break out some of the hardcoded areas of the engine into moddable 2da/ids files (subraces, more kits? Yes, please), even better. If that means we break some mods it's well worth it.
On the other hand, I'd ignore the majority of threads in the feature request forum. I think some improvements are necessary--improved graphics, higher native resolutions, UI changes--but I'm very dubious about trying to include AI improvements, unfinished quests, new content, etc. It's not very sexy to have an Enhanced Edition where most of the enhancements are under the hood but I think the downside potential of changing the core BG experience too much is not really worth it.
Anyone who knows me will recognize this as the unapologetic, conservative view of someone who a) had to referee a lot of modders under the Fixpack umbrella and b) communicate (and occasionally defend) those fixes to an equally diverse group of players. From what I've seen of the BGEE devs so far, it seems like the approach is roughly similar.
Yes, my main concern is making sure that mods can plug in just as easily to the core platform as they do with the original work. If there are engine changes (which is likely), then modders should be informed if modding is truly to be taken into consideration. And remember that this is BG1 first. Most of the conversation I see concerns BG2 changes or fixes which will be later. It would be nice to take into consideration animation slots, but that is for BG2EE.
I am an old modder and have seen people take credit for things they did not fully do themselves. Modders WILL mod this! How easy a time they have depends on the information given by the developers. New tools will, no doubt, need to be written. The days of TeamBG are long gone and all that programmer energy along with it. New joinable NPC's are a dime a dozen because they are easy to do. Not sure where I am going with this, so will stop and end with a short list of 'wants'.
1. Insert code into the exe for all of the IWD format animations so modders can easily make use of them. That information can be found in the ANISND.ids from BG2. They are the 'M' series animation slots. While at it, insert code to handle writing directly to add more slots. When BG2 is done, the reverse should be true. Add all the missing animation slots that existed in BG1 (I am looking at you, Basilisk). Anyone with a Hex editor can look at the exe and find out what to name their 'new' animations and make use of them.
2. More on animations: Insert the code to accept the un-modified creature animations straight from Planescape:Torment. It should also be covered under whatever DnD/License agreement was accepted to modify and enhance BG1. I spent 4 years converting them all to the 'm' IWD format, but a straight insertion would be preferable. Might as well have all animations available for both BG1 and BG2 in both enhanced versions.
3. Character animations: No need to actually incorporate new character races as some posters have suggested. Just put the code into the exe to handle them. How they are designated can be up to the modders. You have the freedom to add as many slots as you want... so add 20! Simple incremental numbering can suffice as their designations can be determined by the modders. Modders DO manage themselves and prefixes can be reserved to prevent incompatibility for quest mods.
4. Incorporate Detectable Spells in both BGEE and BG2EE which was developed at IEEAIS by Kensai Ryu and the gang.
5. Implement the Xyx-manuever into the enemy AI. Ask Dave Gaider if you dont know what that does. Contact me if you need that stuff or want clarification. Also put in the AI for Xyx's Smart Beholders when you get to BG2EE.
6. Get rid of the green water background in BG1. It serves no purpose if you change the overlay color to that of BG2 and only serves to annoy modders.
7. Keep the chitin.key readable by InfExp and Near Infinity (and DLTCEP too).
8. Do NOT change the area bitmap format as there are no other tools to build new areas reliably besides IETME and DLTCEP. Changing that format would require someone to alter Theo's program, and I am not sure he can even be contacted for the source code. That would require a new program to be written delaying modding. Or... give us a full area editor!
9. More scripting functions... but alas, I cant remember exactly what was missing that I really wanted to have available at this time. I'm sure it will come to me. I am mostly retired from modding bg and bg2, but I am not dead yet. You can find my posts at SHS (or anywhere else), but alas I cannot go there any more as my feeble old brain has forgotten the password.
That is all I can think of at the moment. Perhaps someone else has more ideas to add to this list. If a developer wants specific exe hex code information, I will happily get that information for them but wont post it in a forum.
I, too, would be extremely happy to see as many engine bugs as possible fixed. However, for the devs to able to fix them, they should first be aware of them. The best case scenario, as you probably already know, would be to have a list of all engine bugs we want to see fixed in the "current behavior / expected behavior" format. Is this something you and your fellow fixpackers could do (I gladly volunteer for any monkey work this could imply, if needed)? I'm asking because, IIRC, someone said you didn't keep track of engine bugs when employing resource hacks to circumvent them.
@Cuv
Keep in mind BG:EE will be using the ToB engine. Therefore, while several requests in the Features forum may look like they belong to BG2:EE, they are actually fitting for BG:EE. That being said, I agree with you and Cam that most of those requests are out of place and/or better left to modders.
As for your desiderata, I believe the best way for you to see #4, #5, #6 and #7 implemented is to post a Feature request (or a Bugfix request, as you see fit) clearly stating the CURRENT BEHAVIOR and the DESIRED BEHAVIOR. Make sure you make your request as obvious as possible, so that there are no two ways about its interpretation. This would make it considerably more likely for them to be implemented than just posting them here.
As for adding more animations slots, you may want to check out this request I have made on Miloch's part.
Last but not least, as the source art assets were lost, I think it is very likely that the bitmap format will be kept for background art :-)
@AndreaColombo
Are you the unofficial go-between between the dev team and the community? I see you everywhere:)
I might have acted as such on a few occasions
Sorry, guys. I've read enough cryptic dev/producer tweets and announcements over the years to convince me that nothing can really be taken as a guarantee until release day.
Re-coding is tedious monkey work, but would it be necessarily bad if it implied a passage to cleaner, leaner and more efficient coding standards?
If weidu is able to parse and work with BG[1,2]:EE, and it is a matter of a state or two being moved, there may not be any real hassle. If the dialog states are rebuilt and reordered from the ground up, or weidu is unable to be adapted to match a new format is to be used, there could be some serious difficulties with adapting. An entirely new adventure-tool would be awesome; it could open up the game for lots of new folks. Porting existing mods, though, would be made much easier by making sure some of the original structure is left intact.
That isn't a problem, really, for BG:EE - the old games are still around, so folks could have a mod install of the old materials and a new install of the newly re-built games. The Jagged Alliance community and Mount & Blade community are examples of that. But BG:EE could seriously expand its appeal by making sure there is a way to allow the dialog-heavy mods to have a relatively painless process moving existing content into the new engine.
[Question] For the more "technically minded" folks, this is a direct question to the developers/coders currently working on the project, as it does have an impact on the folks still developing mods for the older games (myself included). The challenge with a rebuild of dialog has two technical points: dialog state ordering and accessible dialog tools.
[Expansion]
Right now, modders have WeiDU to work with, and the dialog structure that BG/BG2/BG2:ToB .dlg files shipped with. If a number of mods that expect that dialog state 104 in file BMINSC.DLG to be about x, and suddenly it is state Y, then the teething pains adapting mods to BG[1,2] become strong. Not insurmountable, for anything but the big projects, like BG1NPC, but strong. Many mods create multiple interjections and leverage this dialog structure; string contents change, but the state orders do not.
{to make sure everyone is on the same page, I am not talking about strings:
string #5050572 = ~Hi there. I am a text reference spoken by Minsc. Boo is busy right now.~ [SOUNDREF]
I am talking about states:
[code]
IF WEIGHT #7 /* Triggers after states #: 6 7 13 20 21 22 23 even though they appear after this state */
~NumTimesTalkedTo(0)
ReactionGT(LastTalkedToBy,NEUTRAL_UPPER)
!Dead("Dynahe")
~ THEN BEGIN 0 // from:
SAY #476
IF ~~ THEN REPLY #489 GOTO 3
IF ~~ THEN REPLY #490 GOTO 4
IF ~~ THEN REPLY #491 GOTO 2
END
[/code]
In the string example, a rewriting of the string is no big deal - it most likely matches the original intent; mods that rely on that string to find the relevant state will just need to add the new content to be able to find that state and patch in the mod-added dialog. (Assuming weidu can still do the job. If we are in a new toolset, then we are back to rebuilding things by hand.)
In the Minsc state, it is the ordering of 0, 1, 2, etc. within the file. Current mods operate by referent to that state number, adding, changing, or manipulating the surrounding parameters and possible transitions. Repairing the malformed "Dynahe" is no big deal - changing the content of the strings to something similar is no big deal - even adding additional replies is no big deal. But changing the order of the replies is a big deal, or reordering the states directly instead of manipulation by weights, so that state 0 is now actually
[code]
IF WEIGHT #7 /* Triggers after states #: 6 7 13 20 21 22 23 even though they appear after this state */
~NumTimesTalkedToGT(0)
~ THEN BEGIN 0 // from:
SAY #2795
IF ~~ THEN EXIT
END
[/code]
it becomes less a question of porting a mod and more a question of building from scratch.
}
If dialog structure is pretty much retained, and new quest/NPC entries are added to BG:EE in similar ways to current usage, then the states that the current mod base utilize as a formal common skeleton will still be there, and as far as NPC and Quest mods (not the technical mods) go the process of adapting should be fine. If not, then we would need a roadmap of the new dialog states and create a way of remapping existing content; that is assuming that the dialog structure is retained in any similar way.
[Clarification]
The whole idea of a rebuilt BG game is exciting. This is not about clinging to old structures and resistance to new coding - this is about making a space for the 10+ years of modding that has added to the game. Specifically, it is about highlighting the primary challenges to an existing i.e. modder looking at moving content into the enhanced version. My hope is that the dialog structure has been retained, and that the developers have taken a look at the types of things that weimer and the bigg at PocketPlane have done to support inter-mod dialog cooperation (something that most new games do not do as well as they have).
/Edit: Sure thing on adding the technical folks, @AndreaColombo, thank you for suggesting that: @CameronTofer @ScottBrooks @KeithS
Therefore modders only really need two things:
1) unchanged existing file formats
2) expanded engine capabilities
With the latter it is not even easy to say exactly what is desired, because, like I've said, even vanilla engine allows much wider possibility for modding than one would expect after the first glance. Supposedly, the best bet is to implement all the requests made in ToBEx's forum on SHS.
I wouldn't even bother to incorporate such seemingly indispensable things as Detectable Spells (unless BGEE explicitly needs it for new AI, of course), because it can be easily added by any modder worth his salt.
Also it would be great to make some work around CHU - for example, now there is fixed paperdoll area for inventory and character generation window in game - modder can't change its size with CHU and need to patch .exe to expand it.
A list of ToBEx fixes is already in the devs's hands for implementation in BG:EE. If there are further fixes, or features, that would be good for modders to have built into the engine for whatever reason (e.g. not having to install ToBEx to get them; not having to resort to tricky or hacky workarounds to achieve something; etc.), they should really be requested either in the "Bugs" or "Feature requests" forums. When making a request, clearly state the CURRENT BEHAVIOR and the EXPECTED/DESIRED BEHAVIOR, and make sure your wording makes it really hard for anyone to misinterpret what you're asking for.
Personally, I would like to see as many modder-friendly features and engine fixes implemented as possible (which includes Detectable Spells, or Ascension64's ToBEx solution to the same problem) . It is true that modders can already achieve almost anything with the right tools, but being able to do so without needing the tools is even better :-) The less things one has to install to achieve a given goal, the better: it makes for a cleaner installation. Also, being able to do something without having to resort to tricky workarounds is awesome if I can say so myself, and I'm no modder. I just genuinely enjoy efficiency and strive for its maximization.
The matter of WotC gaining "rights" over modders' work has stymied me before, but given that modders aren't exactly profiting from their mods anyway- as well as the bald fact that vanilla BG isn't owned by modders either despite their incursions into it- I'm no longer seeing where a conflict arises. Letting WotC "own" a contribution to BGEE seems an invisible formality since it won't stop a single modder from breaking open the code and having at it anyway however and to the furthest extent they can and wish.
Of course, I'm primarily thinking here of the sorts of mods that add tweaks and gameplay options, not, say, the bugfix mods which are presumably already being implemented by the dev team in their own way... Nor the plethora of NPC, quest, and dialogue mods that simply have no salience in such a way, but even in those cases the modders might have a good sense of exactly how they'd implement BGEE code structure to facilitate or even standardize their work and could simply make those fixes themselves. Doing so would help pave the road for themselves as well as other modders, present and future. I say this knowing full well there have already been such ideas hashed about by modders in this thread and elsewhere on the BGEE forums, but I'm wondering- without any say in the matter myself, mind you, but still- whether modders prefer the wait-and-rework approach or the direct-integration-collaboration approach.
Not to put too fine a point on it, but the story/quest/dialog mods have a wide, varied level of polish (meaning a circular dial of dreadful > ok > great > awesome > peerless > downright silly, and that can be within the same mod. We don't have pro editors and publishers to report to, and our senses of humor and appropriateness can be extremely varied). Trying to decide what fits and what doesn't often comes back to personal choice. Additionally, some stuff, like my current NPC, is just not right for a Teen-rating game... and mine is not alone on that.
Modders also work on a very different timeframe than developers. It is a hobby cobbled out of bits of free time. If there is to be a release during 2012 (or 2013 for that matter), modders would need to have started working with the developers (literally) 3 years ago
The tweak/gameplay options rest in a grey area compared to NPC/Quest/Dialog mods, but not by much... judging by the weidu.logs I have seen, lots of people like to use Tweakpack, SpellPack, Full Plate & Packing Steel, etc., but again, setting up a way that would allow content like this to be enabled/disabled could make game setup confusing. This may be an area where modding is the best choice, allowing the design team to concentrate on their own added story elements and engine upgrades.
(This entire post presupposes that the original dialog structures are left intact, and that we have a toolset that can manipulate .are, .cre, .wed, .tis, etc. in a way that lets others do so as well operating collaboratively on the main install, like WeiDU does. If this is not part of the plan, and the only available option is to have the mod content shipped with the game as part of the original content, then the idea becomes... unpleasant. Even the best modded content may need error correction eventually, and a modder has a huge advantage over a developer - no need for cash for the toubleshooter, infinite time, multiple updates/fixes/tweaks/patches, targeted and detailed feedback, etc.)