#@Stexinator, not sure if this is an
1 messages ยท Page 1 of 1 (latest)
I need more details to make a guess
https://github.com/smilligan93/SR5-FoundryVTT/pull/841 this is a branch to fix some issues with the importer. Maybe your errors are present there
I was thinking I had to wait for the player to send me the json. but remembered I have a copy of the chummer file. So here is the json export, and what the foundry data had on export from foundry
Some how the matrix init was 1, and unless something changed in 14.1 on all new actors when I tried to use my control rig effect macro it was giving me string concatnation and not int math
in the chummer json?
the player did have vehicles box checked since it is a rigger. So not sure if that had anything to do with it
I know that the chummer export is not exactly what they used as I just regrabbed it this morning from my copy of the chummer file
Makes no difference for me. The vehicles are created parallel to the update of the actor. In really weird cases on a slow machine this could do bad things. But thats like 1 in a million
hmm, when the player gets online and sends me a copy of the json they copied I will send it over as well as try an import myself to see if it repeats or if some how they messed up the copy paste
Can you create a bunch of new actors and import him multiple times to check if the issue sticks?
I just tested it and it did the same thing. What is really weird is that the sheet shows the correct value and rolls correctly, but the value field is still wrong
check the value field of the one you imported and see if it shows value 1 for base
And this time it is only on the mestspace init base not both
.
init base not init dice
I can modify my scripts to only look at init.(type).base.base instead of base.value. I did it for base.value so that it would grab the modified value instead.
what about meatspace?
I did a second import and the first one had meatspace.base.value as 1 while matrix.base.value was 10 and the second they flipped with meatspace.base.value being 11 and matrix.base.value being 1
Here is the original json. although it looks fairly similar at first glance
@twilit badger as far as I can see now base values are imported. I guess value is calculated on attributes and base is value + modifier?
.value is always the result and what is used. .base should be used for the initial value. So an attribute rating should be stored in .base and .value is what's supposed to be used after modifiers.
That is what I thought, so what would cause value to be different when there are no modifiers listed?
My first guess would be an effect using override on the .value
But if it's persistent over new actors without any effects I can't say
That foundry actor has a base of 1 for matrix ini. Is that the same actor that gives you a .base of 10 like in that screenshot?
That is from a brand new character with a brand new import. never touched the character
All of the ones I have shared are from the same json file used for import. Each time it loads in differently. I did it 3 or 4 different times with different results
I have the same behavior on 0.14.1 as stexinator...
Currently all initiative .base values are always recalculated on the fly based on attributes. So it doesn't matter what matrix.base.base is, it will be intuition + data processing.
And for me it gives the correct Matrix Initiative Base of 10 (base.value) . ๐ค
what did meatspace give. I noticed it bouncing back and forth on them
11 on the sheet
now I am curious if some module is somehow causing this
testing that should be easy and would be my next step
it did it on my clean dev world too
uh....
That is a brand new world and it did it
If you create a new actor and set it up to have the same data processing + intuition. What happens? I'm checking if it's actually related to that character being imported or not
One moment
same thing on the made character. could it be related to the matrix device being an RCC?
Shouldn't be, since it's only different in it's type.
Also I checked and it doesn't happen if the matrix device used is an RCC
it really feels like an override is applying somewhere
This points to me to some local difference. I double checked my game world and it works there for me too... I'm out of ideas for the moment.
There is a way to check Foundry effect overrides
Let me check how it worked
What is weird for me is that this is happening both my live instance which is hosted on a linux server and my dev which is on my personal windows pc
The only simularity is my product key, and version of foundry and sr5 of course
Foundry sets up the actor.override object showing all effect results. You can check if that's empty (as it should be with no effects applied)
However, the system normally removes Foundry handling of the overwrite change mode and handles it differently (it creates an .overwrite object like in the screenshot) So even if there were one, it should have shown in your system data shots...
yea, nothing there
At the moment I'm out of ideas, as your game world should not include any local changes to the system JavaScript...
I decided to check other characters. and I am seeing it else where as well
And for some it is meatspace.base.value and for others it is matrix.base.value
What is weird though is that when in game, initiative rolls correctly reguardless
That is weird...
I found the cause, and this is weird handling
take a character and see what the init values of each are. Then change them from meat to matrix or matrix to meat (flip from what they are currently) and check again.
The one not selected will have a value of 1
So the issue is not what is shown on the sheet but is in the systems data of the ini base that's been selected last?
yea, it has always been what is in the systems data
I found this from my control rig macro pulling weird numbers for init
Aaaah, I see. I can reproduce it
Okay
Sooo
Only the currently selected ini base is actually calculated (.value)
All others only have their base calculated (.base)
๐
that is good to know. suprised it rewrites the value field of the object to 1 though.
I guess an edit to my macro is in order to where I will need to calculate the matrix value manually incase the character has meatspace selected (since effects have to be reapplied to update with effect macro)
Wouldn't be an issue to actually calcualte all matrix base and dice values (haven't checked for dice)
it appears to do the same for dice as well
only updating the calculation when selected should have been fine. It changing the uncalculated to 1 is the weird part to me
The system doesn't store derived values, it recalculates always. So whatever is in the raw actor json will be used if nothing is changed
oh... I thought the value field was not a floating variable field on the object. I thought it was static unless told to change
For most values it doesn't make a difference. In this case no one expected an inactive initiative to be used ๐
to be honest, if I could make the effect update in real time with the new values of the driver I would do that and just make them switch to matrix to get the init passed over to the drone and use the drones if not set. But I do not know of a way to do that currently
I'll gladly change that behavior, as it should be inconsequential otherwise: https://github.com/smilligan93/SR5-FoundryVTT/issues/855
And of little effort
That works for me. I know with how the system is as a whole, the right answer would be to eventually have dynamic effects. But I suspect that would be either a large code change on your end or I make a hell of a module on my end
not to say I don't look into the later....
by system I mean SR rules
Dynamic effects as in the change value refers to some actor/item value instead of a flat value?
correct
oh... sweet
that would also solve the issue, I am willing to make small tweak to my macro until then
I'll give you a test build of it this weekend as well
It's still in the prototype phase and subject to change
reminds me, I need to reset up my dev environment and learn how to set it up for module making as well. (forgot to just update my local git when moving to 0.14 on my dev while testing a macro)