Chaotic vs. Random

[Legacy_Failed.Bard]

                 I played around with the include a bit more, adding a constant switch to allow selecting between the vanilla DB and the NWNX supported ones, and for naming the database used.

  I also added an initial framework for the surrounding plant distribution in the manner Rolo had mentioned.  It's not random at all, the number around the main tree is 4 + half the last digit of the WP count (giving 0 - 4), so while it might look random it'll spawn that number consistently.
  I still need to make up a better formula for the placement though, it's still far too even for my liking.  I knew that'd be an issue in the persistant versus dynamic beforehand though.

  At the moment the include is defaulted to the Bioware DB, which is ungodly slow for writing, and as I discovered, suffers the same bloat with integers as it does with strings if you delete the variable instead of just overwriting it.  This means I had to write a zero to every stored entry before writing the actual chain and stage, doubling an already slow process.
  It is more convenient for testing, however, since I don't have to use my server for it now.

  This link for it is the same as the one on the page before.
               
               

               
            

[Legacy_Rolo Kipp]

                <tossing loaded...>

1. My continuing thanks :-)

2. Instead of dropping the secondaries in fixed slots around the primary (which I *think* is what you're saying), How about using the GetChaosNumber( iSeed1, iSeed2, iRangeMin, iRangeMax, iCurve ) to get a bearing & distance offset. Simply increment the iSeed2 (or iteration count), so the iSeed1 would still be the node index, the iSeed2 would be the wp_veg index (or FOREST_WP)  plus number of the secondary being placed. Do it once for distance (in cm) and again for direction.

So placing a small tree (primary) with 3 ferns (secondaries) - (determined with iSeed1 & iSeed2, where iSeed1 is the node index and iSeed2 is the wp_veg index) - around it would (after placing the tree):

For each iNumSecondaries:

• Call GetChaosNum(iSeed1, (iSeed2+(iNumSecondary*2)), iDistanceMin=100, iDistanceMax=1000, iCurve=1) for the Distance (in cm) of Secondary(iNumSecondary)
• Call GetChaosNum(iSeed1, (iSeed2+(iNumSecondary*2)+1), iBearingMin=0, iBearingMax=360, iCurve=1) for the direction from the primary.

Edit: Alternately, divide the bearings around the primary by the number of secondaries, and limit each secondary to an arc, so they do not overlap by more than half (assuming two secondaries each dropped at the end of their range).

3. At the moment, I am (very) limited to an old R40 thinkpad. NwNx really isn't an option yet (until I either repair one of the junkers in my boneyard or acquire a multi-core machine :-P ). So please do keep the NwNdb option :-)

Does any of that make sense?

<...dice>
               
               

               

                     Modifié par Rolo Kipp, 28 décembre 2011 - 07:50 .
                     
                  

            

[Legacy_Failed.Bard]

                 Here's a quick demo video of the system at work.  It's set inside a trigger to allow for the spawn/despawn that happens to be more easily seen.  I'm using the nwnx DB for the demo, with the Bioware DB I get about a seconds worth of stutter at despawn when it makes all the DB writes.  For spawning in there isn't really a noticeable difference in performance.

  I'm happy wih the way it determines the number of surrounding sub-placeables, but distance and specific placement needs more variance.
 I think using a larger sized placeable for the surrounding plants would help disguise part of that, but since I'm making up the core systems just using vanilla placeables (aside from the final stage tree in the demo) that's not an option.
               
               

               
            

[Legacy_Lightfoot8]

               Just to throw in My 2 cents.    

@Rolo  The Chaos generator would still only need to be seeded once per script.   Once it was seeded the Area would spawn the same unless something changed.    

@Failed Bard,  I think the generator would still work,  The only thing that would really need to be stored into the DB that way is the placeables that where destroyed,  With the script just making a quick check if it need to be redrawn or skipped.  Even if skipped the Chaotic rolls would still need to be made for placement and type just so the Chaotic generator is not thrown out of secuence for the area.

In short the chaotic generator can be used just like a random number generator for placement of the sub placables.
               
               

               
            

[Legacy_Rolo Kipp]

               <repeating himself...>

Well, Im using the token "iSeed2" because "iIterations" is too long ;-P

The *Seed* is iSeed1, The number of iterations is iSeed2, then the min-max range and the curve/slope variable constant.  This way we not only get the right sequence of numbers, but have an index (iSeed2) *into* that sequence ;-)

Edit: Perhaps GetChaosNumber( iSeed, iIndex, iRangeMin, iRangeMax, iCurve ) is clearer? 
Edit2: or iCurve = iTightness = iSmushingTogetherConstant (or would that be "iSmooshing...") <stop it, boss>
Hehe... =)

<...ad naseum>
               
               

               

                     Modifié par Rolo Kipp, 28 décembre 2011 - 11:03 .
                     
                  

            

[Legacy_Rolo Kipp]

               <dancing with glee...>

Lightfoot8 wrote...
@Failed Bard,  I think the generator would still work,  The only thing that would really need to be stored into the DB that way is the placeables that where destroyed,  With the script just making a quick check if it need to be redrawn or skipped.  Even if skipped the Chaotic rolls would still need to be made for placement and type just so the Chaotic generator is not thrown out of secuence for the area.

Or... <dredging up an elusive thought from the organic mire at the bottom of his mind> ...the only thing that needs to be saved is the *state* of each WP.  If something is destroyed, it gets bumped back to -9 (bare earth) state and then has to grow all over again.  

This way, not only could lumberjacks (or peculiarly effective fireballs ;-) devastate whole forests, but the plants would regrow asynchronously. That is, the entire area may not be destroyed, only a portion of it.
Edit: And in truth, that state variable can be saved on the WP. No db needed. And if you increment the iIndex of the WP, then the new growth chain will almost certainly be different... that is, something else will grow on that spot.

Damn, my brain hurts, but I'm *really* liking where this is going (NPCs could go the same way... spawn NPC... gets stronger & smarter over time. PC shows up, kills it. When it respawns it is low-level. This would really forestall camping :-)

<...whose feet hurt>
               
               

               

                     Modifié par Rolo Kipp, 29 décembre 2011 - 12:10 .
                     
                  

            

[Legacy_Failed.Bard]

               

Rolo Kipp wrote...
...

Damn, my brain hurts, but I'm *really* liking where this is going (NPCs could go the same way... spawn NPC... gets stronger & smarter over time. PC shows up, kills it. When it respawns it is low-level. This would really forestall camping :-)

<...whose feet hurt>

  Prisoner of the Mists (at least used to, haven't played there in years) handles their spawn and treasure generation in this way.  The HD totals for the areas and GP totals for the chests would grow over time, if creatures were killed or chests looted when the area did the next "bump" upwards the new values would be reflective of what was still in the area.

  It's a good system, but very hard to balance the CR of the HD progression in the areas, as well as the rate at which a dungeon or area will grow to maximum.
  If the low spawn creatures in a high level area are good for low level characters to hunt, you get situations where a dungeon can't ever reach a maximum spawn.  They'll just repeatedly hunt that area since they don't have to wait for the areas CR to raise.
  The opposite end of that, is that if you have a small playerbase, all of the areas might be at high spawn all of the time, and too much for characters starting off, even in the "easy" areas.

  As I said at the start, it's a good system, but expect to be tweaking values for some time before you get a good balance.  I think PotM had to eventually go to a system that tied regrowth rates to player population to try and better balance it.