Jump to content
Sign in to follow this  
Macready

Preempted Tavern Rumors Dialog

Recommended Posts

Hi -

 

Is there a reason you are compiling your own version of the Baldur's Gate tavern rumors dialog (_RBALDU.DLG) and then assigning it to city commoners? In so doing, you are essentially downgrading that file back to unsorted journal status, and I'd rather you didn't.

 

At the very least, please consider compiling your own (non-existing) dialog resource, and then patching that onto commoners. You might also want to think about skipping the journal entries altogether (at least on Tutu -- although I'm pretty sure I read that BGT also uses an organized journal now).

Share this post


Link to post

Lousy timing, my friend - I (literally) just uploaded v15 final, in which I rebuilt the tras to have journal titles... and one of the few I was able to complete was that file :thumbsup:.

 

Crap.

 

 

Give me a minute to reorient myself.

Share this post


Link to post

OK. I can do this:

 

in tp2:

 

COPY_EXISTING ~%tutu_scriptf%twbax_a.cre~ ~override~
			~%tutu_scriptf%twbax_b.cre~ ~override~
			~%tutu_scriptf%twbax_c.cre~ ~override~
			~%tutu_scriptf%twbax_d.cre~ ~override~
			~%tutu_scriptf%twbax_e.cre~ ~override~
WRITE_EVALUATED_ASCII 0x2CC ~X#RUMOR~ #8 // dialog
 BUT_ONLY_IF_IT_CHANGES

 

in _RBALDU, now renamed X#RUMOR.D,

 

BEGIN ~X#RUMOR~

APPEND ~X#RUMOR~

IF ~GlobalGT("Chapter","GLOBAL",%tutu_chapter_5%) RandomNum(8,1)~ THEN BEGIN 0
SAY @0
IF ~~ THEN JOURNAL @1 EXIT
END

IF ~GlobalGT("Chapter","GLOBAL",%tutu_chapter_5%) RandomNum(8,2)~ THEN BEGIN 1
SAY @2
IF ~OR(4) !InParty("skie") Dead("skie") !InMyArea("skie") StateCheck("skie",CD_STATE_NOTVALID)~ THEN JOURNAL @3 EXIT
IF ~InParty("skie") InMyArea("skie") !StateCheck("skie",CD_STATE_NOTVALID)~ EXTERN ~%SKIE_JOINED%~ SkieRBalduChain4
END

IF ~GlobalGT("Chapter","GLOBAL",%tutu_chapter_5%) RandomNum(8,3)~ THEN BEGIN 2
SAY @4
IF ~~ THEN JOURNAL @5 EXIT
END

IF ~GlobalGT("Chapter","GLOBAL",%tutu_chapter_5%) RandomNum(8,4)~ THEN BEGIN 3
SAY @6
IF ~OR(4) !InParty("xan") Dead("xan") !InMyArea("xan") StateCheck("xan",CD_STATE_NOTVALID)~ THEN JOURNAL @7 EXIT
IF ~InParty("xan") InMyArea("xan") !StateCheck("xan",CD_STATE_NOTVALID)~ THEN EXTERN ~%XAN_JOINED%~ XanRBaldurChain1
END

IF ~GlobalGT("Chapter","GLOBAL",%tutu_chapter_5%) RandomNum(8,5)~ THEN BEGIN 4
SAY @8
IF ~OR(4) !InParty("skie") Dead("skie") !InMyArea("skie") StateCheck("skie",CD_STATE_NOTVALID)~ THEN JOURNAL @9 EXIT
IF ~InParty("skie") InMyArea("skie") !StateCheck("skie",CD_STATE_NOTVALID)~ THEN EXTERN ~%SKIE_JOINED%~ SkieRBaldurChain1
END

IF ~GlobalGT("Chapter","GLOBAL",%tutu_chapter_5%) RandomNum(8,6)~ THEN BEGIN 5
SAY @10
IF ~OR(4) !InParty("skie") Dead("skie") !InMyArea("skie") StateCheck("skie",CD_STATE_NOTVALID)~ THEN JOURNAL @11 EXIT
IF ~InParty("skie") InMyArea("skie") !StateCheck("skie",CD_STATE_NOTVALID)~ THEN EXTERN ~%SKIE_JOINED%~ SkieRBaldurChain2
END

IF ~GlobalGT("Chapter","GLOBAL",5) RandomNum(8,7)~ THEN BEGIN 6
SAY @12
IF ~~ THEN JOURNAL @13 EXIT
END

IF ~GlobalGT("Chapter","GLOBAL",%tutu_chapter_5%) RandomNum(8,8)~ THEN BEGIN 7
SAY @14
IF ~OR(4) !InParty("skie") Dead("skie") !InMyArea("skie") StateCheck("skie",CD_STATE_NOTVALID)~ THEN JOURNAL @15 EXIT
IF ~InParty("skie") InMyArea("skie") !StateCheck("skie",CD_STATE_NOTVALID)~ THEN EXTERN ~%SKIE_JOINED%~ SkieRBaldurChain3
END

IF ~GlobalLT("Chapter","GLOBAL",%tutu_chapter_6%) RandomNum(11,1)~ THEN BEGIN 8
SAY @16
IF ~~ THEN JOURNAL @17 EXIT
END

IF ~GlobalLT("Chapter","GLOBAL",%tutu_chapter_6%) RandomNum(11,2)~ THEN BEGIN 9
SAY @18
IF ~~ THEN JOURNAL @19 EXIT
END

IF ~GlobalLT("Chapter","GLOBAL",%tutu_chapter_6%) RandomNum(11,3)~ THEN BEGIN 10
SAY @20
IF ~~ THEN JOURNAL @21 EXIT
END

IF ~GlobalLT("Chapter","GLOBAL",%tutu_chapter_6%) RandomNum(11,4)~ THEN BEGIN 11
SAY @22
IF ~~ THEN JOURNAL @23 EXIT
END

IF ~GlobalLT("Chapter","GLOBAL",%tutu_chapter_6%) RandomNum(11,5)~ THEN BEGIN 12
SAY @24
IF ~~ THEN JOURNAL @25 EXIT
END

IF ~GlobalLT("Chapter","GLOBAL",%tutu_chapter_6%) RandomNum(11,6)~ THEN BEGIN 13
SAY @26
IF ~OR(4) !InParty("skie") Dead("skie") !InMyArea("skie") StateCheck("skie",CD_STATE_NOTVALID)~ THEN JOURNAL @27 EXIT
IF ~InParty("skie") InMyArea("skie") !StateCheck("skie",CD_STATE_NOTVALID)~ THEN EXTERN ~%SKIE_JOINED%~ SkieRBalduChain5
END

IF ~GlobalLT("Chapter","GLOBAL",%tutu_chapter_6%) RandomNum(11,7)~ THEN BEGIN 14
SAY @28
IF ~~ THEN JOURNAL @29 EXIT
END

IF ~GlobalLT("Chapter","GLOBAL",%tutu_chapter_6%) RandomNum(11,8)~ THEN BEGIN 16
SAY @30
IF ~~ THEN JOURNAL @31 EXIT
END

IF ~GlobalLT("Chapter","GLOBAL",%tutu_chapter_6%) RandomNum(11,9)~ THEN BEGIN 17
SAY @32
IF ~~ THEN JOURNAL @21 EXIT
END

IF ~GlobalLT("Chapter","GLOBAL",%tutu_chapter_6%) RandomNum(11,10)~ THEN BEGIN 18
SAY @33
IF ~~ THEN EXIT
END

IF ~GlobalLT("Chapter","GLOBAL",%tutu_chapter_6%) RandomNum(11,11)~ THEN BEGIN 15
SAY @34
IF ~~ THEN JOURNAL @35 EXIT
END

END

CHAIN ~%SKIE_JOINED%~ SkieRBalduChain5
@36
END
IF ~~ THEN JOURNAL @27 EXIT

CHAIN ~%SKIE_JOINED%~ SkieRBaldurChain3
@37
END
IF ~~ THEN JOURNAL @38 EXIT

CHAIN ~%SKIE_JOINED%~ SkieRBalduChain4
@39
END
IF ~~ THEN JOURNAL @3 EXIT

CHAIN ~%SKIE_JOINED%~ SkieRBaldurChain2
@40
END
IF ~~ THEN JOURNAL @11 EXIT

CHAIN ~%XAN_JOINED%~ XanRBaldurChain1
@41
== ~X#RUMOR~ @42
== ~%XAN_JOINED%~ @43
END
IF ~~ THEN JOURNAL @7 EXIT

CHAIN ~%SKIE_JOINED%~ SkieRBaldurChain1
@44
== ~X#RUMOR~ @45
END
IF ~~ THEN JOURNAL @9 EXIT

 

That at least buys us time.

Edited by cmorgan

Share this post


Link to post

Hello -

 

Lousy timing, my friend - I (literally) just uploaded v15 final, in which I rebuilt the tras to have journal titles... and one of the few I was able to complete was that file ;).

 

Ha! Sorry. I just happened to make it to the city in my playthrough.

 

And, that file has been titled in EasyTutu for over a year now. Alboy tipped me off to the tavern rumors quite some time ago.

 

I'm also curious about the change in general. The tavern rumors are supposed to be little rewards for buying drinks in town...if two thirds of the commoners are spouting the lines from this file, it sort of ruins things for the bar crowd. :thumbsup:

 

In any case, I'll settle for not blowing away the existing dialog resource. With that adjustment in place, I can buffer against the rest in the next release.

Share this post


Link to post

My bet is the original materials were rebuilt because original project authors wanted to expand the commoners (and had a bunch of folks who didn't do the rumor in the bar thing). Plus, all that journal stuff never worked in Tutu intil you came along...

 

And they wanted to expand a couple of NPCs to have reactions to the rumors. It just is going to be a few weeks before I can research the workroom and check. The easiest fix is to leave the file as X#RUMOR, and delete the JOURNAL behavior entirely. But the package is up for CamDawg with this code, I tested it (much to my wife's dismay and decided displeasure) so I am off for RL to take her out for a nice afternoon walk, perhaps past a bistro that has good chocolate. Please let me know anything that you think needs fixing as you play through anyways, Macready. v16 may not be out (hopefully) for a long, long while, but I already have a collection of minor stuff that can be looked at over the next few months.

Share this post


Link to post

Nope - never get to do anything but fix stuff. Played your beta through the end of the Cloakwood Mines, and jumped around alot, but nothing bad to report; I really enjoyed it. I got journal entries, cast spells successfully, got my butt kicked by DavidW and his Mighty Minions, and had no troubles with SHS's new soundsets. Lots of investigation of your files using DLTCEP and NI, though, and basically, you rock, man. When you do something up, you do it up proud. I want to see that mod you were thinking of building.

 

The "not get to play" thing changes this week, now that v15 is locked and loaded - I am away for Easter, but when I get back, your newest EasyTutu is first for a real, slow, honest-to-god playthrough with my paladin, then Domi's IWD2, then a fully modded Morrowind on the new rig coming. The only work install will be a couple of BG2 mods I have in progress. I have spent too much time in modderland and not enough time playing.

Share this post


Link to post

Hello -

 

The "not get to play" thing changes this week, now that v15 is locked and loaded - I am away for Easter, but when I get back, your newest EasyTutu is first for a real, slow, honest-to-god playthrough with my paladin, then Domi's IWD2, then a fully modded Morrowind on the new rig coming. The only work install will be a couple of BG2 mods I have in progress. I have spent too much time in modderland and not enough time playing.

 

Amen! I've been enjoying my playthrough. At times it's a bit of a grind only because I know that I've set a release date that I'm trying to meet. But aside from that, I've been enjoying the ride.

 

Keep your promise to yourself this time.

Share this post


Link to post

So let it be written, so let it be done! :thumbsup:

Share this post


Link to post

May I make a suggestion as to how to go about releases with mature mods? As I've noted many times before, I'm -not- a modder yet, but I -have- been a professional programmer for about 15 years, and I totally grok all the woes that come with releases and roll-out quandaries.

 

Okay, my suggestion, and I'm going to use BG1NPC as my example but it should IMO be applied to virtually any semi-mature mods, including the soon-to-come releases of BG1UB and EasyTuTu:

 

When doing a big release, you really ought to be prepared to do another full release exactly one month later. Two months later at most.

 

So, example, you release v15 on April 2 (to avoid the inevitable april fool's jokes). You actually -plan- a release of v16 for May 2. During the month of April, you do -absolutely nothing- for whatever "to do" list you've got in your mind Take this opportunity to mostly take a month off, play your games, and for the love of God do NOT do anything like fix journal entries, typos, or any other non-essential work. The -only- changes to be made between version 15 and 16 are game, romance, spell or quest breaking bugs that only come out when v15 is released. What is considered a "breaking" bug should have a pretty high standard.

 

If I was king of the modding world, I'd set this up as standard for every release of every mod that had already been out for more than a year. Odd numbered versions are essentially "public betas" (but do NOT advertise them that way directly, they -have- been beta'd and it's fair to assure your players that it is a thoroughly beta'd version). DO let your players know what the plan is.

 

I'd even set it up like this: Even numbered versions are what you get after you've fixed the few critical bugs that were inevitably introduced by your most recent odd numbered version. No odd numbered version should remain the most recent version for more than a month or two. No optional, non critical fixes will be applied in the release of even numbered versions.

 

This is especially critical when you're trying to, as you've stated cmorgan, increase the interim between full releases. If you're planning to let v15 sit out there for over a year, and v15 is really really solid except for those -two- bugs that squeaked through the betas, one that breaks Shar-Teel's romance altogether and another that messes up the BG poison quest, that's just going to create great pain and misery for everyone. It won't wash. People will hate you for not fixing those two bugs, and it'll make you -have- to work on that v16 faster than you'd have wanted to. So, plan on it, on a schedule, and don't contaminate those critical bug fixes with the -optional- fixes like journal entry work and updating to modern coding conventions, etc.

 

The way it works -now-, you guys release v15, and tomorrow someone's already fixing more typos and journal entries. Then two weeks later someone finds a bug which literally makes your hard drive explode the moment Imoen steps into the Elfsong Tavern. Quick! Fix it, test it, get it out the door! But oh crap, now it's a bear to test because we've already got 60 modified files that do nothing but update coding standards submitted for testing, and we gotta test those too before we release. Obviously this is a hyperbolic example, but believe me, I know, that sort of thing happens inevitably, and is the biggest headache there is in Coding Paradise.

 

With my suggestion, this -greatly- takes the stress off of your v.15 release, because I -know- (I've been there, brother) that you're dying right now because you want to not have to do another release for another 2 years, and the stress is more likely to make you make a mistake which will make that even more of a pipe dream. Bad plan to start with. No matter how good you are, there are almost certainly going to be a small number of critical bugs that don't come out in private betas, that -only- come out during mass releases, and that almost -always- get reported within a few weeks, if not the first few days, after your full release.

 

Make it 2 months if you want, and take a 2 month break for your playthroughs. But -don't- do a major release that has never been publically tested and expect not to change it for over a year - that's how a romance winds up getting killed for an unacceptable amount of time. Instead, you TELL everyone - this v15 is a full release, it's beyond beta status, it's expected to work great, have a blast, but know that v16 is scheduled for a month or two from now which will address ONLY critical, quest or game breaking bugs in v15. No other work on this mod is even -allowed- until v16 comes out - modders who want to update coding standards are firmly told to go play a game or work on a different mod for that month or two. Code only to be touched for gamebreaker problems.

 

As a player, I'd -love- to see that, and it would make me much more eager to play the v15 version so the big bugs get caught and that the version we'll ALL be stuck with for the next year or three (v16) won't have critical bugs in it.

 

And then, once v16 is out and you've got a pretty solid version out there, you can -really- relax and take your time with the optional crap for the v17 that you can now much more comfortably schedule for September 2009.

 

Sorry, I'm really too long winded, but I hope I argued my case for this roll-out strategy well enough. Hope it helps.

 

Qwinn

Edited by Qwinn

Share this post


Link to post

Bleh, heh, for curiosity's sake I looked at the history of v14 and it looks like most of the real problems with it didn't come out till a couple months after...

 

So... um...

 

...never mind...

 

:thumbsup:

 

Qwinn

Share this post


Link to post

It's true, though. RE, Angelo and de'Arnise romance followed this strategy: we released v2 a month or two after v1, and it helped reduce pressure, took away issues needing immediate attention, and so on. So I agree, it works.

Share this post


Link to post
Bleh, heh, for curiosity's sake I looked at the history of v14 and it looks like most of the real problems with it didn't come out till a couple months after...

 

So... um...

 

...never mind...

 

:thumbsup:

 

Qwinn

Oh, heck no, Qwinn, they are good points - the standard mod doesn't really plan for this sort of thing, as RL makes coding a spotty endeavor. It might be one hour of time over lunch with one file, then perhaps tomorrow three hours stolen from family time, then a weekend where you get a block of four or more hours (as long as you keep RL in some kind of balance...)

 

The concept is as sound as the standard practices of "tick" and "tock" where a major upgrade is planned for one year and then a second "minor revision" comes along the next year to repair the bugs. The difficulty in enabling it is that the amount of time varies greatly. It was over a year, including an entire summer of full time work (40 to 60 hours a week - the advantage of being a teacher is we get summers off, and I really love the project - plus I was learning all about modding, which was way cool) to do the rebuilds within v12 and get the project reassembled, and this past summer was less time but had more people on the team contributing code and dialogue.

 

Most major mods seem to stall out and become abandoned for large chunks of time by their authors, because folks move on (The Quest Pack, Sirine's Call, and even bug-free projects like Finch) or they temporarily get tired of the personalities active on the forums. Some mods go through rather rapid bursts of fixes, versioning up whenever a minor bug is found. Basically, it is all over the place.

 

The good news with BG1NPC is it has been one of the most widely tested and scrutinized modding projects around, ever. Teams of folks have worked on it for years, providing all sorts of content, until finally it became its own worst enemy - this last round has literally been allowing intended content to play without hijacking itself ;). Our troubles can generally be resolved by setting a variable using CLUAConsole, or perhaps placing a quick patch on things if something escapes. We have the advantage of both Tutu and BGT communities of playtesters and modders, so we get twice the experienced help. And, as you mention, even then there will be the unexpected problem that arises.

 

Usually, it is not a big deal to accellerate the process and release a few months after a big fixup. But when it is not an enjoyable experience to check in to the forums and spend free time that could be spent on my dogs, or my wife, or my music, or even playing, then there comes a point of diminishing return. I enjoy helping folks out, and I enjoy collaborating with reasonable adults in a friendly manner. When that happens, I enjoy myself, and I work harder on mods, and I volunteer my time gladly. When I find the atmosphere ugly, I feel less like working on that project and more like working on other projects. It is a measure of my respect for Domi and a love of the project that any changes are present at all, because the project was closed a long while ago, and could have simply been shut down and had no bugfixes present after the earliest Beta 12s.

 

But the primary takeaway is that BG1NPC is not planning any year+ wait for checking for bugs. But "long time", the original plans I set up a few years ago had us working to 6 month intervals centered around a G3 Anniversary release each year when all major known issues were resolved. I am not going anywhere - I am 40 now, so for the next 20 years or so, I expect little stuff will crop up from time to time. I simply will need to balance off my own work with the materials in this project, since right now it takes up almost all my modding time and most of my free time. Otherwise, the whole thing gets closed for good.

Share this post


Link to post

I have a feeling it's much, much better to be an "abandoned and bug-free" mod, rather than to be constantly revised and still have unfixed issues (often springing from these very revisions) for months and months.

 

I recall that Jaheira's quest, for example, was working in its main path after it was first released in v11; I remember, because I was testing it. Then, of course, the proverbial changes came, and in v12, it stopped working at all - and, again, hasn't worked for an entire year.

 

Between changes for changes' sake and "Don't fix what ain't broken", I know what I prefer.

Share this post


Link to post

Hmmm, I didn't notice any problems with the Jaheira quest on my latest run, though it was with EasyTutu. Pretty sure it finished properly. I could go back and check, if it's desired... I never get rid of saved games, heh.

 

Qwinn

Share this post


Link to post
Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...