Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RuntimeVar: Add variable RandomVar that holds a random value #121

Conversation

tangtang95
Copy link
Collaborator

Other than adding a new variable RandomVar, the RandomVarOnce has been updated to use the same data structure of RandomVar. The idea behind this variable is to have a variable that holds a random value that can be rerolled. The reroll strategy is based on two conditions:

  • The lookup of the conditional folder of this RuntimeVar has just started (this is controlled by the locked attribute, which is locked after the first lookup and unlocked after it is resolved)
  • A delta time in seconds has been passed from the last reroll If these two conditions are satisfied, the random variable is rerolled, and the last reroll timestamp is updated. This can be used with the notation:
<RuntimeVar Var="RandomVar:{varName}:{size}:{deltaTime}" Values="217..218" />

where:

  • {varName} has to be substituted with an identifier name for the variable
  • {size} has to be substituted with a number that is the range of the random variable that goes from [0, size-1]
  • {deltaTime} is optional and has to be substituted with the minimum delta time to allow the random variable to be rerolled (if it's not set, deltaTime is 0)

Notice that you can combine RandomVar and RandomVarOnce to use the same identifier {varName}. In this way, when it looks up for RandomVarOnce it does not reroll anything, but only get the random value.
Another two important prerequisites are:

  • Each conditional folder using the same RandomVar should contain the same files
  • All the values of the RandomVar should be mapped to a conditional folder (e.g. if you have RandomVar:prelude:2 and there is only a conditional folder that looks for Values=0, this won't work)

Other than adding a new variable RandomVar, the RandomVarOnce has been updated to use the same data structure of RandomVar.
The idea behind this variable is to have a variable that holds a random value that can be rerolled. The reroll strategy is based on two conditions:
 - The lookup of the conditional folder of this `RuntimeVar` has just started (this is controlled by the `locked` attribute, which is locked after the first lookup and unlocked after it is resolved)
 - A delta time in seconds has been passed from the last reroll
If these two conditions are satisfied, the random variable is rerolled, and the last reroll timestamp is updated.
This can be used with the notation:
```xml
<RuntimeVar Var="RandomVar:{varName}:{size}:{deltaTime}" Values="217..218" />
```
where:
 - `{varName}` has to be substituted with an identifier name for the variable
 - `{size}` has to be substituted with a number that is the range of the random variable that goes from [0, size-1]
 - `{deltaTime}` is optional and has to be substituted with the minimum delta time to allow the random variable to be rerolled (if it's not set, `deltaTime` is 0)

Notice that you can combine `RandomVar` and `RandomVarOnce` to use the same identifier `{varName}`. In this way, when it looks up for `RandomVarOnce` it does not reroll anything, but only get the
random value.
Another two important prerequisites are:
 - Each conditional folder using the same `RandomVar` should contain the same files
 - All the values of the `RandomVar` should be mapped to a conditional folder (e.g. if you have `RandomVar:prelude:2` and there is only a conditional folder that looks for `Values=0`, this won't work)
@tangtang95
Copy link
Collaborator Author

I don't really like how it is written, so, if you think there is something better we can do, I am open to it

@tangtang95
Copy link
Collaborator Author

Maybe there is a better way to unlock the random variable. In here https://github.com/tsunamods-codes/7th-Heaven/blob/master/7thWrapperLib/VFile.cs#L299, we can save the CFolder that has been accessed and then at the end of the loop instead of returning, do a break and unlock all the random variables with a static function of RuntimeVar, but we need somehow to get the string RandomVar:{varName}:{size}:{deltaTime}

@julianxhokaxhiu julianxhokaxhiu added enhancement New feature or request priority/P2 only affects developers labels Dec 17, 2022
@julianxhokaxhiu julianxhokaxhiu added this to the 3.0.0 milestone Dec 17, 2022
Copy link
Member

@julianxhokaxhiu julianxhokaxhiu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The PR actually also in its current state LGTM.

I agree that we could unlock all vars the way you mentioned so it will be more natural, although it is also true that the dice will be for the single resolution. If that's the goal than it would make sense to add that ability, otherwise I'd stick with the deltaTime ( although this delta is very arbitrary, usually mods would need to roll a dice during the resolution moment and not afterwards, for eg. if my PC takes 5s to resolve a file, but the delta think it's ok to re-roll after 2s because during my own tests it took 1s to resolve, we already have a misleading behavior ).

So yeah, you could do IMHO one of the two things:

  • Remove deltaTime in favor of the overall unlock resolution OR
  • Stick with the deltaTime but accept it may bring some issues down the road

Up to you :) And thanks again for this fantastic patch!

@tangtang95
Copy link
Collaborator Author

The other unlock resolution is a substitute for the current unlock resolution which happens only if it is resolved as isActive.

I feel like the deltaTime is necessary because if a mod contains multiple textures (e.g. a 3d model with its various files) then at first texture file resolution it takes a file from one folder and then the second resolution it takes from another folder. So having a deltaTime bigger enough to load all those files would be enough.

I think the PR is fine by itself, but modders have to use it correctly. We do not have any parsing check on how it is used

@julianxhokaxhiu julianxhokaxhiu merged commit 1e5cd42 into tsunamods-codes:master Dec 17, 2022
@julianxhokaxhiu
Copy link
Member

Allright then, fine by me :) Thanks!

@tangtang95 tangtang95 deleted the feature/runtime-var-random-var branch January 7, 2023 10:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request priority/P2 only affects developers
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants