component Same array(s) in different components

[Incrementis]

Hello everyone,

I'm trying to understand how to use more than one component in WeiDU.

An issue occurred where components do not use the same array values initialized in the ALWAYS section.

Unfortunately, this is not described here in the WeiDU documentation.

To understand what is meant here, here is a simple tp2 code that can be used for testing:

Spoiler

// -----------
// Information
// -----------
BACKUP ~./weidu_external/TestingComponents/backup~ // %MOD_FOLDER% doesn't work here
AUTHOR ~Yes~
VERSION ~v0.0.0~
AUTO_EVAL_STRINGS// This will prevent the need of EVAL for string variables


// --------------
// Initialization
// --------------
ALWAYS 

	ACTION_DEFINE_ARRAY testArray
	BEGIN 
		~TRUE1~
		~TRUE2~
		~TRUE3~
	END
	
END// End of "ALWAYS"




BEGIN ~Test-Component 1~
ACTION_DEFINE_ARRAY testArray
BEGIN 
	~FALSE1~
	~TRUE2~
	~FALSE3~
END

OUTER_FOR (index = 0; VARIABLE_IS_SET $testArray(~%index%~); ++index) BEGIN
	OUTER_SPRINT testvalue 	$~testArray~(~%index%~)
	PRINT ~Test-Component 1 -> testvalue:%testvalue%~
END


BEGIN ~Test-Component 2~
OUTER_FOR (index = 0; VARIABLE_IS_SET $testArray(~%index%~); ++index) BEGIN
	OUTER_SPRINT testvalue 	$~testArray~(~%index%~)
	PRINT ~Test-Component 2 -> testvalue:%testvalue%~
END

 

As we can see, the array is initialized in the ALWAYS section.

After that, the first component changes the values it contains.

Finally, the second component prints the array values to see if it knows the new values. Unfortunately this is not the case.

The first component will print the following:

Test-Component 1 -> testvalue:FALSE1

Test-Component 1 -> testvalue:TRUE2

Test-Component 1 -> testvalue:FALSE3
 

The second component will print the following:

Test-Component 2 -> testvalue:TRUE1

Test-Component 2 -> testvalue:TRUE2

Test-Component 2 -> testvalue:TRUE3

The second component has the initialized array values.

 

Here are my questions:

• Is this normal behaviour?
• Does it make sense to solve this via ACTION_READLN or is there a better way to solve this?

What I have is basically a main component and a kind of auxiliary component. They can work independently and collaboratively.

In order to work together, they have to share and modify arrays.

 

Thank you for reading this post!

 

Edited January 23 by Incrementis
Removed text in spoiler section

[Jarno Mikkola]

You can make subcomponents, that have different settings(aka at install time you get to choose which one the mod isntalls, and you can never install BOTH)... not at all sure how you would use those, but I think that you can avoid using ACTION_READLN here... and you don't want to set values in an ALWAYS component... for cheese sake. You can set functions up in it, but you run the functions in a (sub)component.

[AL|EN]

@Incrementis

I remember that there was some trouble with the slashes at the beginning of the BACKUP, remove "./" just to be safe.

Avoid ACTION_READLN unless you want to force players to babysit the whole installation for many hours.

As for the issue: the ALWAYS block will be re-executed a second time when component 2 is installed.

 

[jmerry]

From the documentation on ALWAYS:

Quote

This flag specified a TP2 Action that is executed at the beginning of each Component, before the component-specific TP2 Action.

So, you define that array in the ALWAYS block, setting its values. In component 1, you redefine the array, setting new values. And then print them.

Go to component 2. Run the ALWAYS block again, resetting the values of the array. And then print them.

If you want to have one component modify variables that another component later uses, you can't go and define them in the ALWAYS block, because that'll just reset them every component. Instead, have that later component do conditional things; if VARIABLE_IS_SET, skip, otherwise define the variable. Or maybe you can save things as a 2DA file in "workspace".

[argent77]

17 minutes ago, Incrementis said:

Here are my questions:

• Is this normal behaviour?

Yes. The ALWAYS block is executed for each component separately. This is necessary since the user may choose to install both components at once or each component by a separate WeiDU call.

 

17 minutes ago, Incrementis said:

Does it make sense to solve this via ACTION_READLN or is there a better way to solve this?

ACTION_READLN only allows the user to enter data. It doesn't directly solve the problem of sharing data between components.

To forward array data from one component to another you could use text files with the array content. Another (and probably better) option would be to generate a WeiDU script file (.tph) dynamically by component 1 with the updated array definition that can then be INCLUDEd by component 2 if it exists.

[Incrementis]

Good morning,

Thank you everyone for the valuable information.

It will help me find a solution and it helps me to understand things better.

[DavidW]

15 hours ago, jmerry said:

Or maybe you can save things as a 2DA file in "workspace".

Don't put them there: weidu_external/workspace doesn't make any guarantees about files being preserved or protected between components, it's for manipulations within a component. Put them in weidu_external/data/%MOD_FOLDER%.

[jmerry]

Thanks for the clarification; I haven't used any of those spaces myself, so I wasn't up on the details.

After thinking about it some more, you definitely want to save any data that you're passing between components to a file somewhere. After all, you can't even guarantee that two different components will be installed in the same session, unless you're using something like FORCED_SUBCOMPONENT. Saving to a permanent file of some kind is the only option that consistently works here.

[DavidW]

Well, to be clear: these are just *my* conventions when I set up weidu_external as a shared resource.

The other method is Cam's: just create a weidu_external/%MOD_FOLDER% directory, and do what you like in it.

& yes, exactly as regards passing information between components. In fact, ideally you should actively avoid information leaking between components by wrapping each in a function or a WITH_SCOPE, because that's the only way to guarantee consistent behavior.