crusadingknight

My bad, writing overcomplicated, long-winded papers during the day makes me bad at explaining when I get home. Generally, a TTL of -1 means the system will shoot out all of the particles at once. In the RGBA settings, the min and max are the minimum and maximum rgba (measured from 0 to 1) at the time the particle is created; The rgba will be selected from between those values. (Likely the reason your cloud is becoming red is because the rgba values decay downwards by -0.02 by default, so while everything else is becoming less coloured, your red value is staying above 1.) Probably quicker for me to explain how the particle update system works: When a particle is created, it's red is chosen somewhere between the min and max r values. On each update, a value chosen from between the min and max dr is added to the red value, increasing or decreasing the redness of the particle. By default, the particles have no velocity or acceleration, so they aren't really moving, they're just fading out , which is why they fade more quickly or slowly depending on how you adjust the DMin/DMax settings.

Looking at the client code, the TTL isn't any sane value, just a countdown run each time the function is called, so the units for the TTL are minimum 10ms, and scales up based on load from there. A TTL of -1 means the system (in general, but not necessarily) doesn't continue to update or add particles anymore, so it's generally a one-off system. (The difference isn't visible in the particle editor, since it has to keep replaying the effect so the person editting it can get a good view.) EDIT: On a second note, the RGBA is working...

@Roja: I think any such editor would probably only be as useful to non-programmer as the current one, since there's only so much you can do by tweaking the rgba values/decay, velocity, acceleration, constraints etc. of existing effects. On the topic of the existing interface: Any suggestions to improve it? (I know the actual labels have to be improved.) It should probably be rewritten seperately from the map editor anyway, since it's current implementation is finicky a saving particles at best, and lacks precision (especially on acceleration, which is rather jerky right now.) The current particles also seem a bit in need of help, since only 20% of them seem to be rendering, (which is probably why they're so slow, too, with all of the extras we aren't seeing.)

Not to go too far off topic, but does anyone know why we load a squared constraint radius in particles.c, only to sqrt it for almost every comparison? Or why we calculate sqrt(2) in 2d_objects.c? (sqrt(2) being a constant which means about as much to me as 1.41421356.) Or even why calc_light_frustum calculates the distance (sqrt(x*x+y*y)) four times? None of which are really optimization problems, but given the way the same constants are recalculated several times, they might be maintainability problems. More back on the topic, there doesn't seem to be any use of the inverse square root in ELc yet, aside from normals_sse.h, which itself is used only by the disabled -DTERRAIN flag.

I like it... I *think* there may be a mark filtering patch, or maybe even merged into CVS at present, though nothing more complex then suffix/prefix filtering yet. You mean, as in a longer range teleport, hooked into the map for coordinates? That's quite a nice idea too, and can be implemented. I doubt any of those games actually compete directly with EL; With the features now leaning more towards event and community interaction, we're probably more competing with Second Life than anyone.

All the while remembering Wirth's Law. It probably isn't premature if it's dealing with particle systems. By the way, that was Knuth restating Hoare, and the quote actually is "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."

You know, that code is used in Quake3, Crystal Space, the Titan Engine, etc. If you want more info, take a look at http://www.lomont.org/Math/Papers/2003/InvSqrt.pdf

To save you some time when it comes to integration, the right hand bone (which I assume roja will use for animations? I could be wrong) is boneId 25, ie. float points[1024][3]; float x, y, z; CalSkeleton_GetBonePoints(CalModel_GetSkeleton(actor->calmodel), &points[0][0]); x = points[25][0]; y = points[25][1]; z = points[25][2];

I prefer the transform once, load many times over transform-on-load many times, especially given the quantity of documentation in the encyclopedia already. I doubt it makes much of a difference when the transform occurs, given there is only one client program (elc) loading the ELxml. In any case, the books dependency display I have right now has a sort of directory-style form: Dep1 Dep1_Dep1 Dep1_Dep1_Dep1 Dep1_Dep1_Dep2 Dep1_Dep2 Dep1_Dep3 Dep1_Dep3_Dep1 Dep2 Does that work for everyone, or can anyone suggest any improvements? Layout code isn't very hard to write, so it shouldn't be very hard to tweak it if anyone thinks of a more readable format.

Encylopedia Todo list: Misc. Errata fixes. - Gods, positions, corrections, updates, details. - Commit other posted corrections. Additions: - Description of special GUI features (Relocatable Quickbar, etc.) - Split Maps Window into continents.

The pointer marker->owner won't change. You have to either iterate for where marker->owner == &actor, or add a callback pointer to the actor structure, otherwise there is the possibility you could have undefined effects.

One note: if (!marker->owner) return; Means that stationary effects have to log an actor, and it also does not guarantee to check if the actor isn't there; A better solution is to check if any effects need to be removed whenever an actor is destroyed. Also, it contradicts the note that it will be NULL for stationary effects.

Not easy, it needs the widget it uses for text display rewritten, because my past attempts at making the notepad scroll were ugly hacks. Beyond that, to keep it from reparsing the buffer on each draw, the actual buffer code it uses might have to change. Also, the buttons are unaligned, due to the fact the buttons themselves have changed since I wrote it. However, the bug bluap reported is a new one, which shouldn't be caused by anything in the notepad. Could you possibly mention which widget function it's crashing in?

None of it matters now anyway, as it turns out from reading bug reports that the API I planned to use (Syck v0.60) doesn't support UTF-8 at all, so I'll have to use a semantics-based XML language; I'll now also need to code a way to build a table the same way the YAML API would have done, in order to process book dependencies.

Well, for comparison, we have following: * Such a thing in EL-XML, with links to sub-prerequisites manually added, and words manually centered on the page. * Such a thing as semantic XML * Two equivalent examples in YAML. These were the examples I compared to make my decision; I found that the YAML (which is a light markup language) requires less typing, and a minimum of lines while still being self-explanatory. I certainly see using a more readable and concise language as progress. <Page name="SomeBook"> <size>Small</size><color>yellow</color> <link x="2" y="2" ref="Books" title="Back"/> <link x="437" y="2" ref="Index" title="Index"/> <size>Big</size><color r="0" g="1" b="0"/> <Text x="74" y="2">The Eternal Lands Encyclopedia</Text> <nl/> <Text> BOOKS</Text><nl/> <Color>red</Color> <Text> SomeBook</Text><nl/><nl/> <Size>Medium</Size><color r="1" g="0.5" b="0"/> <Text> Blah</Text> <nlkx/> <Text> </Text> <color r="0.9" g="0.9" b="0.9"/> <nlkx/> <Text> Prerequisites:</Text><nl/> <Text> -<link ref="Prereq1" title="Prereq1"/></Text><nl/> <Text> -<link ref="Prereq1_Prereq" title="Prereq1_Prereq"/></Text><nl/> <Text> -<link ref="Prereq2" title="Prereq2"/></Text><nl/> <Text> -<link ref="Prereq2_Prereq1" title="Prereq2_Prereq1"/></Text><nl/> <Text> -<link ref="Prereq2_Prereq2" title="Prereq2_Prereq2"/></Text><nl/> <nl/> <Text> Cost: 1600 gold.</Text> <Text> Knowledge Points: 14000.</Text> <nl/><nl/> <color>yellow</color> <Text> </Text><link ref="Books" title="Back To Books Index"/> </Page> <Book name="SomeBook" cost="1600" points="14000"> <description>Blah</description> <Prerequisites> <Prereq name="Prereq1"/> <Prereq name="Prereq2"/> </Prerequisites> </Book> SomeBook: Description: Blah Prerequisites: - Prereq1 - Prereq2 Cost: 1600 Points: 14000 SomeBook: Description: Blah Prerequisites: [Prereq1, Prereq2] Cost: 1600 Points: 14000

Eww, XUL... If we were going for a customizable UI, I'd use a quick scripting language like Pawn, Squirrel or Lua... XUL tends to be much more verbose, and seems like overkill for something as simple as arranging buttons. In any case, using a scripting language, you can control what does what from within the script, instead of having to mess with adding client functionality and exposing it through XML. (WoW uses Lua for the UI, etc.) Anyway, I know the scripting route has very little overhead, as I built a minimal Pawn interpreter into the client maybe two years ago for the fun of it. (I tossed the code not long after, but it worked well enough.)

strcasestr, not strcasecmp. Bluap needs strcasestr, which isn't standard, while strcasecmp would be useless. Hence string_contains_substr(). (Well, technically strcasestr() is a standard, just not on windows.)

Quick recommendation: I'd rip out the fortune and story code. I've been meaning to for a while, but I've never gotten around to it. BTW, you can have commit access to the redknight project if you want it, as I hardly have the time to work with the bot on everything anymore. (Though, I still have some patches to make to it to fix a bunch of hackish parts of the code, including moving the config to proper CSV.) Also, I'm noticing you're using the old CONFIG_LISTS interface, and the weird player/guild config detection: You know, those HAVE been rewritten in cvs for about 4 months.

Still, players either move, or stay still - factoring in lagged positions is still better than ignoring them altogether (ie. one or two cycles which don't move is better than an infinite amount.)

I agree the pathfinder shouldn't use actor positions (the client only knows actor positions on a short range anyway), but the mapwalk function could take actor positions into account when selecting the next intermediate target. It does. Line 230, pathfinder.c, !pf_is_tile_occupied(pf_cur_tile->x, pf_cur_tile->y). (This only comes into play if we're less than 12 steps from the target, however, so maybe line 216 should actually read if (pf_cur_tile && !pf_is_tile_occupied(pf_cur_tile->x, pf_cur_tile->y)), so it will bail out to the block which finds a free square. And, of course, the initializer for the for loop became an else clause at line 226, so that we don't have to re-iterate over the list.) In any case, network latency vs. player inertia all told, player positions will likely be concurrent on the client and server most of the time.

Yeah, I've been meaning to get around to that for a while, something else to do on the next weekend (4 days off for me.) It's not too hard, but I'll have to patch the client (just make it display Index and Back links itself, instead of displaying them with XML), and then push the patch through the system before that will work.

I did wonder if there was a general function kind of module. If you want I'll move it. I can check the other function in case I can use that. I know get_string_occurance could probably work, but for it's probably pretty unoptimized for just testing for a substring, and I don't think it handles case insensitivity. I was just using it for the reasoning to move it to asc.c; Otherwise, it would probably get duplicated at a later date.

Only thing I can spot is that string_contains_substr (which is a lot like get_string_occurance) probably doesn't belong in mapwin.c, but rather in asc.c, or another utility source file.

The 'pole' is a light source, hence the lighting in the picture. Quick note: Is it just me, or are the shadows in the WoW picture projected from above, even though the lightsource is beside them? In any case, one of the main elements which makes the lighting look a little more spectral on EL is the fact that lightsources are scattered around maps, sometimes on posts (though, these unfortunately have no halos to make is obvious), while other time's it's over a house or such.

I played with particle effects a while ago - in their current form a burst system works quite well for this sort of thing. Of course, if it doesn't suit your needs, a new, controlled etc. system can be integrated easily enough.