Nested Table rolling problem

[wmljohn]

Is there a problem with nested tables in Unity? I use Rob2e's inspiration cards and players roll for one when they log on. The first time they roll no matter what level card they get the second table rolls a 1. If they do it a second time no matter what level card they get the nested table rolls an 18. I have attached screen shots to show it. I have heard of others who have been having the same issue.42726

[Drizzard]

I've also used these tables as a player and this issue does indeed exist.

[Kelrugem]

Do you use extensions? Then please test without extensions first :)

I ask because I just tested: I cannot reproduce this problem

When you can reproduce this problem without extensions, then please attach maybe a table with which someone could reproduce it, so, some steps of reproducing it would be useful :)

[Kelrugem]

Ah, wait, I see that you do not use physical dice for the second table. But also with that information I cannot reproduce it (I first got a 1, too, but after a reload of the campaign I did get a 20, not a 1; so, was just a coincidence)

[Kelrugem]

Oki, now I was able to reproduce it :D Sorry for the spam. The steps are:

1. Create a table with a non-physical die (in my case d24)
2. Roll on it, you get a 1
3. Close FGU and start the campaign again (not reloading the campaign)
4. Observe that you roll a 1 again on this table
5. Repeat 3. and 4. as often as you want :D

:)

[rob2e]

The problem occurs when a PLAYER specifically does it the first time. To test it you have to connect as a player and do it with the player table top not the DM table top. I know there are other nesred tables out there but I couldn’t off the top of my head think of any other one to test it with. But it has to be a programming issue within unity because the module that I have is just tables there’s nothing else in there that would do anything other than just roll on a table that rolls on another table.

[Kelrugem]

The problem occurs when a PLAYER specifically does it the first time. To test it you have to connect as a player and do it with the player table top not the DM table top. I know there are other nesred tables out there but I couldn’t off the top of my head think of any other one to test it with. But it has to be a programming issue within unity because the module that I have is just tables there’s nothing else in there that would do anything other than just roll on a table that rolls on another table.

I was already able to reproduce it, you can test it also as DM, important may be to just roll on the table and not anything else :) I have provided the steps to reproduce it easily above :)

It is probably not directly related to tables, but related to non-physical dice. As a workaround it probably works when rewriting the table using physical dice

(and as an afterthought, I believe this is a known bug; but I am not sure)

[Zacchaeus]

I can't reproduce this - unless I'm misunderstanding the issue.

[Kelrugem]

I can't reproduce this - unless I'm misunderstanding the issue.

You reproduced it: The first roll was a 1 trivially :D

The thing seems to be, that the first table roll with an unphysical die seems to be always a 1 :) Your test case just trivially reproduces it because it was a d1, hence, not obvious then :D (so, your first table already reproduced it because it uses an unphysical die, which is why the second table roll was not a 1, but by the initial post it might be that the second roll is also always the same, so, you might always get that combination after a complete restart) Maybe change the d1 to a physical die or to any other unphysical die (the nested stuff is not needed here in my opinion, it seems to be related to unphysical die table rolls)

Important, restart the campaign before you test this, with quitting FGU completely :) Looks like a seed problem related to the random tables of rollable tables

EDIT: My steps of reproducing it was just one table; so, the nesting is here not the problem, I think

[Zacchaeus]

Ok, gotcha.

[Engorgio]

Aye same issues for me and the players on my tables

[damned]

The issue is that math.random always uses the same seed. It needs to be initialised with a random seed the first time it is run.
math.randomseed(os.time())

[Kelrugem]

The issue is that math.random always uses the same seed. It needs to be initialised with a random seed the first time it is run.
math.randomseed(os.time())

Yes, I think Weissrolf reported that once for the /die macros :) But those got fixed, so, hopefully easy to fix for tables, too :)

[Moon Wizard]

There is apparently an issue in the Lua random seed setting. It doesn't affect non-standard dice randomly generated by client (which was fixed previously); and it doesn't show up in development environment either. However, the math.randomseed call is apparently not being respected in the Lua engine initialization when in non-dev mode; and we have a specific call in the code for that.

I'll need to investigate further to see if I can figure out why the Lua engine is not accepting the seed in non-dev mode.

Regards,
JPG

[EmptyOwl]

Hi,

I searched the forums to find if anyone else is having table rolling oddities and found this topic. I am not sure what is being discussed here is the same thing I am seeing, but I have this template I made to roll 6 encounter checks a day by watches. The tables are fairly complex and can call on multiple other tables and do not necessarily use "real" dice (like a table might have 61 entries so it uses a d61). I began to spot weird results like the same generated encounters for the day popping up time after time even though a given table had 100+ possible results and was one of over a dozen possible tables that could be rolled on. This behavior seems to cycle every 8-12 days and bring up the same exact generated template result when it does occur. I haven't really gone through each generated result to match them up over the 60-80 I have generated, but the one that stuck out and made me notice is an exact match every 8-12 days and has occurred at least 4 times (yeah, took me that long to make the connection).

I could just break out Tablesmith and dump these tables into that to make them work, but I am wondering if this is a known bug and/or related to what is being discussed here and what I can do about it.

Thanks!

[DCrumb]

As Moon Wizard posted, the game engine is not starting with a random seed such that any call for a random number (that isn't a physical die) will always come from the same "list" of random numbers. At this time, there is nothing we can do to change these results. Besides vision distance and light distance, this will probably be worked on fairly quickly once they find the difference between when they run it (dev mode), as opposed to when we run it (live mode).

[LordEntrails]

Hi,

I searched the forums to find if anyone else is having table rolling oddities and found this topic. I am not sure what is being discussed here is the same thing I am seeing, but I have this template I made to roll 6 encounter checks a day by watches. The tables are fairly complex and can call on multiple other tables and do not necessarily use "real" dice (like a table might have 61 entries so it uses a d61). I began to spot weird results like the same generated encounters for the day popping up time after time even though a given table had 100+ possible results and was one of over a dozen possible tables that could be rolled on. This behavior seems to cycle every 8-12 days and bring up the same exact generated template result when it does occur. I haven't really gone through each generated result to match them up over the 60-80 I have generated, but the one that stuck out and made me notice is an exact match every 8-12 days and has occurred at least 4 times (yeah, took me that long to make the connection).

I could just break out Tablesmith and dump these tables into that to make them work, but I am wondering if this is a known bug and/or related to what is being discussed here and what I can do about it.

Thanks!
It's the same bug. Hopefully will be resolved in the next build. No ETA yet.