levelCurve: Testing produces curious results

[Yama]

Please pardon me for asking what may be a stupid question, but here goes:

Code: Select all

<RandomItem count="3d6"
         criteria=      "aswd"
         level=         "4"
         levelCurve=      "3"
         damaged=      "100"
      />

My understanding of levelCurve is that the above code will randomly generate 3 to 18 damaged level 1 to 7 items, with the likelihood of a given item being of a particular level as follows:

• The chance of a level 1 or 7 item is equal and the lowest.
• The chance of a level 2 or 6 item is equal and greater than the chance of level 1 or 7 items.
• The chance of a level 3 or 5 items is equal and greater than the chance of level 2 or 6 items.
• The chance of a level 4 item is greater than the chance of level 3 or 5 items.

Therefore the distribution would typically graph the form of a rough bell curve.

But how does it work when the code is as follows?

Code: Select all

<RandomItem count="3d6"
         criteria=      "aswd"
         level=         "2"
         levelCurve=      "3"
         damaged=      "100"
      />

Let's say that the dice rolls from the '<RandomItem count="3d6" ' line add-up to 12. This would generate 12 items with levels theoretically ranging from "-2" to 5 (or "-1" to 5 if there was a level "0"). But of course there aren't any levels lower than level "1", so the left side of the "bell" gets truncated.

So what happens to the fraction of the called for 12 items (let's say 3 items) that would (were it possible) have generated as level "-1" or "-2" items?

• Do they simply not generate, resulting in the production of just 9 items, instead of the full 12 that the dice rolls called for?
• Do they all generate as level 1 items since that's the lowest level? That would result in the called for 12 items, but a disproportionate number of level 1 items (3 extra).
• Do the ones that draw as "-1" or "-2" just keep getting thrown back in the hat, to be drawn again 'til the result is a legal level number? That would result in the called for 12 items, with more or less "normal" distribution.

.... or some other possibility I haven't thought of?

[Drako Slyith]

I think that it picks the range first, then it makes the items within the valid range (so it just cuts off and ignores the negative and 0 levels)
then just makes items in that level. I am relatively sure it gets how many items of each level it needs (excluding the negative) then it just picks items randomly to see if it fits in to any of the levels.

[Yama]

Thanks Drako, but I guess I'm a little slow today; I don't quite understand your answer.

[Drako Slyith]

I may not have been very clear. I said that I think the game decides how many items of each level it needs, then it will randomly pick an item in the game, then see if it is in one of the levels that is needed.

[Yama]

I think I got it that time. Thank you again.

One brief additional question:

For testing purposes, can I substitute an integer for the dice algebra quantity in the

Code: Select all

<RandomItem count="3d6" 

line, so that it generates a fixed quantity of items every time?

[sdw195]

yes,

Code: Select all

<RandomItem count="100000"

should work just fine

[Yama]

I decided to do some in-game testing in an attempt to answer my own questions, and got some rather curious results.

I edited the Tinker mod I'm working on so it would only produce armor items (to make tallying the items by level easier), set level=4 and levelCurve=3 so it'd make level 1 to 7 segments and changing the dice algebra "count=" value to the integer "35". I started a new game with Drako's "The Network" extension (so I could jump from Eridani directly into a level 2 system) and soggydoggy's "Star Chart" (so I could instantly locate all the friendly stations when I got there). I saved the game and moved a copy of the savegame file in another directory, so I could keep jumping and reloading until a Tinker station spawned. I kept jumping until I'd visited three Tinker stations, recording the quantity of each level of segment the station had in stock on the spreadsheet below. Then edited my mod again, making level=2, then reloaded & jumped 'til I'd visited three more Tinker Stations, recording the results on the lower part of the spreadsheet.

My first surprise was that changing dice algebra "count=" value to the integer "35" did not result in the stations spawning with a stock of 35 armor segments every time. In fact, the quantity per station over six spawns varied from a low of 86 to a high of 100 segments per station. None of them even came close to the expected quantity of 35. I'm also puzzled by the distribution of the segments across the various levels, particularly the small number of level 1 segments produced when "level=" was set to 2. I realize that ~90 segments per station over only six spawns are too small numbers to expect things to average out to a normal curve, but I thought it'd come closer than that.

spreadsheet-1.jpg (89.26 KiB) Viewed 8300 times

[alterecco]

I would try to change the levelFrequency string of the Group to one that encompasses the entire curve. As it is now I think all items that are not level 1 and 2 are dropped at creation. So, a string "cccc ----- -----" should cover all items from level 1 to 5.

[Yama]

I would try to change the levelFrequency string of the Group to one that encompasses the entire curve. As it is now I think all items that are not level 1 and 2 are dropped at creation. So, a string "cccc ----- -----" should cover all items from level 1 to 5.

Thanks alterecco. I hadn't thought of that: Added that to my testing.

Testing continued:

Since the integer value for "count=", for some unknown reason, didn't work as expected, I tried a couple ways of tricking dice algebra into representing fixed values. The first was <RandomItem count="35d1" which should equal 35 every time (a one sided die can only roll 1, so 35 rolls will always add up to 35). I reloaded and jumped (as described in my last post) until I'd visited three Level 1 Tinker stations, recording the quantities of segments on the spreadsheet below. This again, like the integer value, didn't work as expected; the three stations got 82, 84, and 100 segments respectively (rather than the hoped for 35 each).

I took a final stab at fixed quantities (though with little actual hope by this time) using <RandomItem count="0d6+"50" (zero rolls of a six sided die always equals zero, plus fifty should always equal fifty), going with the larger "count=" value so that if the stations didn't spawn with fixed numbers of segments, I'd at least see if the quantities go up when the value is increased. I jumped and reloaded 'til I'd surveyed ten Level 1 stations, wanting a larger sample in order to get a more meaningful look at the item level distribution. The segment quantity per station ranged from a low of 98 to a high of 138 (see below).

Next I changed the "group levelFrequency string", per alterecco's suggestion, so that it would encompass all the possible levels allowed by the current "level" and "levelCurve" settings <Group levelFrequency="ccccc cc---">. As you can see it had no apparent impact on the quantity of segments per station or the level distribution of those segments.

Then it was time to test what happens when the levelCurve "runs off the end", so I changed the level setting to level="2". This of course would result in no Level 6 or 7 segments at any of the stations. I surveyed another ten Level 1 Tinker stations, changed the group levelFrequency string to "c---- -----" surveyed another ten, then changed the group levelFrequency string to "cc--- -----" and surveyed ten more.

In summary, the results answered questions I posed at the beginning of this thread. In addition, I found that even though it's possible to substitute a fixed integer value in place of the commonly used dice algebra value in the following bit of xml code...,

Code: Select all

<RandomItem count="3d6"
         criteria=      "aswd"
         level=         "4"
         levelCurve=      "3"
         damaged=      "100"
      />

..... when adding random items to a station, doing so still results in the addition of a random number of items, rather than a number of items equal to the integer value that you substituted. Plus, thanks to alterecco, I learned that while changes in the "group levelFrequency string" had little or no impact on the average quantity of items per station, they substantially affected the level of those items when the levelCurve runs off the end.

[Prophet]

When the engine picks 1 (one) item of armor (or anything), it will create a random number in the station according to the armor's NumberAppearing attribute, which is usually a dice range.

For example:
It selects 35 armor items that correspond to your criteria, multiplied by the results of numberAppearing of EACH of those items (average of 1d4 is 2.5) Therefore resulting in 35*2.5=87.5 actual items produced.

You can get around that by creating the items directly in some script rather than the station's <items> element. My method of choice is the <onCreate> event if you want fine tuned control of items.

<Events>
<OnCreate>
(enum {list of items you want} i (objAddItem gSource (itmCreate i 1)))
...>

[Yama]

When the engine picks 1 (one) item of armor (or anything), it will create a random number in the station according to the armor's NumberAppearing attribute, which is usually a dice range.

For example:
It selects 35 armor items that correspond to your criteria, multiplied by the results of numberAppearing of EACH of those items (average of 1d4 is 2.5) Therefore resulting in 35*2.5=87.5 actual items produced......

Thanks so much. Something that finally makes some sense!

So I guess this...

Code: Select all

<RandomItem count="10"
         criteria=      "a"
         level=         "5"
         levelCurve=      "3"
         damaged=      "100"
      />

...would result in ten different types of armor segments, rather than ten segments?

Or could the game pick a segment type more than once, resulting in less than ten different types of armor segments, but possibly more than four (the max that a 1d4 numberAppearing should allow) of the type of segment that was picked more than once? If I remember correctly, I was sometimes getting pretty large quantities of some of the segments that are more common at the level I was testing at.

.... You can get around that by creating the items directly in some script rather than the station's <items> element. My method of choice is the <onCreate> event if you want fine tuned control of items.

<Events>
<OnCreate>
(enum {list of items you want} i (objAddItem gSource (itmCreate i 1)))
...>

Could you recommend an existing mod that I can look at for an example of this type of script?

[alterecco]

Ahh, numberAppearing! That makes sense. Forgot about that one.

There would be a chance of it creating multiple versions of the same armor.

[Prophet]

Any mod that does have this script ( i cant think of any right now that were released) would be very complex so i threw this together:

Code: Select all

<Events>
  <OnCreate>
    (block theItem
      (for i 1 35  ;; run 35 times
        (setq theItem (itmCreateRandom "a" "ccccc")) ;; item selection criteria
        (objAddItem gSource theItem 1) ;; add the item to the station
      )
    )
  </OnCreate>
</Events>

Hope that helps

[Yama]

Any mod that does have this script ( i cant think of any right now that were released) would be very complex so i threw this together:

Code: Select all

<Events>
  <OnCreate>
    (block theItem
      (for i 1 35  ;; run 35 times
        (setq theItem (itmCreateRandom "a" "ccccc")) ;; item selection criteria
        (objAddItem gSource theItem 1) ;; add the item to the station
      )
    )
  </OnCreate>
</Events>

Hope that helps

Thanks Prophet!

I think I understand that snippet, and have some ideas as to how I may be able to incorporate the it into the mod I'm tinkering around with.

One question though: I understand that the "ccccc" means that the segments will be level 1 to 5 items, but are the chances of a level 1,2,3,4, or 5 segment being added to the station all the same, or is there something like levelCurve at work here?

[digdug]

"ccccc" has an equal probability for each level. (20% in this case)

levelCurve (as you demonstrated with your nice Excel spreadsheet) has a bell shaped curve distribution, not sure if it's a normal distribution, I will test it.