Find content
Not Telling
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!
Baronius
Member Since 25 Aug 2005Offline Last Active Apr 07 2009 03:37 AM
Posts I've Made
In Topic: TP2 Code Generator released
22 December 2006 - 09:40 AM
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.
Edit: grammar...
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.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
Edit: grammar...
In Topic: TP2 Code Generator released
21 December 2006 - 04:25 PM
TheBigg:
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...).
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.
My first comment:In any event, I threw together a small shell script to do (almost) all the tasks you requested in about half an hour[..]
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...).
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?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
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.
