[quote=“Basti50”]
Docs - errors
- The use of the terms “width” and “length” in the docs is confusing (“length” is ambiguous). It would be best to use width for the x direction, and height for the y direction.
But what happens to z? (that is if we’re not talking about image sizes in which case I agree) Sorry, I’m still not really thinking in terms of the z-level. (I can’t really see any good reason to use z-levels except in a large Dwarf-Fortress like map, but performance-wise that’s almost certainly a no-go.) Anyway, I really did stumble over this in one case, but maybe I was just being dense… Maybe mention in the docs that you’re using the terms width (x), length (y), and height (z)? - I believe that it is an error not to hammer into the reader’s head, over and over again, that the order of coordinates must be reversed for m_pos depending on whether you are declaring it or adding coordinates after the fact!
I’m still hoping to leave everything m_pos related to phrases, which align the coordinates in the (x, y, z) order so the end user doesn’t need to bust his/her head about it. I was joking around due to the fact that I spent quite a few minutes believing that the phrases didn’t work, simply because I forgot to reverse the terms. As a user, let me say that I prefer to declare the coordinates rather than assign them procedurally, so I’d still be defining m_pos directly in most cases. But obviously that doesn’t mean that it’s not a good idea to have phrases to do the work as well.
Docs - room for improvement
- The specification for m_figure does explain the extension_value and offset_coord properties better than the docs proper (which I complained about in an earlier post). It’s still not crystal clear…
It’s thankfully not that strict. Say you got a map figure with the coordinates {{0, 0, 0} {5, 0, 0} {10, 0, 0}} and the offset values {{0, 0} (→ valid for {0, 0, 0}) {1, 1} (→ valid for {5, 0, 0}) {1, 0} (→ valid for {10, 0, 0}) {5, 5} (→ valid for nothing)} I still don’t get it… No need to explain it to me here (I’m not using z-levels), but give some thought how to do it in the docs!
extension_value is strictly for stretching images (which I consider independent from the map figure’s actual ‘physical’ form). I definitely agree that this is an important distinction, and I’m glad you’ve implemented it.
Questions/Requests/Problems
- How does extension_value work? The specification says that it is an (x,y) measurement(vector, I guess?). However, by trial and error, I got an image that was 2 tiles wide and 1 tile high to print properly by using {{0, 1}} for the extension_value. Wouldn’t it be better for that to be specified using {{2, 1}}, i.e. 2 sectors wide in the x direction, and 1 high in the y direction?
They’re meant as additional height and width which get added during the drscimage phrase. Doing it the way you suggested would be more intuitive, I agree, but the program would have to subtract them by 1, which would make the code more costly, at least a little. I think I rather make this more clear in the docs. Yes, but why do the x and y seem to be reversed? That seems to be the opposite of what the specification text says? The docs, by the way, don’t seem to address this at all–you have to go to the specification to find it. - I’m actually thinking to add ‘auras’ to map figures in the traditional rpg fashion which would work as a portable field of effects that you can attach. That would be a great feature. But even just collision detection would be sweet.
- Further to that, do I have to use facing directions to reliably determine whether a multisector actor is going to collide with another actor?
There is at least the phrase ‘To decide whether (target - a mappable thing) is in map reach of (chaser - a mappable thing)’ which checks an object’s entire surroundings and not only a direction. The code is rather inefficient as of yet though. I will try to switch to a more mathematical approach which should go a bit faster. OK, thanks. I didn’t see anything that indicated that this phrase checked all sectors of the actor. - AI: The term “steps” seems to be used both for phrases that return/contain coordinates and for phrases that return offsets. Consider standardizing the terminology to make clear what kind of data is in each list.
Not sure where you see offset values in there. Offset values too are strictly for images, so they shouldn’t have any part in pathfinding. You probably mean the difference between steps & waypoints? I need to find a better terminology, true, once the AI gets out of its baby shoes. I was using “offset” in its general meaning, not specific to R&D’s terminology. (I.e., an offset is a delta value, not a direct specification of a location.) This snippet from the docs seems to be using a “step” directly as a location:while ai_steps of av_yourself is not empty: change step to calculate next step of av_yourself; move player on sector (x-coord of player - Entry 1 of step) and (y-coord of player - Entry 2 of step) in Lab;
Are there movement routines that take steps (as opposed to coordinates) as inputs, or does an author have to manually subtract the step from the actor’s current position in order to move?
[/quote]
Thanks for the performance notes. Glimmr bitmap fonts use very large lists (at least 3-4 thousand entries) and still get very good searching performance, but those are lists of a single dimension. I’m sure you’re right that it’s the nested lists that limit the performance (and of course, R&D is doing far more with its maps than the flat list in a bitmap font is doing!). In any case, there are always options for subdividing a map. I just wondered what was possible.
Thanks!