Chaotic vs. Random

[Legacy_Rolo Kipp]

               <with eyes shining...>

Failed.Bard wrote...
 I have an initial framework finished and working.  The growth routine is pretty crude at the moment (straight 1 in 10 chance if the regrowth local is set, determined at tree creation), but the initial random generation of the area works, as does the 2da system, and the database system to handle it.

Holy moly! You and LF are *fast*! That's even faster than the rumor system!

I might still pare the DB calls down, by combining the stage and chain stored ints into a single string (since it's stored as a string anyways), which will halve the read/write calls on creation and cleaning.

  Here's a chopped down snippet of the 2da, I've removed most of the columns for readability:
2DA v2.0

      Label                                       Stage1a                 Stage1b     <snip>     Stage10a            Stage10b        
0    EMPTY_NULL_FOREST     ****                          ****                              ****                       ****
1    TEMPERATE_FOREST_1   x3_plc_grass001 ****                              x3_plc_treel000 ****
2    TEMPERATE_FOREST_2   x3_plc_grass001 ****                              x3_plc_treel001 ****
... etc ....
  The actual trees are the last three steps, it's grass, then bushes, then trees in the five temperate forest chains I'd added.  Each chain in those five starts the same, but has a different final tree, stage 8 is small, 9 medium, 10 large.

Yes! Yes! That is very much where I was heading.

Caveat, though. Part of the purpose of using wps to spawn in placeables is to reduce the resources for *inactive* areas while *increasing* the resources in active areas.

Specifically, the 2DA chains (good word, that) actually specify a vegetation *group*. Each group must cover the footprint of the largest possible placeable (for forest, the Giant Tree, roughly 10m diameter). At low VegValue, placing a single grass placeable in an otherwise blank tile would be very patchwork-looking. So it works more along the lines of:

• Groundcover group - rosette of 7 placeables
• Groundcover w/ central bush - rosette
• Bushes - rosette of 3 small bushes around larger bush
• Saplings - rosette of large bushes (brush) with central sapling
• Small tree - rosette of 3 small bushes (still too open for ferns) around small tree
• Medium tree - rosette of 3 small ferns around medium (average) tree
• Large tree - Large ferns around large tree
• Huge tree - no extra groundcover
• Giant tree - rare occurance, nearly fills tile.

Climax forest would have quite a few Giant trees, hopefully generating a cathedral like atmosphere (planning to tie atmospheric effects into the dynamic states functions later).

Additionally, I'd like a range of various Veggy groups for each level, that is also chosen chaotically, rather than randomly. I.e. Any given wp_veg *may* progress toward oak tree or maple or whatever, but it will always progress to the given variant, as you've set up with your 2DA. A wp_veg would chose a certain chain and progress or regress along it with the state of the area. The only difference would be to make each stage a group of 1 to 7 placeables, rather than a single resref. Perhaps a "|" delimited string in each column? What are the a/b variations? Seasonal?

For seasonal variation, I am currently planning a modification of the Seasonal Trinity Tileset round robin of modules (Spring->Summer->Autumn->Winter->Back to spring). I chose to go this way for several reasons, one of which is providing seasonal variation to my creatures (white foxes & hares! The Crone becoming the Maiden! ;-) and seasonally distinct scripting. I also want my open water tiles to morph into hard ice tiles (have a certain location that can only be reached by walking on water. Or flying).

I'll upload the initial bit with the include and the base 2da once I've cleaned the code up a little.  It still needs work, but it's in a good enough state to take a look at.  The script can be spawned easily enough off an area or a trigger, the trigger being the easier of the two since you can walk in and out more easily, for checking the growth progression.

Fantastic! You are great! Thank you FB!

<...with shock and awe
               
               

               

                     Modifié par Rolo Kipp, 26 décembre 2011 - 07:21 .
                     
                  

            

[Legacy_Rolo Kipp]

               <nodding...>

Lightfoot8 wrote...
The First step is the creation of a seedable random number generator.  Since you like the word of chaotic for such a critter we will call it a Chaotic Generator,  I also added a High and Low range arguments for ease of use.

Yup, exactly! A Chaotic Number Generator. Provide a iSeed1,iSeed2, iLow, iHigh num and perhaps a curve slope value (i.e. the number of dice rolled?).

Given any set of variables, the CNG will always return a set integer in the range iLow<=result<=iHigh. Plotting the results for a large group of iSeed1 would yield a curve that is flat (iSlope=1) to increasingly steep.  Basically, I want the iLow & iHigh probabilities to be very rare.

iSeed1 (which would be the unique index of that particular node, a value of 1-64K)
iSeed2 (which would be the unique index of that particular wp_veg in that area, a value 1-255) might be the number of warm-up iterations of GenerateChaotic() in your example...
 

Assuming that the Generator is going to be used in a single script Per seeding and the Current postion does not need to be stored into a local.  This would be the Include for the Generator.

const int a = 16807; // 7^5  /// x^y is x to the y power in the comments.
const int c = 0;
const int m = 1073741823; // (2^30) -1
int rSeed;

int GenerateChaotic (int nHigh ,int nLow = 1 )
{
 *snip*
}
  

Giving the Generator a unique seed per script based on you request would not be that hard from here. 
...
int nSeed = (NodeIndex << + WpIndex;
SeedChaoticGenerator( nSeed);
...

But I don't really want a unique seed when called. I want the seed to be precisely the node index and the wp_veg index, so the value returned is the same *every* time I call it for that wp_veg at *that* particular node.

Example: Node 3141 (whose name just might be Pi's Zadora) might use template area 59 (which is actually named something like "tem_fffh_1ss0_3". Template 59 has a certain wp_veg with an index of 26.
*Every* time Node 3141 wakes up it will load template area 59.
Then it will work through all the wp_veg.
When it gets to wp_veg 26 it calls GenerateChaotic(3141, 26, -9, 9, 3) and returns... 7 perhaps.  
It will *always* return 7 for that wp_veg in that Node.
It will always return a different (allowing for the probability of repetition) number for that same wp_veg in *other* nodes (with a possible 64K nodes and a target of 100-200 templates, each template will "serve" hundreds of nodes).

To give the results a bell I would use the same trick used by just about every dice game out there(even though nwn missed the trick in most cases) .  Take a great sword for example. It does 2 to 12 damage.

Exactly! Except that the dice roll slope-variable is very coarse grained at small values, and I was sorta hoping a more mathematically insightful scripter would jump in, laugh at all of us (in a friendly, if superior way) and jot down one of those truly elegant one-line equations that makes us all say "Doh! I shoulda thought of that!"

But a value of 3 would actually give me the sort of steep slope I was looking for.

BTW, your pm idea for fractally generating the distribution is pretty interesting, too. I just don't like the precise placement (location) being algorythm. Too much chance for ugly groupings and border-of-tile drops. Not insurmountable challenges, but, for now, I think the seeded wp idea will be easier, quicker and (thanks to FB!) already implemented ;-)

Even though NWN handles this as a D6 *2...

<jaw drops in astonishment>
They *didn't*! Oh, *please* say you're joking? <looks rather completely disillusioned>

I... don't have anything to say about that. Nothing good.

...It really should be 2D6,  Making a roll of 7 the most common and 2 and 12 the hardest rolls to get, Just like the game of craps.     For your results however,   since it is hard to roll a 9.5 die to get the range you want,  I suggest just getting the average of two Chaotic numbers in the range you want for the same result.

int nResult = (GenerateChaotic(9,-9) + GenerateChaotic(9,-9)) / 2;  

If you wanted a function to controll the dx  of the bell It would not be that complex with this system.    It could however start burnning up the instruction count if you started getting to many itterations. *code snipped*

  
Yes, adding a slope (incline, dx) to the function, at least until we found a comfortable setting, would be good.

And that would make the function more generally available for *other* spawns, like carnivores, herbivores, citizens in cities... etc.

I hope that answers the original question.
L8.

Yup :-) Thank you very much :-)
               
               

               

                     Modifié par Rolo Kipp, 26 décembre 2011 - 08:03 .
                     
                  

            

[Legacy_Failed.Bard]

               

Rolo Kipp wrote...

<with eyes shining...>

Failed.Bard wrote...
...

Yes! Yes! That is very much where I was heading.

Caveat, though. Part of the purpose of using wps to spawn in placeables is to reduce the resources for *inactive* areas while *increasing* the resources in active areas.

Specifically, the 2DA chains (good word, that) actually specify a vegetation *group*. Each group must cover the footprint of the largest possible placeable (for forest, the Giant Tree, roughly 10m diameter). At low VegValue, placing a single grass placeable in an otherwise blank tile would be very patchwork-looking. So it works more along the lines of:

• Groundcover group - rosette of 7 placeables
• Groundcover w/ central bush - rosette
• Bushes - rosette of 3 small bushes around larger bush
• Saplings - rosette of large bushes (brush) with central sapling
• Small tree - rosette of 3 small bushes (still too open for ferns) around small tree
• Medium tree - rosette of 3 small ferns around medium (average) tree
• Large tree - Large ferns around large tree
• Huge tree - no extra groundcover
• Giant tree - rare occurance, nearly fills tile.

Climax forest would have quite a few Giant trees, hopefully generating a cathedral like atmosphere (planning to tie atmospheric effects into the dynamic states functions later).

Additionally, I'd like a range of various Veggy groups for each level, that is also chosen chaotically, rather than randomly. I.e. Any given wp_veg *may* progress toward oak tree or maple or whatever, but it will always progress to the given variant, as you've set up with your 2DA. A wp_veg would chose a certain chain and progress or regress along it with the state of the area. The only difference would be to make each stage a group of 1 to 7 placeables, rather than a single resref. Perhaps a "|" delimited string in each column? What are the a/b variations? Seasonal?

  The a and b aren't variations, it's for when it makes more sense to keep the plant from the stage before in addition to the one for the current stage.  A small tree growing out of the middle of the bush, for example.
  Since most of the stages in your idea seem to only have two different placeables, though with varying amounts of the secondary ones, that could likely be scripted in off of the current 2da reads.  a is the primary vegetation, b the secondary.

  The only issue I could see with this, is that the position of the secondaries could either be  persistant or dynamic, not both, unlike the main tree.  The only way to make them persistant without bloating the DB would be to have them all appear the same position relative to the main tree, which would be fine with one but might look bad once you apply it across every tree.
  The alternative to that, is to allow them to be a random distance and facing, within a certain range, for each of the sub trees, which would give the illusion of randomly sprouting around the main tree without being so vastly different as to be immediately obvious if a PC walks past it on multiple spawn.despawn instances.
 
  I'll take a look at the scripts and see how hard it would be to set it up that way.  The only immediate issue I can think of is if the main tree WP is slightly raised compared to the ground aroung it, that it might lead to floating plants.  Since there's no reliable check for ground level aside from porting a creature to that spot and getting their z axis, it'll make for a bit more work.
               
               

               
            

[Legacy_Rolo Kipp]

               <sipping rich hazelnut coffee...>

re primary/secondary: Brilliant! I love it.

re dynamic placing, I'd rather have it chaotic, vector being a chaotic function of iSeed1=wp_veg index and iSeed2 perhaps being the number of the secondary? So a seed from 1-6. Give it a flat slope=1 and that way the distance/direction and facing of each secondary would be chaotic, but persistent.

re floating plants: And I was floating so high...:-/

Not sure the extra instructions would be worth bringing them to ground, though.  Particularly for ground cover, as quite a lot of that seems to float anyway, to get the leaves/blossoms up around calf-level.

Don't placeables drop to the walkmesh? I know you can't spawn in a placeable up a mountainside, for example. Wouldn't the secondaries drop/pop up to the proper Z?

<...happily>
               
               

               
            

[Legacy_Rolo Kipp]

               <grinning slyly...>

Of course, there's no reason this system has to be limited to temperate forest... It would work equally as well for dynamic swamp, jungle, or alpine (mountain) tilesets.

It would work for deserts and undersea, as well. They'd just need their own 2DA with context sensitive chains (a very useful mechanic, IMO).

They'd even work for the Crystal Forest in the Underways... Though I imagine recovery times for disasters would be a problem. Takes quite a while to re-grow gem-quality "trees"... ;-)

Edit: I'll be working on the proof-of-concept Regional mod as soon as we wrap up our CCC contributions this month. I'll be trying out FB's work there (combined with my own and LFs contributions) and we'll see what happens.

<...at Cestus>
               
               

               

                     Modifié par Rolo Kipp, 26 décembre 2011 - 08:40 .
                     
                  

            

[Legacy_Lightfoot8]

               

Rolo Kipp wrote...

But I don't really want a unique seed when called. I want the seed to be precisely the node index and the wp_veg index, so the value returned is the same *every* time I call it for that wp_veg at *that* particular node.

Correct.  I Think you misread that part.  Or I explained it poorly.  The Function does not Give you a unique seed.   It take a unique seed(node index) to seed the chaotic generator.   The Generator then gives you a constant string of chaotic numbers.  

ie.

void main()
{
    nNodeIndex = GetNodeIndex(); // Your custom function.
   
    //Seed the generator with the seed..
    SeedChaoticGenerator(nNodeIndex);
   
    int x=1;
    int nRnd;
    object oWP  = GetNearestObjectByTag("WPTag");
    while (GetIsObjectValid(oWP))
    {
      nRnd = GenerateChaotic(9, -9);
      /*
          Code dealing with the result
      */
     oWP=GetNearestObjectByTag("WPTag",OBJECT_SELF,++x);
    }
}

Would have the same result for nNodeIndex every single time.  A different NodeIndex used for the seed would return a different set of consistant results for the random/chaotic numbers.    The Seed will not change when spawned unless the NodeIndex is changed.   Giving you  1,073,741,823   Differand seeds to choose from for consistant results. 

  
               
               

               

                     Modifié par Lightfoot8, 26 décembre 2011 - 09:04 .
                     
                  

            

[Legacy_Failed.Bard]

               

Rolo Kipp wrote...

<grinning slyly...>

Of course, there's no reason this system has to be limited to temperate forest... It would work equally as well for dynamic swamp, jungle, or alpine (mountain) tilesets.

It would work for deserts and undersea, as well. They'd just need their own 2DA with context sensitive chains (a very useful mechanic, IMO).

They'd even work for the Crystal Forest in the Underways... Though I imagine recovery times for disasters would be a problem. Takes quite a while to re-grow gem-quality "trees"... ;-)

Edit: I'll be working on the proof-of-concept Regional mod as soon as we wrap up our CCC contributions this month. I'll be trying out FB's work there (combined with my own and LFs contributions) and we'll see what happens.

<...at Cestus>

Other environments wouldn't need a seperate 2da, just seperate line entries in it.  The entires are read from the seed string as three digits, so rows 0 to 999 are viable under the current system.  I'd thought about using it for crystals as well, in addition to the possibility of controlling the size of snow and ice drifts and formations in perpetually frozen climates.
  There's no reason it wouldn't work for any sort of scaling placeable system.  For seasonal you'd just have to make it use a different set of lines depending on the season.

Edit: I was just thinking, I should be able to create a "random" placement of the sub-vegetation around the main tree based on the wp count that could be consistent every time as well, similar to Lightfoot8's system.  It would only change if another WP was added to the area and the engine created a new list in a different order when that happened.
               
               

               

                     Modifié par Failed.Bard, 26 décembre 2011 - 09:46 .
                     
                  

            

[Legacy_Rolo Kipp]

               <weighing a handful of scrolls in one hand...>

Failed.Bard wrote...
Other environments wouldn't need a seperate 2da, just seperate line entries in it. 

They wouldn't need it, no. But having a separate 2da for each tileset/purpose would make managing things easier, I think :-)

The entires are read from the seed string as three digits, so rows 0 to 999 are viable under the current system.  I'd thought about using it for crystals as well, in addition to the possibility of controlling the size of snow and ice drifts and formations in perpetually frozen climates.
  There's no reason it wouldn't work for any sort of scaling placeable system.

Yup :-) I'm quite excited, actually. 

For seasonal you'd just have to make it use a different set of lines depending on the season.

Or you could leave the seasonal aspect to the seasonal over-ride hak as I will. Same placeable resref, but new textures or even geometry for different seasons.

<...and eyeing a massive tome with one eye>
               
               

               
            

[Legacy_Rolo Kipp]

               <pours a little oil...>

Lightfoot8 wrote...
Correct.  I Think you misread that part.  Or I explained it poorly.  The Function does not Give you a unique seed.   It take a unique seed(node index) to seed the chaotic generator.   The Generator then gives you a constant string of chaotic numbers.  

Ahhh. Yes, I misread it.

I think this will work nicely :-)

<...on the waters>
               
               

               
            

[Legacy_Rolo Kipp]

               <looking quite interested...>

wyldhunt1 wrote...
We use NWNX Areas and NWNX ResMan, and NWN Funcs to add any content we want on the fly.
*snip*
This allows for true instancing, such as WoW style instanced dungeons, or unlimited template areas which have wide diversity while maintaining each individual areas map.

I think I understand better. *Very* intriguing.

I really do have to look into NwNX. Downloaded it and have it ready for investigation/experimentation... 

*sigh*

Soon, RSN...

<...but also too busy to pursue the elusive ideal>
               
               

               
            

[Legacy_wyldhunt1]

               Areas (Stable Windows Version)
http://www.nwnx.org/...opic.php?t=1705

Areas general info
http://www.nwnx.org/...opic.php?t=1244

ResMan info
http://www.nwnx.org/...topic.php?t=108

Funcs (Stable Windows Version) Note this is 'Funcs' not 'Functions'... Different plugins.
http://www.nwnx.org/...opic.php?t=1535

General download page
http://www.nwnx.org/index.php?id=nwnx2

If you want to play with it, there is the base to our magical instancing system. Read those threads and you'll understand how we can use them to create/edit/add/copy almost anything to our mod on the fly without having to re-boot the mod.
The only thing we can't do is alter anything that's in a client side hak.
               
               

               

                     Modifié par wyldhunt1, 26 décembre 2011 - 10:38 .
                     
                  

            

[Legacy_wyldhunt1]

               In fact, if you wanted to get crazy with it (This is more than we're planning to use in the release of Adelan), you could use LETO to alter the area files in your ResMan folder, and then make a copy of the modified area via NWNX Areas and create entirely custom areas on the fly through scripting. If someone was completely insane, they might even be able to come up with a user friendly interface to allow DM's to build new areas live In Game.

I'm probably not quite that crazy... But it's theoretically possible.

EDIT: Updated the leto link to the NWNX version
               
               

               

                     Modifié par wyldhunt1, 26 décembre 2011 - 11:18 .
                     
                  

            

[Legacy_Rolo Kipp]

               <raven nods...>

I *am* that crazy :-)

But I have to work up to it. In that direction will be the MOptimizer to optimize my haks and resource management and some sort of app (probably javascript, as I am least rusty in that) to paint regions and output the 2DA files they will need.

I've got some basics worked out for the MOptimizer based on Funky's great tutorial and some pseudo code for the Region Painter that will have to wait until I finish working out the transition and wakeup code (which this thread is in support of).

<...vigorously>
               
               

               
            

[Legacy_wyldhunt1]

               The main reason for mentioning it was that if you decide to set it up now, you can have most of your mod files in an external folder and have total control over them. This could be very useful for your transition script if you set it up properly now.
It sounds like you are going to be using the same area template multiple times and spawning different placeables in them to eliminate the repetativeness of the area.
Let's say that you have a very successful server. One day, 10 people are in 10 different areas. Each of those areas use the same template.
In order for that to work, you need 10 copies of every area in your mod, just in case this happens...
That makes your mod very very bloated.
If you take the time to set up a true instancing system, you only ever need a single copy of each template area. If a second is needed, it will be created on the fly. When/if you decide that it's no longer needed and you decide to free up resources, you just delete the entire new area(s) that you created. Your mod will load faster. It won't be anywhere near as laggy if there is only a single copy of every unused template area.
In adition to that, you can modify a lot of the area info when you create it. You have more control over the areas name and such.

So, contrary to appearances, I wasn't off topic. Your entire mod will benefit if you instance using those templates.
As far as the code goes, that ability to control the areas info when I create it is a big part ofwhat enabled me to not need random number generators. By the time the area shows up, it has all of the info (Name, tag, variables, etc) that a static area would have had if I had made it for that spot in the toolset. Then I just use the technique I mentioned above to lay out the placeables in a pattern that is specific to the templates location in the world so that it appears to be random to the players without ever needing a single random number generated.
               
               

               
            

[Legacy_Rolo Kipp]

                <looking a bit...>

Actually, I had a few ideas for handling multiple groups needing the templates at different nodes.

For one, the odds of a large number of parties all happening upon different nodes (out of thousands) that all need that one particular template (out of hundreds) are pretty small. Still, "template collision" is bound to happen. 

First line of defense would be to simply delay the entrance of the next party, perhaps with an optional encounter (i.e. they may work through an random encounter (*not* necessarily combat) or back off and find a different route around the blocked node. 

Then there's the shortcut method. If you know all the dozens of nodes between here and there, no need to walk through them all one at a time. Just jump to the destination (I've something a little tricky in mind for my "world map" system ;-).

Third, there's the pool of back-up templates variations that can be temporarily used (I.e. if there are 10 variations of the basic ffff_0000 template (forest all around, open borders) then I can substitute one in a pinch.

And, of course, I could have duplicates of the most heavily used templates...

Not withstanding all the above, I still do want to provide something like your instancing system. Specifically, I want to be able "create from within" (as a DM) and I also want to save decent areas generated using a combination of complex ("Complexity" is another grreat book, Lightfoot ;-) and chaotic systems. One of my longterm goals is to use a ton of spare cycles when the world is sleeping to *evolve* the world geographically, ecologically, economically and politically.  I want the world to be more valuable with age, the one currency that can not be hacked or forged.

And, as you can see from this post, I'm not terribly concerned about being on topic (for my own thread's sake, anyway) =)

Don't get me wrong, I want NwNx and 3rd party control/modification of my mods so bad I can taste it.  
But I also want to see what I can do, at least SP-wise, without any extra hoops for players to jump through.
Eventually, when I do start to bring the global systems together, I will have no choice but to break the server loose from the client, even for SP.  But for now I think we can still do an aweful lot with nearly vanilla NwN :-)

<...vague & dreamy>
               
               

               

                     Modifié par Rolo Kipp, 27 décembre 2011 - 01:43 .