Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - chaos

Pages: [1] 2 3 ... 20
1
Code: [Select]
// This is a port of http://fossies.org/dox/gsl-1.16/gausszig_8c_source.html, is copyrighted 2005 Jochen Voss and 2014
// Matthew Sheahan, and is licensed under the terms of the GNU Public License verson 3 or optionally any later version
// of the GNU Public License.  No warranty is provided and all warranties whatsoever are disclaimed.

#define Ziggurat_Rightmost_Position     3.44428647676

nosave private float array ziggurat_wtab = ({
    1.62318314817e-08, 2.16291505214e-08, 2.54246305087e-08, 2.84579525938e-08,
    3.10340022482e-08, 3.33011726243e-08, 3.53439060345e-08, 3.72152672658e-08,
    3.8950989572e-08, 4.05763964764e-08, 4.21101548915e-08, 4.35664624904e-08,
    4.49563968336e-08, 4.62887864029e-08, 4.75707945735e-08, 4.88083237257e-08,
    5.00063025384e-08, 5.11688950428e-08, 5.22996558616e-08, 5.34016475624e-08,
    5.44775307871e-08, 5.55296344581e-08, 5.65600111659e-08, 5.75704813695e-08,
    5.85626690412e-08, 5.95380306862e-08, 6.04978791776e-08, 6.14434034901e-08,
    6.23756851626e-08, 6.32957121259e-08, 6.42043903937e-08, 6.51025540077e-08,
    6.59909735447e-08, 6.68703634341e-08, 6.77413882848e-08, 6.8604668381e-08,
    6.94607844804e-08, 7.03102820203e-08, 7.11536748229e-08, 7.1991448372e-08,
    7.2824062723e-08, 7.36519550992e-08, 7.44755422158e-08, 7.52952223703e-08,
    7.61113773308e-08, 7.69243740467e-08, 7.77345662086e-08, 7.85422956743e-08,
    7.93478937793e-08, 8.01516825471e-08, 8.09539758128e-08, 8.17550802699e-08,
    8.25552964535e-08, 8.33549196661e-08, 8.41542408569e-08, 8.49535474601e-08,
    8.57531242006e-08, 8.65532538723e-08, 8.73542180955e-08, 8.8156298059e-08,
    8.89597752521e-08, 8.97649321908e-08, 9.05720531451e-08, 9.138142487e-08,
    9.21933373471e-08, 9.30080845407e-08, 9.38259651738e-08, 9.46472835298e-08,
    9.54723502847e-08, 9.63014833769e-08, 9.71350089201e-08, 9.79732621669e-08,
    9.88165885297e-08, 9.96653446693e-08, 1.00519899658e-07, 1.0138063623e-07,
    1.02247952126e-07, 1.03122261554e-07, 1.04003996769e-07, 1.04893609795e-07,
    1.05791574313e-07, 1.06698387725e-07, 1.07614573423e-07, 1.08540683296e-07,
    1.09477300508e-07, 1.1042504257e-07, 1.11384564771e-07, 1.12356564007e-07,
    1.13341783071e-07, 1.14341015475e-07, 1.15355110887e-07, 1.16384981291e-07,
    1.17431607977e-07, 1.18496049514e-07, 1.19579450872e-07, 1.20683053909e-07,
    1.21808209468e-07, 1.2295639141e-07, 1.24129212952e-07, 1.25328445797e-07,
    1.26556042658e-07, 1.27814163916e-07, 1.29105209375e-07, 1.30431856341e-07,
    1.31797105598e-07, 1.3320433736e-07, 1.34657379914e-07, 1.36160594606e-07,
    1.37718982103e-07, 1.39338316679e-07, 1.41025317971e-07, 1.42787873535e-07,
    1.44635331499e-07, 1.4657889173e-07, 1.48632138436e-07, 1.50811780719e-07,
    1.53138707402e-07, 1.55639532047e-07, 1.58348931426e-07, 1.61313325908e-07,
    1.64596952856e-07, 1.68292495203e-07, 1.72541128694e-07, 1.77574279496e-07,
    1.83813550477e-07, 1.92166040885e-07, 2.05295471952e-07, 2.22600839893e-07,
});

nosave private float array ziggurat_ytab = ({
    1, 0.963598623011, 0.936280813353, 0.913041104253,
    0.892278506696, 0.873239356919, 0.855496407634, 0.838778928349,
    0.822902083699, 0.807732738234, 0.793171045519, 0.779139726505,
    0.765577436082, 0.752434456248, 0.739669787677, 0.727249120285,
    0.715143377413, 0.703327646455, 0.691780377035, 0.68048276891,
    0.669418297233, 0.65857233912, 0.647931876189, 0.637485254896,
    0.62722199145, 0.617132611532, 0.607208517467, 0.597441877296,
    0.587825531465, 0.578352913803, 0.569017984198, 0.559815170911,
    0.550739320877, 0.541785656682, 0.532949739145, 0.524227434628,
    0.515614886373, 0.507108489253, 0.498704867478, 0.490400854812,
    0.482193476986, 0.47407993601, 0.466057596125, 0.458123971214,
    0.450276713467, 0.442513603171, 0.434832539473, 0.427231532022,
    0.419708693379, 0.41226223212, 0.404890446548, 0.397591718955,
    0.390364510382, 0.383207355816, 0.376118859788, 0.369097692334,
    0.362142585282, 0.355252328834, 0.348425768415, 0.341661801776,
    0.334959376311, 0.328317486588, 0.321735172063, 0.31521151497,
    0.308745638367, 0.302336704338, 0.29598391232, 0.289686497571,
    0.283443729739, 0.27725491156, 0.271119377649, 0.265036493387,
    0.259005653912, 0.253026283183, 0.247097833139, 0.241219782932,
    0.235391638239, 0.229612930649, 0.223883217122, 0.218202079518,
    0.212569124201, 0.206983981709, 0.201446306496, 0.195955776745,
    0.190512094256, 0.185114984406, 0.179764196185, 0.174459502324,
    0.169200699492, 0.1639876086, 0.158820075195, 0.153697969964,
    0.148621189348, 0.143589656295, 0.138603321143, 0.133662162669,
    0.128766189309, 0.123915440582, 0.119109988745, 0.114349940703,
    0.10963544023, 0.104966670533, 0.100343857232, 0.0957672718266,
    0.0912372357329, 0.0867541250127, 0.082318375932, 0.0779304915295,
    0.0735910494266, 0.0693007111742, 0.065060233529, 0.0608704821745,
    0.056732448584, 0.05264727098, 0.0486162607163, 0.0446409359769,
    0.0407230655415, 0.0368647267386, 0.0330683839378, 0.0293369977411,
    0.0256741818288, 0.0220844372634, 0.0185735200577, 0.0151490552854,
    0.0118216532614, 0.00860719483079, 0.00553245272614, 0.00265435214565,
});

nosave private int array ziggurat_ktab = ({
    0, 12590644, 14272653, 14988939,
    15384584, 15635009, 15807561, 15933577,
    16029594, 16105155, 16166147, 16216399,
    16258508, 16294295, 16325078, 16351831,
    16375291, 16396026, 16414479, 16431002,
    16445880, 16459343, 16471578, 16482744,
    16492970, 16502368, 16511031, 16519039,
    16526459, 16533352, 16539769, 16545755,
    16551348, 16556584, 16561493, 16566101,
    16570433, 16574511, 16578353, 16581977,
    16585398, 16588629, 16591685, 16594575,
    16597311, 16599901, 16602354, 16604679,
    16606881, 16608968, 16610945, 16612818,
    16614592, 16616272, 16617861, 16619363,
    16620782, 16622121, 16623383, 16624570,
    16625685, 16626730, 16627708, 16628619,
    16629465, 16630248, 16630969, 16631628,
    16632228, 16632768, 16633248, 16633671,
    16634034, 16634340, 16634586, 16634774,
    16634903, 16634972, 16634980, 16634926,
    16634810, 16634628, 16634381, 16634066,
    16633680, 16633222, 16632688, 16632075,
    16631380, 16630598, 16629726, 16628757,
    16627686, 16626507, 16625212, 16623794,
    16622243, 16620548, 16618698, 16616679,
    16614476, 16612071, 16609444, 16606571,
    16603425, 16599973, 16596178, 16591995,
    16587369, 16582237, 16576520, 16570120,
    16562917, 16554758, 16545450, 16534739,
    16522287, 16507638, 16490152, 16468907,
    16442518, 16408804, 16364095, 16301683,
    16207738, 16047994, 15704248, 15472926,
});

varargs float gaussian_number(float stddev) {
    float x, y;
    int sign;
    stddev ||= 1.0;
    for(;;) {
        int k1 = random(__INT_MAX__) + __INT_MIN__;
        int k2 = random(__INT_MAX__) + __INT_MIN__;
        int i = (k1 & 0xff);
        int j = (k2 & 0x00ffffff);
        sign = (i & 0x80) ? 1 : -1;
        i &= 0x7f;
        x = j * ziggurat_wtab[i];
        if(j < ziggurat_ktab[i])
            break;
        if(i < 127) {
            float y0 = ziggurat_ytab[i];
            float y1 = ziggurat_ytab[i + 1];
            float u1 = (random(__INT_MAX__) + __INT_MIN__) / to_float(__INT_MAX__);
            y = y1 + (y0 - y1) * u1;
        } else {
            float u1 = 1.0 - ((random(__INT_MAX__) + __INT_MIN__) / to_float(__INT_MAX__));
            float u2 = (random(__INT_MAX__) + __INT_MIN__) / to_float(__INT_MAX__);
            x = Ziggurat_Rightmost_Position - log(u1) / Ziggurat_Rightmost_Position;
            y = exp(-Ziggurat_Rightmost_Position * (x - 0.5 * Ziggurat_Rightmost_Position)) * u2;
        }
        if(y < exp(-0.5 * x * x))
            break;
    }
    return sign * stddev * x;
}

2
General / Heap fragmentation & you
« on: April 16, 2014, 01:13:11 PM »
FYI, if you're running an LPMud and operations seem to be getting inexplicably slower, with intermittent bursts of extreme slowness, you might be running into something that dogged me for a long time before I realized what it was: heap fragmentation.

Basically, your memory allocation is taking too long, sometimes way too long, because your free lists (the data structures that track what memory is available to be allocated) are full of wee little chunks and you're sometimes searching through enormous numbers of them to find a chunk of memory you can use.  So you get operations that were fast yesterday suddenly taking forever, and then not taking forever the next time you run them, and similar glorious debugging joys.

The fastest, most effective way to inflict horrific heap fragmentation on oneself that I've found is to quickly allocate enormous numbers of data structures, and immediately deallocate most of them but not all of them.  Intensive graph search in high combinatoric complexity spaces works great for this; what changed on Lost Souls that made me realize what was going on was a new system for procedural generation of descriptions and configurations for combinations of damage types.

Having realized what was up, and that we had been having the problem for a while without it getting bad enough to be properly identified until this new system was deployed, I was able to quickly get enormous performance benefits by 1) making said new system cache its final results to disk so the graph search didn't need to be recapitulated all the time, and 2) reducing the core lib's reliance on intermediate data structures, by which I mean arrays and mappings that are quickly used and discarded, usually for passing function results around.  Retaining and reusing, rather than reallocating, frequently used data structures, along with strategic use of returning complex results via pass by reference instead of data structure, seems to have quickly and dramatically reduced LS's vulnerability to heap fragmentation.  So I thought I'd pass along the information in case anybody else runs into the problem.

(Honestly, most people running LPMuds probably don't need to worry about the issue at all.  It's mostly really memory-intensive ones that would.  Lost Souls is, as far as I know, the only MUD to discover that things go horribly wrong with 32-bit LDMud's LPC parser if you try to address more than 2 gigabytes of memory.  If your MUD fits in a couple hundred megabytes, you'll be fine.)

3
Discworld Discussion / Re: Distlib, distlib, wherefore art thou distlib?
« on: December 28, 2013, 05:50:52 PM »
"Wherefore" means "why". HTH, HAND.

4
Promotions / Re: Call for articles for Imaginary Realities volume 6 issue 1
« on: December 24, 2013, 12:24:09 PM »
Chaos, it sounds good, maybe a little background of its place would help newer coders?
That sounds like a good idea.  Imaginary Realities is the (as far as I ever saw) one and only MUD community webzine, originally from more than a decade ago.  The old content is mirrored a couple places, like http://imaginary-realities.disinterest.org/.  It's for people to write about anything vaguely related to mudding, and has had a lot of great stuff in it over the years.

5
Promotions / Call for articles for Imaginary Realities volume 6 issue 1
« on: December 22, 2013, 04:32:25 PM »
So, against all odds, Imaginary Realities has been resurrected!  We have our first issue of new content out, and are looking for articles for the second.

If you'd like to contribute, please take a look at our guide to the topics we're looking to have covered, and email Richard Tew, richard.m.tew@gmail.com, to verify that your topic is a good fit.  Articles should be in the range of 1000-4000 words, and need to be received by January 31st, 2014. Longer articles are possible for serialisation, with approval required.

6
Drivers / Re: FluffOS 3.0-alpha7.4
« on: November 07, 2013, 08:31:08 PM »
The virtual-time smoothing mechanism that Wodan describes is basically why my MUD's performance improved dramatically when I introduced a lib-level mechanism for requesting interval callbacks (a la JavaScript setInterval) that are implemented via heart_beat() and whose handling philosophy is best-effort rather than guaranteed-N-calls-over-N/interval-seconds.  The more heavily your lib uses call_outs, the more it becomes a superb mechanism for generating uncontrollable self-similar lag spikes.

7
Lost Souls has ranged weapons.  Actually, technically almost any object is a ranged weapon because you can throw arbitrary things.  There are also bows, crossbows, wands and whatnot.  Quixadhal is correct that it's pretty much bollocks.

8
Drivers / Re: Long standing bug in FluffOS
« on: September 04, 2013, 08:06:36 PM »
And there's also the position that the current behavior is perfectly internally consistent and quite useful if one approaches the system in the mode of understanding it, rather than judging it for how it didn't meet one's preconceptions.

9
Code Vault / Re: A* Search Algorithm
« on: August 30, 2013, 07:54:36 PM »
This is available on Github now too: https://github.com/chaosprime/lpc-astar

The current version uses standard graph theory terminology (nodes and edges) instead of completely random-ass nomenclature of my own specification.

10
Drivers / Re: FluffOS website (for real)
« on: August 09, 2013, 02:40:09 PM »
Earth Force, PSI-Core, isnt that a bit 1995 ?
Your MUD is a bit 1995.

(they all are)

11
Drivers / Re: Parse error on new homepage for Fluffos
« on: August 09, 2013, 01:52:33 PM »
Compile on MORDEN linux distros, 32bit & 64bit, CYGWIN support.

---

I assume it should be MODERN with the r letter in a different position.
Oh, that's no fun.

"my tea told me to kill you"

12
Design Lab / Re: Virtual Wilderness (again)
« on: August 07, 2013, 07:25:09 AM »
Yeah, I have the distance landmark thing going on.  It basically scans the world out to a distance determined by the maximum visibility distance set by any terrain type and draws lines to see if there are any obstructions, then performs some very rough aggregation by terrain type and tries to describe that.  Slightly more complex output example, from ~Cimbra/rms/m_24_8_0:

Quote
    a forest of evergreens with a paved road [compass, compass:up, u, road:e/w]

    A dense mat of fallen needles forms the majority of the forest floor.  Large evergreen trees grow in proliferation, creating a haven of safety from the cold winds that blow through the region from the north.  A paved road has been constructed here to ease travel between important areas.  It bears signs of considerable use, with shallow paths worn to either side from the many feet that have tread upon it.  Small tufts of grass have begun to grow over the road.  The air is thick with the scent of pine and fir.  Above is empty air.  Northward, southward, eastward, and westward is the evergreen forest.  Far to the south and above, southeast and above, and southwest and above stands a mountain range.  The area is reasonably well-lit.  The road continues eastward and westward. 

    Above you is a still, heavily clouded night sky.  The moon is not visible. 

    Obvious exits lead in all compass directions and their upward variations, as well as up.

The road is an example of an "overlay".  Overlays are secondary map features whose configuration is merged with that of the base terrain types they affect.

The part relevant to what you were saying is "Far to the south and above, southeast and above, and southwest and above stands a mountain range."  You're only seeing it to the south and above because there's forest in between you and the mountain range and it's obscuring the view of the parts of it that are straight south of you.

Speaking of modes of visualization, something else this facilitates is views like this one, which is from that same position and presently available only through a magic item called a panoramicon:

Quote
+++++++++++++++++++++++++++++
+                           +
+ tttttttttttt-ttttttttt-tt +
+ tttttttttt--tttttttttt-tt +
+ ttttttttt-ttttttttttt-ttt +
+ ttttttt--ttttttttttt-tttt +
+ ttttt--ttttttttttttt-tttt +
+ tttt-tttttttttttttt-ttttt +
+ tt--ttttttttttttttt-ttttt +
+ t-tttttttttttttttt-tttttt +
+ -tttttttttttttttt-ttttttt +
+ ttttttttttttttttt-ttttttt +
+ tttttttttttttttt-tttttttt +
+ tttttttttttttttt-ttttteee +
+ ttttttttttt-@---ttteeeeee +
+ tt---------tttttteeeeeeee +
+ --ttttttttttttteeeeeeeeee +
+ tttttttttttttteeeeeeeeeee +
+ tttttttttttteeeeeeeeeeeee +
+ ttttttttttteeeeeeeeeeeeee +
+ tttttttttteeeeeeeeeeeeeee +
+ ttttttttteeeeeeeeeeeeeeee +
+ tttttttteeeeeeeeeeeeeeeee +
+ ttttttteeeeeeeeeeeeeeeeee +
+ ttttttteeeeeeeeeeeeeeeeee +
+ tttttteeeeeeeeeeeeeeee... +
+ ttttteeeeeeeeeeeeeee...tt +
+                           +
+++++++++++++++++++++++++++++

If you're wondering why in the world somebody decided to make the mountains "e", well, so I am I.

13
Design Lab / Re: Virtual Wilderness (again)
« on: August 05, 2013, 10:20:58 PM »
The "overland map" on Lost Souls (which is a collection of 20 3D maps, each 81x81x11), and various other areas, are handled through a mechanism something like what you describe.  A typical filename format is /d/Project/Subproject/rms/m_x_y_z (aka Project_Room("m_x_y_z") in our project accessibility macro convention), for example /d/Almeria/Cimbra/rms/m_12_-31_1, at which the description looks like:

Quote
     a forest of trees and shrubs [compass, compass:up, u]

   A thick layer of leaves forms the forest floor.  Large trees grow in proliferation, with branches of evergreen needles mingling freely with broad-leafed deciduous branches.  The air smells crisp, and heavy with the scent of pine, cedar, and maple.  Above is empty air.  Northward, southward, eastward, and westward is a mixed forest.  The area is reasonably well-lit. 

    Above you is a slowly moving, heavily clouded night sky.  A breeze blows around you.  The moon is not visible. 

    Obvious exits lead in all compass directions and their upward variations, as well as up.

The terrain is configured, not procedural, and in the case of the general world map at least it really should have been procedural.  There is no height map; everything is just defined by coordinate.  (Which supports things like the area Corpore Scyros, which is a dead god's skull floating in an extraplanar void; height mapping not helpful.)  A partial config file for a smaller area (11x11x5) looks like:

Code: [Select]
<X> 5
<Y> 5
<Z> 2

<SpecifyArea 2>
'''''''''''     
'''''''''''     
'''''''''''     
'''''''''''     
'''''''''''     
'''''''''''     
'''''''''''     
'''''''''''     
'''''''''''   
'''''''''''   
'''''''''''   
</SpecifyArea>

<SpecifyArea 1>
'''''''''''     
'++''''''''     
'''''''''''     
'''''''''''     
'''''''''''     
'''''''''''     
'''''''''''     
'''''''''''     
'''''''''''   
'''''''''''   
'''''''''''   
</SpecifyArea>

<SpecifyArea 0>
...........
.||***...*.
....%T%....
...%TTT%...
..%TTTTT%..
...%oooo%..
.......oo%.
........o%.
.......oo%.
..%%%ooo...
...........
</SpecifyArea>

<SpecifyArea -1>
~~~~~~~~~~~
~#####~~~#~
~~~~###~~~~
~~~#####~~~
~~#######~~
~~~######~~
~~~~~~~###~
~~~~~~~~##~
~~~~~~~###~
~~######~~~
~~~~~~~~~~~
</SpecifyArea>

<SpecifyArea -2>
___________
_#####___#_
____###____
___##ccc___
__##cc###__
___#c####__
_______###_
________##_
_______###_
__######___
___________
</SpecifyArea>

The significance of the terrain type specification characters is configured by terrain definition objects attached to the project.

There's no attempt to write out .c files for generated rooms; as matters stand, that would cause a lot of pain, since writing a .c file is how you create a "custom" room that deviates from the map-generated configuration.  Nor is there an attempt to avoid empty air or underground rooms.

As matters stand, the mechanism is clunky, memory-abusive and insufficiently mutable for my purposes moving forward.  (I require a fully dynamically deformable world, dunno 'bout y'all.)

There's a severe limitation in how much MUDs can draw from "voxel games" like Minecraft because of the requirement that we linguistically describe things.  In Minecraft, if you see a bunch of voxels stacked like this:

Code: [Select]
  ___
 /   \
/_____\
| o o |
|     |
|  H  |

your brain does the work of supplying the description "house".  It's completely impractical to ask a MUD engine to look at a bunch of dynamically deformable voxels and construct "house" out of them, or "mountain range" or "forest".  So in order to get my requirements, I think I'm going to have to have polygons, not voxels, which is a whole area of development that I loathe and am profoundly inexpert with, unfortunately.

14
Drivers / Re: Long standing bug in FluffOS
« on: August 04, 2013, 07:10:51 PM »
And just how many places do you really think most mudlibs are going to fail if variables are suddenly initialized to the logical and correct type of data they were declared to be?
Having suffered through porting a complex mudlib from a driver version that initialized floats to 0 to one where floats were initialized to 0.0, I can confidently say "a lot".

15
Drivers / Re: Long standing bug in FluffOS
« on: July 27, 2013, 07:35:40 PM »
I think we've had this conversation before, and I still think it's nonsense, but it doesn't matter.  Maybe we should have had different type semantics that more closely tied together static and dynamic typing, but we didn't, and then people went and wrote a bunch of code using the language they had.  Not only throwing compat busters at them by now implementing that closer tying together of static and dynamic typing, but then telling them the compat busters are their fault for having written to the language they had instead of pretending they had a different language that more closely met your expectations?  Poor behavior.

Pages: [1] 2 3 ... 20