Thanks for your answer, Erephine. I might fix the mod (also adding your cool images) sometime.

I give my consent for your Herbs files, feel free to keep them available in this thread.

Good luck to your hobby, keep up the good work!

Nice work, Erephine. (Including the excellent herb drawings.)

I have NOT asked for permission to do this. I will put it offline immediately if asked.

Why didn't you send an email? Both the Herbs website and the mod's readme includes my email address.

This was done for my own enjoyment, and I am only sharing it here, because I feel this is a very interesting mod, and it deserves to be played. !!

Thank you for your compliment, I'm glad to hear you find it interesting. It was planned to be extended (Herbs should be spread in the game, Tutu edition still has BG1 item descriptions, some items are overpowered...), but somehow I could never get to it. However, now that you've made these cool changes, I could try to integrate them (and release a new version) sometime in the future -- of course, you would be credited in the readme & website. What do you think?

By the way, your package includes itm files as well -- did the BAM references require update, or what are the changes?

I had Delphi available when developing this, which was handy to create the GUI efficiently but as the model is certainly separated it wouldn't be complicated to implement (convert) the model to C++ or Java. If there is a demand, it will be done.

I guess that my real point by now would be that the ideal way IMHO to have asked for extensions to WeiDU so that TP2CG would just do all the command combination, rather than having to implement the TLK reader, traificator, again

As I've already mentioned, WeiDU has shown unusual behaviour to me in the past, and not just once, and it really isn't much effort to implement a TLK handler.

Edit: grammar...

TheBigg:

In any event, I threw together a small shell script to do (almost) all the tasks you requested in about half an hour[..]

My first comment:
Yeah, almost
Examples where I couldn't use it:
1. No STO and EFF files. "They can be added in the later version if more people want it" doesn't help on me
2. As I said, I want to control the scope of TRA entry reuse. Because e.g. for a group of certain files of a type (itm, for example) I might not want to use the same entry for them even if they have the same description, because modification will be problematic in the future. (If you change description of MISC1A.ITM, a new entry will be needed or it will affect MISC1B, MISC1C too because they all have the same @number in the tp2. Complicated.)
3. I don't want to distribute the UNIDENTIFIED_DESCRIPTION and NAME for the items (but not for spells!) because my mod is for a given game setup, so the strRefs in my files refer to the correct dialog.tlk entries. So instead of providing and distributing my own custom description (even if it's copied from my game) for items that have a standard in-game description, I want the mod to use the target game's dialog.tlk for these.

My second comment:
Yes, you can solve practically everything in such a way and format that you've introduced in your previous post, but this is exactly why you use the GUI of your operating system for your everyday activities on your computer: user-friendliness, easy to customize, many settings, quick (from user's aspect, not the program efficiency; i.e. you don't have to type console commands, for example.) Furthermore, many people don't know and/or don't want to learn it either how to write such stuff that you've written above. On the other hand, they can easily what buttons to click and what to type to certain textfields, can't they? I released this program, so I want to make it available to others as well. Isn't it faster, especially for the starter user, to click a checkbox than setting the value of a boolean variable (if he can program at all...).

Obviously, a new program would allow you to make your output code adapt better to your tastes - but IMHO I'd prefer to spend a week on the mod rather than on an utility program I'd use only once

I see a little self-contradiction here, though I'm sure you didn't mean it in that way. Adapting better to my tastes -- an utility used only once? The utility exactly ensures that for any number of tasks & problems, I can customize it to meet my current task's requirements. So it's definitely not something that I use once. Furthermore, you exactly did it with your code above: one code for a specific problem class. With TP2CG, I can customize everything quickly, without having to change code lines. And think of the users who can't make code that you've posted. Remember, clicking checkboxes or setting booleans?

Finally, I believe that GUI programs bring modding closer to people. I don't want to discourage people from learning weidu, but saying "learn weidu, it's easy" to everyone is not always helpful to them. Some people simply don't want it, or don't have the time. They can have very good mod ideas regardless. They may learn basic TP2 syntax and structure, but they might not want to search offsets in NI to make tp2 code.

More generally, I believe that implementation (coding) level should be separated from the design and creative work. Someone can be a good mod maker without knowing how to negate a number in two's complement to produce -1. Yes, this shifts the modder's picture from the "hacker/programmer expert" to the picture of "storyteller/ world-creator" person who is otherwise amateur in the ways of computer science. TP2CG is far from this possibility (i.e. to offer an interface to people to make a mod without knowing the internal details), as it's not even a mod management program, but I mentioned this just to emphasize that telling "hey, everything can be solved via commandline" to people might not be the best tendency.

The fact that such a code that you've posted is required to solve those tasks I've listed, exactly proves that there is little user-friendliness here, amateurs would have little chance. If you had provided 10 weidu commandline inputs, the case would be a bit different, but you provided a composite programming structure instead -- which might not even be readble by amateurs, not that they make such a code from scratch. (Yes, amateurs might also want to distribute only certain texts of their items or spells while using the target dialog.tlk for other texts; and without knowing how to make "SAY" code with accurate offset values. Yes, amateurs might also want to use type-based indexing for their TRA entries, to be able to modify them and extend in the future easily.)



SimDing0:
As I've said, your methology is not bad, in fact now I say it may be perfect for the class of problems you're facing while developing your quest mods. Without knowing how you organize your design phase (and other phases of the development cycle), I can't form an opinion that is not vague, obviously.

Now that I've examined QuestPack, I can see a major reason why you recommend incremental tp2 creation & reinstallation. This roots in the fact that Questpack modifies/extends a lot of content, so you have to manipulate many files and then apply it on the game. WeiDU offers efficient ways (C_E_REGEXP etc.), so you create the installer simultaneously while applying your changes on the game.
I believe this methology works very well in many cases, mainly in case of (but not limited to) mods that affect a lot of existing content, i.e. their connection to the original game is strong.
On the other hand, generally it's advantageous to keep the implementation details hidden until we don't need them (In your works that I know of, this was obviously impossible, as there was no other way to apply your changes on the game as using weidu. In fact, in this case, this seems to be the best way.) So we can focus our attention on the quests and we can remain game-centric. This works for mods that have less connection with original game content and add a large amount of new, mostly "independent" content.
For example, if you just need to change area flags for five areas during your mod's development (while focusing on content and gameplay), you tick a checkbox in DLTCEP once, for each; instead of moving your attention to set bitmasks and writing code context for it etc. It's enough if you document this somewhere (yes, correct and precise documentation is essential in any methology), and at the end, you apply these changes. Note: yes, it really doesn't matter whether you make code for five areas immediately or you write it at the end, but imagine other file types, with other minor things, and so on.

Again, in your applications it was required to use low-level code from the beginning. The previous example must be changed to "change the area flags of N area files". N is probably big, or unknown at least. And it may differ from player to player (hence the strong connection with the game setup I spoke of), so generic approach is needed here.

Consequently (considering the what I've told about Implementation), I believe that the correctness of your methology (as of every methology) depends mainly on the features of its Design phase.

Could you tell the major steps of you developing a large & complex quest mod?

Typing them to the TP2 manually is a lot of time for a big quest mod,

As I've said before, this isn't a good way to go about developing a quest mod. Build your content in WeiDU form as you go along, rather than converting it at the end. You still do lots of typing, but it's broken up so it's less painful.

The method you suggest is not bad and also offers a certain level of self-documentation, but in case of large mods, it's not the best idea to develop your mod on implementation level. Simply because it distracts your attention from the important parts if you have to deal with the implementation details on such a low level (file copying, file manipulation, bitwise (!) operations etc.) Keep in mind, I'm talking about very big, complex mods. However, obviously I'm not implying either that a large quest mod should be developed in the "make new Cre with dltcep, test it in game, make new item in dltcep, test it in game...." style. Ad-hoc development would be hopeless here. A proper methology is needed here, to determine the necessary processes of design, implementation and validation (and more, if needed).

Furthermore, "intuitive" development is wide-spread for certain mod types, of smaller or medium size. This is what GeN1e refers to above. Its advantages are the joy of incremental development & playing (testing) and the good effectivity of bug-hunting (because the complexity of the mod is low, unlike e.g. in case of quest mod where one quest may have several branches that have more branches and so on).

Thanks, theBigg. This is why I made TP2CG, to do what the current weidu version lacks and I need it (EFF/STO support, user-defined scope of string reuse, flexible TRA management due to automated type-based tra indexing and certain other things.) I also experienced some unreliability with traify in the past (once it generated incorrect numbers, while at another time, the whole output .d file was commented out etc.), but considering your hard work on weidu, I guess those were fixed meanwhile I just prefer setting everything precisely on my own, and then having the files auto-checked during code generation.

If weidu can directly do what I need, I probably reinvented the wheel for myself.

The mod I'm developing has stores as well. WeiDU says this --automate works only with CRE/ITM/SPL/CRE files. Is there a way (command) to do the same for STO and EFF files? (I don't have 50 stores but it's easy to forget to make code for strrefs at certain offsets). Also, does Weidu detect strrefs in embedded effects in ITM/CRE? Furthermore, I want to control the scope of TRA entry re-use (i.e. not to generate a new entry for each string if the same text is used 111 times in my mod), to set it to use different TRA starting indices for different filetypes, and to add tp2 comments automatically (such as creature's names and items names to sign their COPY block)?

TheBigg, could you tell if there is any way to do those with weidu commandline? Typing them to the TP2 manually is a lot of time for a big quest mod, hence the tool, but if weidu can also do it, it's even better.
Thanks in advance.

Do you have area, item, creature, effect, spell, or store files which work in your game perfectly, but you don't have the TP2/TRA code you need to distribute their names, descriptions, texts?

TP2 Code Generator can help you:
http://forums.blackw...?showtopic=2372

Thanks to berelinde and cmorgan for the testing and suggestions!
Thanks to Sir-Kill for creating the program icon!

True that, what erebusant wrote - never had trouble with TGCE1. The original-original version overwrote, but Baronius corrected that.

Actually, it has never overwritten anything. It was that the technique I used and BG1Tutu didn't like each other for some reason, so I applied a new solution in the new edition.
EDIT: Actually, I think I know why it seems it used to overwrite FAI; it's the mod never reverting FAI to its original form. Practically, it's basically the same as overwriting, so changing this was essential in its successor, In Candlelight.

but i have to add that it appears to be down/ have become a paysite; so it might not be of much use to you.

Hey Sean,
Would it be a large request from me if I asked you to explain *what* text from here made you think it became a pay site? Please do so.

I don't understand: can one not download unless a donation is made?

No one can download anything until the site is open again. It was disabled because otherwise the downloads would make the whole site slow down and then die. But all this is accurately explained on the page I linked to.

It should be compatible (or can be made compatible with little effort) with any usual wmp file. (You will need to extend it a bit though if you have a wmp file with more worldmap entries, because the current code assumes there is one worldmap entry and adds the area to that.)

Nonetheless, I took a very quick look at the TP2 of Yacomo's cool-sounding extended wmp. As far as I can see, it rebuilds the whole wmp with a fixed list of areas & their attributes, so areas not on its list will not be kept. Consequently, I guess any mod that adds an area on its own  (e.g. by using my code) instead of having a Yacomo-Wmp-entry should be installed after Yacomo's wmp mod. (By the way, DELETE_BYTES ("%links_num%") 0xD8 shouldn't be something like DELETE_BYTES ("%links_offset%") 0xD8? I checked the file very quickly so I might have missed something obvious.)

Tutorial and template code, to install an area with multiple links to the worldmap, via WeiDU.

http://www.blackwyrm...ls/patchwmp.php

(another argument, inter alia, against TeamBG's hosting of the dialogue tools used to build TS).

You didn't state its opposite or such, but I would like to add that Vlad used that tool because there wasn't any better. TS was the first mod with a great number of banters/interjections.

Since the thead hasn't been updated since Apr, these seem to be missing:
- IEGMC Canada is not among the list of IEGMC mirrors.
- BWL has an RSS feed as well. forums.blackwyrmlair.net/rss.php

Just thought I would mention them.

(However, even if it's profitable, why not? No one would be so stupid not trying to make money from a site when it's possible.

Um, I would. *checks to see if dictionary.com has an entry for "personal conviction."

Okay "no one" was a too general term. I admit. As you could see in my earlier post. Let me quote it:

Even if it were more profitable than what I do or plan to do, I wouldn't choose that either. Business kills the hobby. Competition kills the fun. (I'm talking of a enterprise which primary activity is making and selling mods. Assuming the legal background /license etc./ is given.)

Even if it were more profitable than what I do or plan to do, I wouldn't choose that either. Business kills the hobby. Competition kills the fun. (I'm talking of a enterprise which primary activity is making and selling mods. Assuming the legal background /license etc./ is given.)

The only modding-related financial gain I can think of is Sorcerer's Place encouraging people to donate to their site as a way of giving thanks for providing mod downloads, despite the facts that they didn't make most of the mods (something they're not always open about) and a lot of the links are external.

Do you have any clue how much does its forum software, server, active technical support (and this wasn't everything) cost per month? Plus the RAM and hardware upgrades when required.
(However, even if it's profitable, why not? No one would be so stupid not trying to make money from a site when it's possible.
The old TeamBG also tried to negotiate with Bioware about a commercial activity related to mods. When there might be a possibility, why not to make an attempt?)

I don't know about any concrete examples to it in modding, but it's quite possible (if not obvious) that since there are so many games and many mods, some people are trying to make some money from it. As far as IE modding is concerned, I don't know of any examples either. BWL and IEGMC asks for donations (and I may have seen it somewhere else too but I don't remember), but these (at least BWL; as I can only talk in BWL's name) make so little income that it's enough only to compensate a few percent of the total costs.

Then we agree. Rare event.

Writing a leaking program is looking into the future because of the additional RAM needed? This sounds like a Microsoft commercial - "We coded it with the technology of yesterday, sell it today, and you'll use it with the computers of tomorrow!"

Generally, if memory leaking is intense enough, no RAM will prevent your system from freezing / giving other symptoms sooner or later -- provided you are constantly using the program for long enough time.

EDIT: To sum up, "for future" is not an excuse for a leaking program. Of course it can make it usable at least (see Vlad's case). But naturally this doesn't substract anything from IETME's significance in IE area creation. First make a better program, and then tell how bad the others are.

Update: Don't use WinBiff to extract any WED and TIS files. Many thanks to Vlad for sharing this at TeamBG!

You know, it's very confusing having all of this discussion about TeamBG policy on Studios, while Studios policy discussions take place on PPG, etc. etc. Maybe that would be a good use for the otherwise-unnecessary FWP forum--a one-stop shop for all site policy discussions!

Heh, this is a good idea, it could be named Inferno or Troll Mound.
We could have deathmatches or one against all fights there.

I know better. Considering how popular these fight threads are, I think we should meet in reality and organize a good fight.
JCompton could bring his deadly vipers, guest would be disguised in a robe, and everyone could gratify his/her passions in the fight, using fists, daggers & stuff. And so on... would be much fun, wouldn't it?
Would save some bandwidth for SHS too.

OK I'm a complete idiot. I must have been viewing Page 1 of this thread, and when replied, the reply appeared here, in Page 2. The post I replied is the last one on page 1, so it exists, sorry for the inconvenience.

Ctrl+C and when forum is back Ctrl+V (with the assistance of Notepad meanwhile, if needed)

(Was meant to be the reply to guest's question, but since it was deleted, feel free to delete mine as well.)

I only have to say that Theo did study programming, and the fact that IDU/IDW/IETME were never updated is only a matter of lazyness. He knows the bugs the tools have, and no, hes not going to fix them

I didn't want to imply that he wasn't aware of the bugs or wouldn't be able to correct them (if I had done it anywhere, let me correct myself here). However, what I tried to explain to theBigg in my long post about programming, is that it's not the same how a code is written. I'm not sure where or what Theo studied (I remembered that not in uni, but I apologise if I'm wrong), but this case is general and not just about him: it's much easier to fix bugs in a well-written code where the technology was chosen wisely etc. (And in uni you obviously get more versatile knowledge than in a course, for instance). This is why programmers who are studying in university or studied in university may produce better code than others (usually). But even for them, debugging is sometimes not a too easy task, and this is what I wanted to explain to theBigg. (Not sure with how much success).

And why wouldnt he claim ownership and "hide under a rock" instead? Cos he had the balls and spent time making a tool now obsolete? Thats as stupid as saying "dude, if i had invented the bike id hide under a rock cos now you have cars and planes". I think in its own time IDU did its job. Now you have better tools, hooray for it, by all means, use them and forget about IDU, just as youd use linux over windows 3.1.

Nice summary, Ana! Perfectly summarizes my point as well. And an explanation to why I suggest new modders (but not just them) to respect the old, now obsolete tools instead of talking them as c**p.