14 replies to this topic

[Baronius]

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!

Edited by Baronius, 21 December 2006 - 07:31 AM.

[the bigg]

weidu --automate somedir --out myfile.tp2

[Baronius]

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.

Edited by Baronius, 21 December 2006 - 12:02 PM.

[the bigg]

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).

It can't at the moment, but I can add this to the new version, if somebody reports the deficiency.

Also, does Weidu detect strrefs in embedded effects in ITM/CRE?

It does for ITM and SPL, I'm unsure of CRE - but again, I can code this for the next version.

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)

It does this automatically.

to set it to use different TRA starting indices for different filetypes

Just use multiple directories and files, along with --traify#.

and to add tp2 comments automatically (such as creature's names and items names to sign their COPY block)?

You can use --traify-comment.

Hopefully this was decently clear and satisfactory

[Baronius]

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.

[SimDing0]

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.

Edited by SimDing0, 21 December 2006 - 01:35 PM.

[GeN1e]

Still it's good for store-, spell- and itemmods which don't require too many modder-hours to be completed and add a large amout of stuff.

[Baronius]

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).

[SimDing0]

but in case of large mods, it's not the best idea to develop your mod on implementation level.

Experience dictates otherwise.

Yes, you're correct that this is fine and sensible for things like store mods.

[Baronius]

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

[the bigg]

In any event, I threw together a small shell script to do (almost) all the tasks you requested in about half an hour (and I don't even know Bash - I spent more time looking up the manual than hacking), so it's not obvious that a new program was really needed (as opposed to clever use and combination of existing tools). To run shell scripts on Windows, you need something like CygWIN (or a better operating system).

#!/bin/bash

if [ -n "$2" ]; then
	output=$1
	directory=$2
	
	echo 'BACKUP ~tmp~ AUTHOR ~me~ BEGIN ~~ //IGNORETHISLINE' > tmp-stub.tp2
	for a in spl itm cre eff sto are; do
		if [ -d $directory/$a ]; then
			echo "automating and traifying the $a files"
			(
				echo
				echo '////////////////////////////////////////////////////////////////////////////////'
				echo "//							  handle $a files							   //"
				echo '////////////////////////////////////////////////////////////////////////////////'
				echo
			) > tmp-stub1.tp2
			weidu --automate $directory/$a --out tmp-tmp.tp2
			cat tmp-stub.tp2 tmp-stub1.tp2 tmp-tmp.tp2 > tmp-$a-part.tp2
			echo
			echo Starting Number for $a files?
			read b
			weidu --traify tmp-$a-part.tp2 --traify# $b --traify-comment --out res-$a.tp2
		fi
	done
	
	echo "Merging all files"
	
	cat res-*.tp2 | grep -v "//IGNORETHISLINE" > $output.tp2
	cat res-*.tra > $output.tra
	echo
	echo 'Cleanup?'
	read a
	a=`echo $a | tr '[:upper:]' '[:lower:]'`
	if [[ $a == y || $a == yes ]]; then
		rm res-*.tp2 res-*.tra tmp-*.tp2
	fi
else
	echo "usage: $0 out-tp2-file mod-base-dir"
	echo
	echo "out-tp2-file shouldn't contain the .tp2 extension"
	echo "the directories mod-base-dir/(spl|itm|cre|eff|sto|are) will be checked"
	echo "the files out-tp2-file.tp2, out-tp2-file.tra will be overwritten"
	echo "the files res-*.tp2, res-*.tra, and tmp-*.tp2 will be deleted"
	exit 1
fi

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

[Baronius]

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.

Edited by Baronius, 21 December 2006 - 04:32 PM.

[SimDing0]

Without knowing how you organize your design phase

The sad truth is "I don't organize it".

[the bigg]

1. No STO and EFF files. "They can be added in the later version if more people want it" doesn't help on me

STO was already there, but I see your point nonetheless

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.)

Ah, I must've misunderstood you, there's no quick way for WeiDU to do this

3. I don't want to distribute the UNIDENTIFIED_DESCRIPTION and NAME for the items[...]

That's why we have the --automate-min option - otherwise, WeiDU starts from the SoA new strings.

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.[...]

Yes, obviously. It's just that I'm mostly set in the Unix mindframe, rather than the Windows one, and I love the CLI, so I have some troubles thinking in the newbie way

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.

Well, I could always either redistribute the script (so that they don't have to re-type every time all the program), or I could have written it in OCaml and stacked a simplicistic GUI on it - but then, I'm talking more about "don't reinvent the automate wheel and use/adapt WeiDU" rather than "don't write the guide TP2 at all", so 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

Also, the usual questions: is there a source code? Is it in a cross platform language or in a Windows-only, MS Visual Studio Something only one?

[Baronius]

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...

Edited by Baronius, 25 April 2007 - 04:54 PM.