Post reply

Name:
Email:
Subject:
Message icon:

Verification:
Type the letters shown in the picture
Listen to the letters / Request another image

Type the letters shown in the picture:
What color is grass?:
What is the seventh word in this sentence?:
What is five minus two (use the full word)?:

shortcuts: hit alt+s to submit/post or alt+p to preview


Topic Summary

Posted by: Wisp
« on: June 16, 2019, 12:57:38 PM »

Yes, I mistyped. It was late.
Posted by: DavidW
« on: June 15, 2019, 07:19:35 PM »

Should that be -(2^31), or does WEIDU have a floating-point capability I haven't come across?
Posted by: Wisp
« on: June 15, 2019, 06:30:56 PM »

If the label is not unique, WeiDU cannot (and does not) resolve the label into a component number. Instead -2^31 is returned.

Edited for correctness.
Posted by: Gwendolyne_FP
« on: June 09, 2019, 03:58:09 PM »

I understand, but how many mods use LABEL?

I wanted to use them to check if IA_contents were installed. As many components share the same content, it would have been a good way to identify them and avoid checking for all the components of using the IF_FILE_EXIST command.

It works fine but unfortunately displays warnings that may confuse players.
Posted by: DavidW
« on: June 09, 2019, 12:45:41 PM »

In this case, I am afraid to find them redundant with component numbers, therefore useless.

The point of LABEL was always to allow constant reference to a component even when its number changed, e.g. because of a change in the logical structure of the tp2.
Posted by: Gwendolyne_FP
« on: June 08, 2019, 11:27:49 AM »

In this case, I am afraid to find them redundant with component numbers, therefore useless.
Posted by: Wisp
« on: June 08, 2019, 11:23:56 AM »

Would it be possible to get rid of the warning when two or more components use the same LABEL?
No. Labels resolve into component numbers and therefore must be unique.
Posted by: Gwendolyne_FP
« on: June 03, 2019, 10:23:38 AM »

Would it be possible to get rid of the warning when two or more components use the same LABEL?

I am using them for Infinity Animations to specify which IA_content is installed to run each component. That way, modders won't have to check for existing bam files (with weird names) to know if their are installed or not, but rather use this kind of code:

Code: [Select]
ACTION_IF (MOD_IS_INSTALLED "infinityanimations.tp2" (ID_OF_LABEL "infinityanimations.tp2" "IA_content_01")) BEGIN
Posted by: the bigg
« on: October 10, 2010, 06:49:37 AM »

Is the point of LABEL to obliterate the need of markers, or only to allow for flexible MII substitute? Because if that's the former, then I'm unsure if you are fixing anything (I may be reading this thread wrong, though), since markers in reality serve a very definite purpose, completely different from MII.
Marker files still remain the most effective way to track this sort of thing (you can use FILE_EXISTS ~override/banter-accelerator.mrk~ rather than keeping track of all mods that contain a banter accelerator). LABEL and MOD_IS_INSTALLED are like a Toyota Prius: it's ugly, slow and less cost-effective than oil-operated cars, but snotty intellectuals feel superior by using it because it doesn't pollute the air override.
Posted by: GeN1e
« on: October 09, 2010, 10:31:56 PM »

Is the point of LABEL to obliterate the need of markers, or only to allow for flexible MII substitute? Because if that's the former, then I'm unsure if you are fixing anything (I may be reading this thread wrong, though), since markers in reality serve a very definite purpose, completely different from MII.
That purpose being nothing else than to act as a global over-tp2 WeiDU variable, because you can't ~SET mod_x_is_here = 1~ and expect it to be read by the next WeiDU launch.
Detectable Spells is a good example, because it now is put into separate tph and dumps a marker to prevent the repeated clean-up of previous versions (Ascension, Kelsey). And obviously it can't check for MII, since it doesn't know which mod will use in future - for example, I'm incorporating it into RtW, and SCS/RR can't know that without an update.

What really would be helpful, is to have a way to store variables between mods, perhaps by extending WeiDU.log or dumping a new WeiDU.arg into the game directory, callable with every setup launch.

Code: [Select]
~setup-mod_1_name.tp2 #component_number1~
{
  SET ag#_was_hereX = 1
}
~setup-mod_1_name.tp2 #component_number2~
{
  SET ag#_was_hereY = 1
}
~setup-mod_2_name.tp2 #component_number1~
{
  SET ag#_was_hereX = 1
  SPRINT ag#_was_here_string ~~~~~using string for a mindf@cking crazy purpose I can't ~%possibly%~ imagine~~~~~
}
Using #component_number to allow for adequate per-mod variable deletion, in case the user opts to partially reinstall later.

Using OUTER|INNER_LABEL_SET|SPRINT may also serve as a normal SET|SPRINT, though I'm certain none would ever need this, since they don't check for their own markers within that component.
Posted by: cmorgan
« on: October 02, 2010, 05:18:18 PM »

Cool - I understand. With bg1npc I think I  am stuck with marker files " just in case" / backwards compatibility, this is something that certainly attracts me for stuff I might do.
Posted by: the bigg
« on: October 02, 2010, 07:26:22 AM »

I am going to continue dropping marker files in the override, BTW - the only people who dislike them are Miloch (and WeiDU 221 removes his objections) and Jarno (but he's a colossal moron, so nobody should consider anything he says).
Posted by: DavidW
« on: October 02, 2010, 05:23:15 AM »

[Edit: on the other hand, L1NPCs relies on a !(MOD_IS_INSTALLED ~setup-scs.tp2~ 3020) to make sure it doesn't mess with BG1 NPCs affected by SCS's analogous component. So I guess I would need to know the LABEL for that if DavidW intends on changing the component number (again). If not, I don't see the need to replace a bunch of existing syntax.]

Good case-study, actually. I'm not intending to change the component number, but I can't promise not to, and I can't really keep track of all the mods that might be relying on my fixed component numbers.

@Cmorgan: I don't strongly feel that it is better than component flag dropping (it's a bit more elegant and aesthetically pleasing). The idea came out of a discussion of why MOD_IS_INSTALLED couldn't substitute for marker files, and consideration of what would so substitute. I'm not especially planning to retrofit SCS to this just yet, though I'll certainly use it going forward.
Posted by: Miloch
« on: October 01, 2010, 10:46:51 PM »

If I am reading this correctly, this is a more intricate way of doing

BEGIN ~mymodcomponent~

COPY ~swh101.itm~ ~override/small_flag_file_that_indicates_this_component_is_installed.g3~
It's probably a "less intricate" or at any rate less crufty way of doing it. See here for a background discussion, if you really want some bedtime reading material :D.

It is equivalent to using MOD_IS_INSTALLED [component#] but DavidW's issue was that mod component numbers (of active mods anyhow) can be subject to change, whereas labels might be less so. It isn't really necessary unless you're in that position. For example, bigg's comment about Aurora doesn't worry me much, because I don't really plan on rearranging the existing component numbers (any more). If I did, I would probably introduce LABELs. Likewise, Level 1 NPCs has about 100 components now, but I don't see the real value of LABELs for it for the same reason, unless someone wants to make a case for that.

[Edit: on the other hand, L1NPCs relies on a !(MOD_IS_INSTALLED ~setup-scs.tp2~ 3020) to make sure it doesn't mess with BG1 NPCs affected by SCS's analogous component. So I guess I would need to know the LABEL for that if DavidW intends on changing the component number (again). If not, I don't see the need to replace a bunch of existing syntax.]
Posted by: cmorgan
« on: October 01, 2010, 06:23:16 PM »

If I am reading this correctly, this is a more intricate way of doing

BEGIN ~mymodcomponent~

COPY ~swh101.itm~ ~override/small_flag_file_that_indicates_this_component_is_installed.g3~

BEGIN ~mynextmodcomponent
REQUIRE_FILE ~override/X#BG1NPCCore.G3~ @1004 /* BG1 NPC Required Changes component is not installed. */


etc.


Is there a good reason for folks to stop flagging the components and start using an internally defined label? The only one I can think of is if R_P and R_F only check override, and someone has biff'd the install. (I'm not criticising adding the functionality, only asking what makes it more powerful/interesting/useful than simply dropping a flag file for each component and checking for it like UB/BG1NPC used to do).