36 réponses à ce sujet

[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 .

[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 .

[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>

[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.

[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 .

[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.

[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 .

[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.

[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.

[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 .

[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 .

[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.