384 replies to this topic

[Littiz]

Finished re-installing and found the source of a couple of problems.

1- IMPORTANT FOR KISH
(to be posted in his forum too...)

An incompatibility is given by one of Oversight's component, "Cleric Kits".
First, you use direct copy instead of patching (you lazy man ). This should be avoided at all costs, since it deletes any addition to the file made by previously installed kits
Second, you apply values that would seem correct, but all of them are also followed by "0000" (with the exception of the first 2, which aren't standard)
These final four zeros aren't needed - and, as I suspect, actually wrong.
In any case, they prevent Refinements' patches to apply, and surely, with those values, things here don't work anymore (the_bigg did a check with one of them).
Proposed Solution:
Could you please "steal" our code for KIT.IDS WeiDU-patching?
That one gives no problems if it gets applied twice, and the values are surely correct (or at least, they always worked in all of my tests).
I might think to turn the commands in a list of SET_2DA_ENTRY, but I think it would be better this way - even for Oversight, if I'm right about the values.


2- Fixed the Wong Fei's stone problem with Kensais. This one was really nasty (I did remove the Kensai flag, already!), and it was tied to my changes made for the Use Scrolls "engine".


3- I've decided to think a bit more about the problem, and I've found how to render Kits from other mods compatible to our Use Scrolls system.
Tricky, it'd need some significative work for interested mod authors, but it's doable. The only kits that would need such treatment are kits duallable to thief, BTW.

Edited by Littiz, 11 June 2004 - 07:12 AM.

[the bigg]

3- I've decided to think a bit more about the problem, and I've found how to render Kits from other mods compatible to our Use Scrolls system.
Tricky, it'd need some significative work for interested mod authors, but it's doable. The only kits that would need such treatment are kits duallable to thief, BTW.

I think that you need to ask Weimer (anti-paladin and generic archer) and Ghreyfain (the pit fighter and a whole crapload of cleric kits).
Or, better, I could ask them myself (knowing of your limited free time frame ). But, seeing from your work, it doesn't seem like they will have much to do, it's just up to copy some more of your tp2 work...

[Littiz]

Thx the_bigg, but it won't be that simple I'm afraid
Refinements needs 3 "versions" of each kit, external mods would need 4, to handle the case of Refinements' absence.
There are also the scripts - that would need to be extended - and other stuff.
Things would be easier for kits usable only by the protagonist, still it'd require some work (and it'd also raise installation ordering requirements).
I might explain things to you in a greater detail though, so you might still handle this part, if you want

I confirm what I said about Oversight: those values don't seem to work, and prevent Refinements to work as well. Going to inform Kish

Edited by Littiz, 13 June 2004 - 01:43 AM.

[Idobek]

Your kits.ids patching uses REPLACE_TEXTUALLY on white spaces, could you please not do that? You only need to patch the hex values anyway. This also occurs elsewhere in the tp2, it is not a good idea because the white spaces can be changed by things like SET_2DA_ENTRY.

Would it not be possible to make Use Scrolls an optional component? It would make overall compatiblity so much easier.

[Littiz]

Your kits.ids patching uses REPLACE_TEXTUALLY on white spaces, could you please not do that?

I might probably change this for KIT.IDS, but surely not everywhere.
I needed some tricky uses of the command for the shadow kits, IIRC, and maybe elsewhere.
Without including spaces and some more text, I'd patch things that are not meant to...
But I suppose you're right, in that case it's just redundant.

Would it not be possible to make Use Scrolls an optional component? It would make overall compatiblity so much easier.

Sorry, this is not an option, I fear.
Both for technical (the code is spreaded everywhere) and consistency reasons (it's one of the Key Points of the new HLA system, which has always been treated as an unique block).
I'll give all the possible support to provide compatibility WITH the mechanism, though

Edited by Littiz, 13 June 2004 - 10:16 AM.

[Idobek]

I needed some tricky uses of the command for the shadow kits, IIRC, and maybe elsewhere.
Without including spaces and some more text, I'd patch things that are not meant to...
But I suppose you're right, in that case it's just redundant.

From what I can see this can all be done with SET_2DA_ENTRY. I am mentioning this because I use SET_2DA_ENTRY on kitlist.2da which means that the Refinements code doesn't work if it is installed after NPC Kit.

Umm... while I'm here I should mention that the "Pretty 2DAs" code has been improved some. This:

COPY_EXISTING ~WEAPPROF.2DA~                 ~override/WEAPPROF.2DA~
REPLACE_TEXTUALLY ~NAME_REF~                 ~ID NAME_REF~
SET_2DA_ENTRY 34 7 1 ~3~
SET_2DA_ENTRY 34 39 1 ~3~
SET_2DA_ENTRY 34 40 1 ~3~
REPLACE_TEXTUALLY ~
ID~ ~
   ~

is better expressed as this:

COPY_EXISTING ~WEAPPROF.2DA~ ~override/WEAPPROF.2DA~
SET_2DA_ENTRY 0 0 2 ~2DA_V1.0~
SET_2DA_ENTRY 0 1 2 ~~
SET_2DA_ENTRY 0 0 53 ~PLACEHOLDER ID~
SET_2DA_ENTRY 34 7 1 ~3~
SET_2DA_ENTRY 34 39 1 ~3~
SET_2DA_ENTRY 34 40 1 ~3~
SET_2DA_ENTRY 0 0 54 ~~
REPLACE_TEXTUALLY ~2DA_V1.0~ ~2DA V1.0~

[Littiz]

From what I can see this can all be done with SET_2DA_ENTRY.

This is not the case.
When you add a kit with the ADD_KIT command you must also specify the 3 related dialogue strings.
For the shadow copies of the original kits, I used dummy strings to be replaced with the correct description pointers.
You can't set those pointers with SET_2DA_ENTRY since you can't know which position a new kit will occupy.

I could change the whole mechanism, including copies of those strings in the TRA file, probably (I mean, directly having them used by the "invisible" SAY commands of the ADD_KIT command). But I seem to remember I had reasons to discard even that solution...
Ah, it's been a while.
For now I can change the piece of code you pasted, though, thx, then I'll try to think a bit more about the issue

Edited by Littiz, 13 June 2004 - 10:04 PM.

[the bigg]

You can't set those pointers with SET_2DA_ENTRY since you can't know which position a new kit will occupy.

Yes, you can: use some tricky multi - while loops and you've done it.

BW: if you send me as more details as possible on how this code works, I can make it work also for modded kits, without having to resort to contact Weimer, Ghreyfain and the other guys.

[Idobek]

It is possible to know where the new kits are in kitlist.2da by using READ_2DA_ENTRY. The value in the first column is %MYKIT% you can scan down using a WHILE loop. I actually do this on kits.ids but the principle is the same. Here is the code I use to scan kits.ids:

COPY_EXISTING ~kit.ids~ ~override~

  SET "row" = 1

  READ_2DA_ENTRY 1 0 1 "kitname"

  WHILE NOT ("%kitname%" = (0x4000 + "%IK_EDWIN_KIT%"))

  BEGIN

    SET "row" = ("%row%" + 1)

    READ_2DA_ENTRY "%row%" 0 1 "kitname"

  END

  SET "lastcolumn" = (53 + "%row%" - 33)

I use this to find the last column of weapprof.2da for compatibilty with AoE and Rogue Rebalancing without multiple ADD_KITs.

[Littiz]

Ok guys, we might do something then. But let me do an example: today my modding time equals the time to write this answer. Tomorrow will be the same and so on

Anyway, I HATE while loops, and if we can do otherwise, we'll do otherwise.
I mean, I'd have *TWENTY* kits to patch that way.
Ok, it's a lot of copy paste work, but hey.
Also the CLAB files are now correctly set with REPLACE_TEXTUALLY commands...
sigh, everything works so nicely
This thing will raise bugs like the plague

SET_2DA_ENTRY

Hmm, this new command might prove useful, I see.
It could be used to recognize external Kits, so, keeping the logic of having Refinements installed last, we might directly update the UNUSABLE values of those kits, reducing the number of needed copies to 3 kits total for each kit, and handle everything from this side, as the_bigg seems to suggest.
Hmmm.
People, these modifications to the installer, alone, are worthy of a new Refinements version, do you realize it?

@the_bigg: another one who follows the mechanism would be a nice help in any case.
So please have a look at this thread. That's the very basic idea.
Consider that I didn't know a LOT of stuff when I wrote that: things are considerably trickier in truth, especially the scripts.
The worst part were trueclass thieves, all mages, and something else.
The case of non-thief kits duallable to thief is the easiest to handle luckily, but I'll explain you later

EDIT: a step back.
The %MYKIT% value is available when a kit is installed via ADD_KIT.
I'd need to read a string to recognize external kits.
I don't know if it's possible right now, and my head is smoking after work

Edited by Littiz, 14 June 2004 - 12:38 PM.

[the bigg]

I think I can handle this without install-order or such crappy things on part of the end-user (apart from Refinemets = last)...
READ_2DA_ENTRY reads also strings, so we're set on this: I read them in kitlist.2da with while loops (eg. Anti-Paladin - I can read the clab coloumn with "wwanti" and save the row number) and set there the unusable value.
Just to get everything clear:

(original) wwanti gets the undead hunter unusable,
wwantiTF gets the empty clab and not the UH unusable
wwantiTW gets the original clab and not the UH unusable,

Then I merely copy/past from your pair of check scripts, in a sequence of action_if file_exists wwanti.2da then extend_top baldur.bcs refinements\blabla\wwanti.bcs .

Have I got everything clear? If so, then great!
Otherwise, correct me where I am wrong and I will do the dirt work.

BTW: don't underextimate WHILE loops, they are really powerful!

[Idobek]

I have been looking again at the Refinements TP2. The incompatibilty problems come with this section:

//Set restrictions and adjust string references
COPY_EXISTING + ~KITLIST.2DA~     ~override/KITLIST.2DA~
REPLACE_TEXTUALLY ~29           0x00000001~     ~29           0x00000021~
REPLACE_TEXTUALLY ~30           0x00000002~     ~30           0x00000022~
REPLACE_TEXTUALLY ~31           0x00000004~     ~31           0x00000024~
REPLACE_TEXTUALLY ~40           0x00100000~     ~40           0x00100020~
REPLACE_TEXTUALLY ~47           0x01000000~     ~47           0x01000020~
REPLACE_TEXTUALLY ~48           0x02000000~     ~48           0x02000020~
REPLACE_TEXTUALLY ~49           0x04000000~     ~49           0x04000020~

This is the section for the vanilla kit usability values and it is this I am suggesting you do with SET_2DA_ENTRY.

This following section is confusing me:

REPLACE_TEXTUALLY ~30530 30530 30530 ~     ~30530 30530 9561 ~
REPLACE_TEXTUALLY ~35320 35320 35320 CLABTH01 ~     ~25189 25160 25213 CLABTH02 ~
REPLACE_TEXTUALLY ~35320 35320 35320 ~     ~25189 25160 25213 ~
REPLACE_TEXTUALLY ~25161 25161 25161 CLABTH01 ~     ~25190 25161 25215 CLABTH03 ~
REPLACE_TEXTUALLY ~25161 25161 25161 ~     ~25190 25161 25215 ~
REPLACE_TEXTUALLY ~25162 25162 25162 CLABTH01 ~     ~25191 25162 25216 CLABTH04 ~
REPLACE_TEXTUALLY ~25162 25162 25162 ~     ~25191 25162 25216 ~
REPLACE_TEXTUALLY ~25151 25151 25151 CLABTH01 ~     ~25179 25151 25201 CLABFI02 ~
REPLACE_TEXTUALLY ~25151 25151 25151 ~     ~25179 25151 25201 ~
REPLACE_TEXTUALLY ~25153 25153 25153 CLABTH01 ~     ~25181 25153 25204 CLABFI04 ~
REPLACE_TEXTUALLY ~25153 25153 25153 ~     ~25181 25153 25204 ~
REPLACE_TEXTUALLY ~26755 26755 26755 CLABTH01 ~     ~25195 25168 25221 CLABPR02 ~
REPLACE_TEXTUALLY ~26755 26755 26755 ~     ~25195 25168 25221 ~
REPLACE_TEXTUALLY ~25169 25169 25169 CLABTH01 ~     ~25196 25169 25222 CLABPR03 ~
REPLACE_TEXTUALLY ~25169 25169 25169 ~     ~25196 25169 25222 ~
REPLACE_TEXTUALLY ~25170 25170 25170 CLABTH01 ~     ~25197 25170 25223 CLABPR04 ~
REPLACE_TEXTUALLY ~25170 25170 25170 ~     ~25197 25170 25223 ~
REPLACE_TEXTUALLY ~30497 30497 30497 CLABTH01 ~     ~30497 30497 9563 CLABMA01 ~

It will always work because (I think) it only applies to the kits you have just installed. However, why are you doing it this way? From what I understand you are attempting to creating a unique line during the kit installation and then replacing it afterwards, and you are doing this because you don't want to include the kit descriptions with Refinements. What I don't understand is why you simply don't specify the correct strings refs during ADD_KIT using SAY #xxx, this specifies an existing string to use for the description/name etc. From what I can tell this entire section would not then be necessary.

[Littiz]

(original) wwanti gets the undead hunter unusable,
wwantiTF gets the empty clab and not the UH unusable
wwantiTW gets the original clab and not the UH unusable,

Correct logic, but, in general, we have two scripts to update. Ehm, three.
Baldur.bcs, Baldur25.bcs and the script used by the Use Scrolls HLA.

Just think that mage scrolls are "locked" for all characters who can dual to thief.
If a char duals to mage, he must be "freed" via the permanent script, while when a char duals to thief, he must be "freed" via HLA, when that is picked.
Of course, always coherently with the state activated or not_yet_reactivated starting class.

Also, we are trying to reduce the load.
So, if a kit cannot be dualled, it should need no action at all (isn't it the case of the anti-paladin?).
If it's duallable only to thief, the baldur scripts need no update.
The creature's script needs always a pair of scripting blocks per kit, since it checks for LastSummonedBy() or something.
As you've seen, the baldur scripts need 6 pairs of blocks (one pair per party slot), but if we have a kit meant only for the protagonist, we can drastically reduce this to just one pair, again.
I used some pivot variables too, for additional checks, but I don't think we should mess with them ATM.
Oh, and if the new kit is a thief kit, the behaviour is similar, yet it all depends on the UNUSABLE used (we might be in trouble here).

After all, it shouldn't be as scary as I thought at first... Kits that come from mods have already an ADD_KIT command to copy stuff from (which wasn't true for the original kits ), and the scripts to handle these parts are relatively simple (though it is extremely easy to do something wrong, trust me...).
Still, it's a draining task, so I thank you for the help you're offering, @the_bigg
Oh, one more note: remember that KITTABLE.2DA must NOT be updated by the additional kits.

BTW: don't underextimate WHILE loops, they are really powerful!

I know how powerful and elegant they are, I just HATE them (in WeiDU)

This is the section for the vanilla kit usability values and it is this I am suggesting you do with SET_2DA_ENTRY.

Done.
It works, the only problem is that SET_2DA_ENTRY forces my hex values to the decimal form Much harder to read an UNUSABLE in decimal...
Then, I just avoid SET_2DA_ENTRY when possible, since I never learned how to reformat the tables correctly
Hm, speaking about your "pretty 2da" code: I got two ID columns. Is that meant to happen?

What I don't understand is why you simply don't specify the correct strings refs during ADD_KIT using SAY #xxx, this specifies an existing string to use for the description/name etc. From what I can tell this entire section would not then be necessary.

You are partly right, in that I am greatly ignorant and I didn't know about the "#" operator... I just used the first solution I came up with.
Still, this part has another function, so it cannot be removed.
The ADD_KIT command was created to add NEW kits, and forces you to provide a CLAB file. I was using it to add copies of existing kits, and I hated the idea of filling the mod and the override with CLAB files identical to the original ones.
So I just used the same CLAB for everyone, and patched the names later. If I patch them together with the strings, they all go to their right places, otherwise I'd need tricky while loops, READ_2DA_ENTRY commands or whatever.
Since this code already works, and it spares useless backup, I'd prefer to leave it as it is.
Of course, I'm not a WeiDU guru and there might be better options available, but until they're not necessary....

And uh, why do you always suppose I place useless code?

Edited by Littiz, 15 June 2004 - 12:01 PM.

[Idobek]

Hm, speaking about your "pretty 2da" code: I got two ID columns. Is that meant to happen?

This appears to be a side effect of applying the new version of the code over old, odd--I'll see if I can get around it.

It works, the only problem is that SET_2DA_ENTRY forces my hex values to the decimal form  
Much harder to read an UNUSABLE in decimal

This must be a side effect of Wes change the code to allow expressions.

Then, I just avoid SET_2DA_ENTRY when possible, since I never learned how to reformat the tables correctly

You don't have to format the tables at all. If you don't want to bother, don't do it.

And uh, why do you always suppose I place useless code?

I don't, I am just trying to offer advice--mainly because I would like my mod(s) to work with Refinements.

The ADD_KIT command was created to add NEW kits, and forces you to provide a CLAB file. I was using it to add copies of existing kits, and I hated the idea of filling the mod and the override with CLAB files identical to the original ones.
So I just used the same CLAB for everyone, and patched the names later.

Right, I get what you are doing there now. Unfortunately, I am going to make another suggestion: Copy all the clabs files you need into the override before you add the kits and then specify those clabs during ADD_KIT.

[the bigg]

Ok, I've done (I hope!) Anti-paladin and Generic Archer (They're both dual-able to thieves, and can be chosen by everybody in Multi Player, so I patch baldur.bcs for the whole 6 kits). I'm just going to test them. It's just ugly!

ACTION_IF FILE_EXISTS "override\wwarch.2da" THEN BEGIN

   ADD_KIT ~WWARCHtF~
[...]
   ~Refinements/Hlab/Thief/clab/CLABEMPT.2DA~
[...]
   SAY @1
   SAY @1
   SAY @1

   ADD_KIT ~WWARCHtw~
[...]
   ~override/wwarch.2da~
[...]
   SAY @1
   SAY @1
   SAY @1


   COPY_EXISTING + ~KITLIST.2DA~                 ~override/KITLIST.2DA~
   REPLACE_TEXTUALLY ~ROWNAME~                 ~ID ROWNAME~
   SET "row"=3
   SET "patchdone"=0
   //patch unusable flag for anti-paladin
   WHILE ("%patchdone%"=0)  BEGIN
         READ_2DA_ENTRY "%row%" 4 1 "kit"
        WHILE (("%kit%" = "WWARCH") AND ("%patchdone%" = 0) BEGIN
                   SET "kitlistrowanti" = "%row%"
        SET_2DA_ENTRY "%row%" 7 1 0x00000021
        SET "%patchdone%" = 1
                      END
              SET "row" = "%row%" + 1
          END
   READ_2DA_ENTRY "%kitlistrowanti%" 2 1 "lower" //names for USSCR kits
   READ_2DA_ENTRY "%kitlistrowanti%" 3 1 "mixed"
   READ_2DA_ENTRY "%kitlistrowanti%" 4 1 "help"
   SET_2DA_ENTRY "%WWARCHtF%" 2 1 "%lower%"
   SET_2DA_ENTRY "%WWARCHtw%" 2 1 "%lower%"
   SET_2DA_ENTRY "%WWARCHtF%" 3 1 "%mixed%"
   SET_2DA_ENTRY "%WWARCHtw%" 3 1 "%mixed%"
   SET_2DA_ENTRY "%WWARCHtF%" 4 1 "%help%"
   SET_2DA_ENTRY "%WWARCHtw%" 4 1 "%help%"
   REPLACE_TEXTUALLY ~
   ID~ ~
     ~ // ~enter/ID~ ~enter/2 spaces~

          EXTEND_BOTTOM ~Baldur.bcs~   ~Refinements/Hlab/Thief/wwarch.baf~
   EXTEND_BOTTOM ~Baldur25.bcs~   ~Refinements/Hlab/Thief/wwarch.baf~
   EXTEND_BOTTOM "li#stri.bcs" ~Refinements/Hlab/Thief/wwarch1.baf~


   //full compatibility with all weapprof modifiers (like, say, AOE)
   COPY_EXISTING + ~WEAPPROF.2DA~                 ~override/WEAPPROF.2DA~
   REPLACE_TEXTUALLY ~NAME_REF~                 ~ID NAME_REF~
   SET "row"=3
   WHILE ("%row%" < 35) BEGIN
         READ_2DA_ENTRY "%row%" "%kitlistrowanti%"  1 "WWARCH"
  SET_2DA_ENTRY "%row%" (22+"%WWARCHtF%") 1 "%WWARCH%"
        SET_2DA_ENTRY "%row%" (22+"%WWARCHtw%") 1 "%WWARCH%"
        SET "row" = "%row%" + 1
          END
   REPLACE_TEXTUALLY ~
ID~ ~
   ~ // ~enter/ID~ ~enter/2 spaces~


END

Oh, I've added a feature: new kits will be compatible with mods that change weapprof.2da, like Universal Weapons... BTW: trueres &C. get the THIEF weapon proficiency, or somebody else's one?

COPY_EXISTING + ~WEAPPROF.2DA~                 ~override/WEAPPROF.2DA~
REPLACE_TEXTUALLY ~NAME_REF~                 ~ID NAME_REF~
SET "row"=3
WHILE ("%row%" < 35) BEGIN
            READ_2DA_ENTRY "%row%" 7 1 "thief"

[...]
      SET_2DA_ENTRY "%row%" (22+"%trueres%") 1 "thief"
      SET_2DA_ENTRY "%row%" (22+"%truequF%") 1 "thief"
      SET_2DA_ENTRY "%row%" (22+"%truequi%") 1 "thief"
[...]
      SET "row" = "%row%" + 1
END
REPLACE_TEXTUALLY ~
ID~ ~
   ~ // ~enter/ID~ ~enter/2 spaces~

The ADD_KIT command was created to add NEW kits, and forces you to provide a CLAB file. I was using it to add copies of existing kits, and I hated the idea of filling the mod and the override with CLAB files identical to the original ones.
So I just used the same CLAB for everyone, and patched the names later. If I patch them together with the strings, they all go to their right places, otherwise I'd need tricky while loops, READ_2DA_ENTRY commands or whatever.

Ehm, why? use COPY_EXISTING "clabxx??.2da" "override" beforehand and then reference to the one in the override. And, if you keep it the other way, don't name it CLABTH01, since you can easily overwrite changes done by some external mod, name it TEMPCLAB.2DA or something like this...

Anyway, Littiz, could you send me the tp2 (if you've done any change to Use Scrolls part) so that I can keep them?

2 compatibility questions:

1) If a Kit uses the Undead Hunter flag (not sharing it, but using it like you've done with the Sword Angel) what should I do?
- uninstall it
- try to change the unusable of the scrolls
- don't install at all refinements
- ...?

2) Should I update the HLA's of new kits or not? EG: change the Generic Archer from Fi0 to Ra2 ?

[Littiz]

This appears to be a side effect of applying the new version of the code over old, odd--I'll see if I can get around it.

You mean when it has already applied by another mod, like Rogue Rebalancing?
Does it prevent the file from working? I ask since it happens even with the old version, it seems...

This must be a side effect of Wes change the code to allow expressions.

I keep my opinion that it's better to avoid SET_2DA_ENTRY, when possible
I can live with that decimals, though.

I don't, I am just trying to offer advice--mainly because I would like my mod(s) to work with Refinements.

Of course, same for us. Extended compatibility was already in schedule
Thank you for past and future advices, if I haven't said this already

Right, I get what you are doing there now. Unfortunately, I am going to make another suggestion: Copy all the clabs files you need into the override before you add the kits and then specify those clabs during ADD_KIT.

Why should I put in the override useless stuff?
Why modify a working code that doesn't have this flaw?


@the_bigg:
Nice work!! Answers:

Ok, I've done (I hope!) Anti-paladin and Generic Archer (They're both dual-able to thieves, and can be chosen by everybody in Multi Player, so I patch baldur.bcs for the whole 6 kits).

I, for one, would drop compatibility with multiplayer games...

The code you pasted seems correct to me, but since you removed the ADD_KIT parameters I can't check it all.
Anyway, you can check better than me at this point, just be sure to nullify the patching of KITTABLE.2DA.

Oh, I've added a feature: new kits will be compatible with mods that change weapprof.2da, like Universal Weapons...

I don't know what that mod does

BTW: trueres &C. get the THIEF weapon proficiency, or somebody else's one?

I think so, but I don't remember ATM.
The kits for trueclasses caused a lot of problems at the time, I'd avoid messing with them if possible, since we'd SURELY cause bugs.

And, if you keep it the other way, don't name it CLABTH01, since you can easily overwrite changes done by some external mod, name it TEMPCLAB.2DA or something like this...

I can change the name to avoid overwriting the thief CLAB, but for the rest I prefer to keep the existing solution, since it seems more efficient to me (no stuff in the override for no reason) and it is already working

If a Kit uses the Undead Hunter flag (not sharing it, but using it like you've done with the Sword Angel) what should I do?

In theory, it'd have no reason to: as it is, it's a redundant flag for the system.
Why building a new kit using that value? It'd give no particular unusability settings (unlike, say, the Cavalier's value).
No one should be using it.
IF someone uses it, we'll try to understand why, and we'll tailor a solution.
EX: if that kit isn't meant to use mage scrolls, we don't need to do anything, again

Should I update the HLA's of new kits or not? EG: change the Generic Archer from Fi0 to Ra2 ?

It's not our job, really.
Plus, the Generic Archer is not a ranger...

I can send you the latest version of the mod (which is close to 1.04) if your mail account can receive it. Can it?
Please, let me have a look at the scripts too, just to spare you from banging your head where I have already

Edited by Littiz, 16 June 2004 - 11:17 AM.

[CamDawg]

If a Kit uses the Undead Hunter flag (not sharing it, but using it like you've done with the Sword Angel) what should I do?

In theory, it'd have no reason to: as it is, it's a redundant flag for the system.
Why building a new kit using that value? It'd give no particular unusability settings (unlike, say, the Cavalier's value).
No one should be using it.
IF someone uses it, we'll try to understand why, and we'll tailor a solution.
EX: if that kit isn't meant to use mage scrolls, we don't need to do anything, again

The Archer of Sylvanus kit from the SP Collection has been using this flag for a while for the exact same reason. Being a druid kit it doesn't need scrolls, so there shouldn't be an incompatibility.

I understand your aversion to modifying working code, but Idobek's suggestions with regards to S_2_E will solve a lot of potential compatibility problems for Refinements in the future.

[Littiz]

The Archer of Sylvanus kit from the SP Collection has been using this flag for a while for the exact same reason.  Being a druid kit it doesn't need scrolls, so there shouldn't be an incompatibility.

Ehm, what reason?
You mean, because it's redundant so you can abuse of it, like I did?
If it changes the flag of some items, there might be an incompatibility...

I understand your aversion to modifying working code, but Idobek's suggestions with regards to S_2_E will solve a lot of potential compatibility problems for Refinements in the future.

Cam, I've changed the code to use S_2_E where Idobek asked me to do it.
Changing it where it is NOT needed causes more problems than it solves, as I've explained in my previous posts

Edited by Littiz, 16 June 2004 - 09:54 PM.

[the bigg]

The Archer of Silvanus uses (I think to guess) the Undead Hunter flag the same way you've done with the Jester flag on the Sword Angel.

The ADD_KIT parameters are the ones from the usual Anti-paladin, so they should be OK.

Universal weapons changes the weapprof.2da, allowing everybody to put proficiencies everywhere, EG a mage can put pips in sword or whatever. I've added the ability to add all weapon use also to the tw and tF kits.

@ e-mail: No, my e-mail accepts only <2.5 megs files. But, if you use winrar, I think that the problem would be over (or you could anyway split the file up in two pieces). You can doownload it from www.download.com, it isn't very much big...

Also, I've tried my code, and SURPRISE! WeiDU CANNOT compare two strings, so my hands are tied, and my code won't work, nor can guess how to do it.

Well, I could replace_textually "0x00000001" "0x00000021" /before/ adding ALL the new kits (like the berstF), but it seems to me that it can easily generate bugs. Damn...

For some strange reason, I cannot open PocketPlane, so I cannot ask Weimer to add the string-comparing feature.

Edited by the bigg, 17 June 2004 - 04:31 AM.