That should work, yeah. Especially now that I found out that you can use ‘next’ and ‘break’ in a while loop. The algorithm just needs to get redone first. I’ll get down to it tonight.
I think I fixed it now. New example here. Should work for every platform (or abort the loop beforehand if it doesn’t). Word of warning though, at least to Windows 7 users: turns out that, if you open a gblorb over ‘Open with’ for either Glulx or Git, it will not call for the current file but some buffered data instead, apparently. In my case, it calls for the old file which prints “First, second,…” etc. although that file is long gone. 
@Erik
You were right that again something seems off with the resizing factor. Probably has something to do with the new full-map parameters. Will try to work on that.
This one works! I suspect the problem was line endings in the text editor you used to create the import file…
That’s good to hear!
Windows 7 and Mac OS not playing nice with each other? Who would have thunk it, right? 
Glad that this is out of the way though.
I’ve got just one more general question: It recently came to my attention that arrays will probably get included in a later Inform 7 release. Would it be a good idea to switch over to those instead of lists? (For faster performance or other advantages)
Uhm, another question just popped up. There seems to be a limit to the amount of text an indexed text can actually store. I just tried to create a very large map in a text file, but the indexed text will only store about half of it. Would there be a possibility to extend this limit somehow?
There shouldn’t be a limit, but you might be running into Inform Bug 587. What happens if you apply the fix in the bug report’s comments to IndexedText.i6t, which is in your Inform install? (While you’re at it, you might as well apply the fix for Bug 593 too.)
And that’s another problem removed from this world. Cheers, mate!
Personally, I wouldn’t wait. It will probably be at least a couple of months before I7 arrays are available; there are still many, many bug reports to be resolved before a new version of the software can be released. The performance you’re getting currently isn’t bad, and there’s no guarantee that it will be better using arrays.
Also, I haven’t seen any specs for I7 arrays, but I would bet that they are intended to be static rather than dynamic. If that’s so, lists are also more flexible: they can be created on the fly (allowing you to load maps from external files, for example), or change their size dynamically. (Whether multidimensional arrays will be included in I7 is another question–I believe you would need those for what you’re doing.)
Waiting means a serious loss of momentum for little clear gain. If you do some testing once the new version is released and you find that arrays will work better, revise at that time. But for now, you’ve got a project that’s at least 85% done, and you may as well complete it!
–Erik
@Basti: I want to get back in and give you some of the sort of beta feedback that you requested in your original post. Mostly on the docs (which I looked at over the Xmas holiday but somehow lost all my notes), but also on a couple of other points.
Interrelationship with Glimmr
Having looked over the thread and the extension docs again, I’m not sure that it is user-friendly to include the Glimmr Image Font extension in the main extension. Only a small subset of users are likely to want to use this, but the inclusion of the font will add a hefty number of kilobytes (400 or 500) to every blorb file. Maybe you might consider releasing the image font as a display layer extension? Or include it in the documentation with a paste button, so that users can include it only if they want to?
More generally, would it be possible to structure R&D so that it didn’t require Glimmr at all? If a user wants only to create a text-grid map, for example, then the full Glimmr isn’t really necessary. (Ditto if they just want to use R&D for coordinate-based movement, without any display layer at all…)
AI - split out or not?
Splitting out the AI into its own extension is probably OK–it’s a very simple division and not likely to confuse users–but I also don’t think that it’s a problem to leave it in the main extension. Removing the Glimmr Image Font requirement seems more important from the standpoint of keeping users happy 
Coordinates
I don’t understand why you changed the coordinate ordering for m_pos to (z,y,x). This seems like it is bound to create confusion, especially when there are statements like this in the docs: “IMPORTANT: The actual line-up of a set [for m_pos] is (z, y, x) and NOT (x, y, z), as the phrases would imply”. Also, I don’t know if it’s is a typo or if the m_origin phrase really returns (x,y,z) instead of (z,y,x), but that’s what the docs say: “m_origin of (t - a mappable thing) - Returns the origin in the (x, y, z) arrangement”. Is there a good reason for using two coordinate orderings…?
The documentation is pretty comprehensible sentence-to-sentence. However, I think it would be more effective with (1) more big-picture conceptual overviews, as well as with (2) more detailed explanations of specific things.
Conceptual overviews: R&D is big and complex, and the docs don’t do much at all to give the reader an idea of the big picture, of how all the components work together, and what kind of work the author will be doing. How many “layers” of abstraction are there? What can I do with each layer? For example, it seems that the internal storage of the map is (almost?) totally abstracted from the display layer. That’s important, because it suggests that I could use R&D to implement a room-less IF, where all movement was based on coordinates rather than rooms, and never even show a map with it at all. (Pretty cool!)
Similarly, in making clear what the structure is and what R&D offers, it would be useful to make it clear what the author will need to do to use it. In other words, is R&D a minimal or a maximal implementation? For example, if I use R&D, do I have to code my own movement routines, or is that built in? (If I type NORTH when a map is displayed, will the avatar of the player automatically be moved north, or do I have to program that behavior myself?)
More detailed explanation of specifics: R&D is complex and does many things in not-very-Informy ways. This isn’t necessarily a bad thing–R&D is dealing with very different types of data from standard Inform–but it does mean that the intuitions of most Inform programmers will be confounded. As I was reading each section of R&D, I was left with many questions. I could usually work things out by studying the in-doc examplets and the main examples, but ideally I wouldn’t need to study these things to understand how each piece fits in. For example, right off the bat it would be nice if there were a description of how map data is stored, and possibly an explanation of why the author isn’t allowed to write data directly to that structure. As I mentioned above, I lost all of the notest that I made a couple of weeks ago, but I include the below as an example of the kinds of questions that hit me when I read the section on map avatars. Hopefully, this will be helpful…
[rant]It’s not clear from the docs whether m_actor and m_figure are two different things, or precisely how the two relate. Is an m_figure a separate object, a property of an m_actor…?
Make it more clear exactly how map actors work, and how the author can make something a map actor. For example, the suggested addition (in caps) to this sentence from the docs would help: “To decide whether something can or cannot be placed on a map, R&D makes the distinction between things and so called ‘mappable’ things. TO MAKE A THING MAPPABLE, SIMPLY DECLARE AN M_ACTOR FOR IT, E.G. THE M_ACTOR OF JILL IS AV_JILL.”
The m_pos definition is hard to wrap your head around: “A map actor’s current position which can contain any amount of coordinate sets.”…“A map actor can be enlarged by adding more coordinate sets”…“we can also remove existing coordinate sets from map actors”. I’d recommend adding a more complete explanation. Are these absolute coordinates or relative ones? Why am I adding them? What does “enlarge” mean in this context? What does adding more coordinates do? What happens precisely when I remove coordinates?
The img_ref list of coordinates could also use with a more explicit description. Does this list always have to include 8 numbers? If I don’t want to use facing images, do I have to repeat the same image reference 8 times? Also, what if I want facing images for up and down, or even in and out? How would I add those?
What does the “map alter” phrase do? Is this how I’m supposed to change the img_ref after the fact?
The offset_coord property is confusing. The definition says “Will modify the position of the graphic in relation to the map actor’s position. Each entry signals a change in the z-coordinate”. But the example immediately below shows the offset_coord as { { -1, -1 } }, which looks like an (x,y) pair–how is the z-coordinate involved? Is it something to do with having multiple pairs, e.g. { {-1, -1}, {0, 0} }. If so, how does that work?
All this is ditto for the extension_value, whose definition is “works similar to offset_coord, only that here, the graphic of a map actor is extended in width and length per added z-coordinate”, yet also seems in practice to be an x,y pair rather than a z…
And now I really don’t understand why the coordinate for m_pos is (z,y,x), when elsewhere we seem to have (x,y)…?
The m_effect definition is totally opaque to me: “m_effect - A list that saves the current ‘partially’ true (entry 1), true (entry 2) and true (without repetition) (entry 3) environmental effects for a map actor”. What are these? It sounds like this is just a summary of the environmental effects that impinge on the actor–i.e., that they are not something that the author sets manually, but are automatically set by R&D. But what do partially true, true, and true w/o repetition mean? Do I as the author need to do anything with this at all? If so, how would I get at it?[/rant]
R&D looks extremely powerful, and I think that it could lead to a number of different types of innovations in IF games. I hope you hear from a few more people about this public beta.
–Erik
I’m running out of options to express how thankful I’m for your continuous effort to help me out in this, so all I’ve got left to say is that u r a real bro (and while we’re at it, I got to add that I also really envy you for your working ethics. Seriously, man, if I would have only half that drive, this extension would have been out ages ago)
Ok, enough with the soft-soaping, let’s have a go at it.
You mean that stuff is optional? checks the docs again … I could have sworn there was an i.e., instead of an e.g. standing there. Big whoopsie! from me 
That would be a possibility and it would cut compiling time, probably to no small margin. I could make map-displays a kind of thing and simply add the image-map to it as a component, if need be. It would add another layer of abstraction and hence wouldn’t be as neatly tied together than just using image-maps, but still, should be doable.
I want to add waypoints and such to map figures directly instead of relying on a special kind (after all, a player can switch characters at any given moment, hence you can never be certain when something might need to be controlled by the computer). The split up is there to avoid redundant data which might be never used (plus I count every bit of code I can legally cut out of R&D’s main bulk as something positive )
Sorting. That’s the short answer. Having the z-coordinate at the start makes it easier for something like a map-display to decide whether or not it and a given object share the same z-level. If the z-coordinate would be placed at the end, it would be all over the place, thus the borders would be a lot harder to track down. As for why y before x, remember when I somewhere mentioned that I would like to be able to create objects which would be built up like a ‘+’ or similar? The coordinates for that would be (ignoring the z-coordinate) {0, 0} {1, -1} {1, 0} {1, 1} {2, 0}, if the x-coordinate would have been placed first, {1, -1} would stand in front of the origin coordinate and all kinds of ugly stuff would happen since it is presumed that the origin always has the first spot. There’s maybe a way to have more control over the sorting algorithm for such lists, but if so then I didn’t discover it. At least I’ve modified the code in such a way that later readjustments should be easily possible by changing just a few decide phrases, instead of going through the entire code again. Having said that, I’m not really happy with how coordinates are organized now. I have that idea spinning around in my head to make the individual coordinates merge into several ‘edges’ (like north-edges, west-edges, maybe a ‘body’ for all the coordinates which can’t be assigned to any existing edge and don’t form an edge themselves), instead of piling them up in one big bulk. This should make deciding scopes and such a lot less resource hungry, since R&D would no longer run through all individual coordinates anymore. Something to ponder on for another release maybe.
m_pos really returns the coordinates in the (x, y, z) arrangement btw. Seeing as all the phrases use this arrangement as well, this seemed like the most intuitive way to handle it. There is also a phrase which returns the origin in its original form but that one is only used internally so I didn’t mention it.
Before I continue on with the documentation, there is one thing I want to discuss a bit further. Correct me if I’m wrong, but I get the impression that you would prefer the docs to be an in-depth manual, in other words, something to explain what a thing is, not just what it does. This is not what I’m shooting for, or even what I believe a documentation for an extension should be. I think those are actually better off as a minimal and, hopefully, educational as well as motivating introduction to an extension’s functionality. That is, what the author would actually use in the end, not what R&D does internally to achieve what s/he wants, which would only be important for people who plan to modify the extension itself. I think the specifications are a better place to explain the later without making the documentation too overblown with information. Anything to get you moving asap without getting entangled in exhausting details. I can make the PDF for it later after all, if R&D should ever gain enough interest 
.
Taking the GCBD documentation as a negative example, when I skimmed over it, I was actually so intimidated by what I felt to be a very verbose style that I decided to skip right over to the code and learn the ropes from there. Something that shouldn’t happen when reading a documentation. Hence when I was sitting down working on my own docs, I wanted to try some different things for R&D: shorter paragraphs which built around a strictly need-to-know basis for a given topic, two sentence allegories which should, ideally, give you a good idea what the different components do and confining to a learning-by-doing approach over the quick examples, which always worked best for me at least, your mileage may vary.
I hope you don’t take this the wrong way, it was just my (admittedly very brief) personal experience with the GCBD documentation. It also doesn’t negate any of your criticism so I will still have to address that too 
What I hear out of it generally is that a) this documentation really needs an introduction chapter or at least a section and b) those parts of R&D which are strictly for internal use need to be better obscured to avoid confusion and abundance of details.
There are only two layers to a map (least the ones you should care about): storage and (possibly) graphical. The graphical layer is dependent on the storage layer but not the other way around and doesn’t need to be included. A room-less IF would therefore be possible (or at least almost, since a map itself is a kind of room).
Minimal implementation. R&D tries really hard to not get into your way as long as you don’t want it to (by not allowing people to run through walls for example). At its core, R&D is just a manager for a lot of lists within lists. It doesn’t tamper with any of the standard rules, giving the author more freedom but also a lack of standardized behaviour (although the later examples should cover most of the basics when it comes to movement at least). Some parts of R&D itself are still pretty much hardwired but I’m working on that.
That’s one of those questions I would consider as being on a too low technical level to be immediately interesting, or even required, for the average Joe author to know. Again I would claim that the specifications are a much better place to seeks answers in such a situation.
Need to call it quits tonight, but I will get back to this as soon as I’m able.
Hell no! (Waiting for arrays that is) I do want to get done somewhere in the near future
Well, I was just referring to the possibility of conditional compilation: if the author has also included Glimmr, then include a certain block of code; if she hasn’t, then include that other one instead. I assume that the layer of abstraction needed is pretty much already there, since you must have at least three different drawing routines right now: graphics, text, and the newer “faked” image text. But I haven’t studied the code, so I don’t know exactly how you have it organized.
Thanks. This is going to be confusing for users, so give the documentation of it some thought.
I don’t think that’s what I’m suggesting at all, to be honest. I think that by the time I’ve read the first couple of paragraphs of the docs, I should have some idea of what the extension can do, why I’d want to use it, and the basic concepts I need to understand in order to progress. When I say I want big-picture information, I am referring to the minimum I need to understand what your extension is and how I can use it.
Exactly. (Of course, when an extension has R&D’s complexity–and I think that it beats most extensions out there on the complexity scale!–minimal isn’t likely to actually mean short.)
Well, I’m not suggesting that you have to explain every aspect of R&D’s internal workings, obviously. The storage of map data is really the only example I can think of where as a user I definitely would want to have at least some idea of what R&D is doing under the hood. See my response to that issue below.
On another tack, R&D requires authors to do a lot of work on their own to even begin to use it. For example, I will need to create my own movement routines to move my characters around the map. But there’s nothing in the docs about that as a topic in itself. So a realistic appraisal of what I as an author might need to do to use R&D, and perhaps the very basic formula for doing it, should be addressed (shouldn’t it–?)
I hope that other people provide you with opinions about this as well, but here’s my experience: The shorter paragraphs didn’t always tell me what I wanted to know, and generally didn’t tell me how what I was reading about fit in with what I had read in earlier section. After reading some (not all) sections, I was puzzled as to what I would use data-access phrases for, or just how data was to be stored in the properties that were presented to me:
[rant]For example, from the graphics chapter: the type property (at least I think it’s a property, the docs don’t say what it is): “type - Hints at the creator of the graphic, may it be 1: a tilecell, 2: the user or 3: an object”. I honestly still don’t have a clue what that means, or how I’m meant to use it.[/rant]
I found that I had to jump back and forth between the code descriptions and the short bits of sample code to understand what each piece was doing and how the data was organized.
Not at all, it’s certainly a legitimate reaction. I definitely don’t claim that the Glimmr docs are the paragon of extension documentation; they were very painful to write and I’ve never felt very good about them. Your reaction to GCBD is disappointing, though, since those docs are laid out in a fashion that I hoped would make them easier to approach, and in more or less exactly the way you are describing. The first section (3 paragraphs) describes basic concepts needed to approach GCBD, followed by a step-by-step, no-frills description of how you set up a GCBD project. Everything else in the long extension docs are intended to be visited on an ad hoc, need-to-know basis: the following section describes each type of graphic element in turn and explains how to specify it–you don’t need to look at any part of this at all unless you learned from the introduction above that you want to work with, say, sprites. Finally, there’s a reference section that lists all of the properties of every element and is useful for reference once you’re an intermediate user (I refer to this myself, whereas I don’t use any other part of the docs). So part of your problem may have been in trying to approach it all as must-read stuff, when only a very small percentage of it is actually that. (Or it may be that I just didn’t do a very good job presenting the information–certainly a possibility!)
(a) definitely, (b) maybe, but (c) is key: context for understanding what I’m doing when. Not all of the docs are problematic in this way (the first section is fine for example), but the farther in I got, the harder I had to work to understand things. The section on graphics was very tough (also how they differ with tilecells), and I’ve already laid out the issues with understanding what’s going on with avatars.
I know the answers to these, I was just trying to indicate what the reader might want to know before diving in too deeply.
I don’t agree, as I said above. My first idea for R&D is to set the entire game on a single, very large map (since you say that the map display can show a window into a much larger map). But I have no interest in defining my very large map using the placement phrases you provided. (I was considering randomly generating a mountainous landscape, sliced into z-levels ala Dwarf Fortress, and importing that into the given structure.) The representation of space is the key element of the extension, and I am certain that I am not the only the person who would want to specify it using other methods than you’ve provided. So it seems courteous to at least describe it, rather than send me diving into the 28,000-word(!) code of the extension without any way to know what I might be looking for.
Oh, I don’t need responses to all those specific questions/comments; I’d prefer that you work on R&D! I just wanted to give you my input. Hope it proves helpful.
–Erik
I wanted to make clear–since my previous posts probably haven’t–that the changes I’m suggesting for the docs are on the surgical level. A sentence or two here or there will probably serve to impart missing critical information and provide needed context. I am not suggesting that the docs are hopeless or that you need to start over or anything like that!
Edited to add: I was just looking through the R&D source code and noticed that you put more complete explanations of many object kinds in their index specifications. That must have been what you were referring to when you said that you had put a lot of focus on specification text (I thought you were referring to the brief explanations of properties that you gave in the documentation itself). That’s cool. I don’t know if it’s a useful data point, but as a user I don’t tend to look in the index first for that sort of information. The index is a last resort for me.
So, I created my first map with R&D last night. Not much more complicated than Cyberspace, but it was a test nonetheless. The process was quite simple, and much easier than last time I tried (a few months ago)–that is probably due to the presence of documentation, but it might also be due to changes in the extension itself, I’m not sure. I never managed to get a compilable file the first time, but I was up in minutes this round. If any of you out there are interested in exploring roguelike/CRPG-IF hybridization, I recommend that you take a look. You can get started quickly by grabbing the tile images from the Glimmr Canvas-Based Drawing example “Roguelike-like” (available in the assets folder from the Glimmr full release download). No excuses remain!
Basti, below are some reactions, requests, questions, etc. I’ve spoilered because there are too many really long posts in this thread!
[spoiler]One thing I found while testing is that I would really like to be able to define all of my tilecells with a single table. I think it would be faster, as well as cleaner and easier to read. However, if I do that, I will not be able to use the predefined tilecell subkinds (t_floor, t_wall, etc.), since you can’t specify subkinds in a table. Would I lose anything by doing that? (Obviously, I would manually assign the appropriate default environmental effects, such as ee_block for walls, to my custom tilecells. But are there other benefits to using the built-in kinds?)
I wonder if the “fit” phrase could be made optional? I tried removing the “fit” phrase from my example, but it looked like every tile was sized to about 2 x 2 pixels (i.e. way too small). I feel like it shouldn’t be necessary to do a fit for every map display, that R&D should have some other way of determining the desired tile-width and tile-height. If something like the fit-phrase is required, would it be possible to set the tile-width directly rather than having to set the width of the full map-display?
How would I go about animating the image displayed for an m_actor? The naive approach would just be to change the img_ref for every tick of a timer. Is that in fact the best approach? (I’m not sure if animation is even practical from a performance standpoint, but it might be fun to try.)
I didn’t realize until I was testing this that the m_room is actually a subkind of room. The docs just say that an m_room is a “world” or “map” that we paint to. Is the use of the room class just a convenience for folks that want to include one map per room? Or does it have other implications, like a map won’t display unless the player has actually moved into the m_room?
What do you think about eliminating the built-up-rule? It seems to me that since you’re using an activity for generating the map, it would be easier for the author to just write an after rule to do anything that would currently be done in the built-up-rule. This would be more flexible, since you could have rules that fire for all maps, only certain maps, or specific maps. For example:
After map generating an m_room:
After map generating a dungeon m_room:
After map generating the torture chamber:
I notice that the order in which you have defined the direction names for the facing directions and the img_ref doesn’t match the internal Inform ordering. This probably isn’t a big deal, but it would be easier to loop over the directions and make assignments if they did match. The internal ordering is:
[rant]north
northeast
northwest
south
southeast
southwest
east
west
up
down
inside
outside[/rant][/spoiler]
On a different topic, I wonder if it would be possible to improve performance by including a phrase that would provide direct storage of a map, as opposed to using phrases in-game to build the map. For example, right now, we need to first run the map generating activity, then use various placement phrases to add features to the map one by one. That takes processing time while the game is running. You could potentially provide a phrase that the author could run once. This phrase would output the (probably not human-readable) source code needed to define the map without the activity or phrases–in other words, a direct representation of the storage. The author could then replace the procedural code in the game file with the “flattened” version. This would save all of the time needed to build the map procedurally while the game is actually running.
I’m looking forward to messing around a bit more with R&D in the next couple of days.
It looks like this isn’t possible currently, because the def_floor and def_wall don’t accept any tilecell, only the restrictive t_floor and t_wall subkinds. Any chance that you would be able to change the definition of def_floor etc. so that they accept any tilecell instead of just a certain subkind?
A m_room has a tilecell called def_floor.
A m_room has a tilecell called def_border.
A m_room has a tilecell called def_wall.
That’s a real goldmine, thank you!
I still want to talk a bit more about the documentation when I find the time, but for now, I think we’re better off discussing the points in your last post. I’ve got some ideas and explanations to throw around.
Amen to that!
This is still one of R&D’s many construction zones where I’ve got no clear idea where I’m heading. You usually don’t need to bother with t_floors and the like, if you don’t want them as the standard tiles for a given map. I should probably scratch t_floors out of the definition and allow every tilecell to become the generic floor, should be more flexible this way. t_wall and t_border will stay for now, since I plan something for those. Walls, for example, should be able to actually choose between different graphics, depending on their surroundings (so it would automatically chose the right image for edges, horizontal/vertical walls, etc.). t_borders meanwhile, I plan to include as an out of bounds case for moving objects, which triggers a list of effects before putting the map actor back where it came from or remove it from the map (a special case which I actually haven’t addressed until now in the code. Gotta think of something there). t_borders might also get through without a specific definition, t_walls, however, would most likely require a more unique approach.
You should be able to ignore that phrase by defining the parameters tile-width and tile-height manually, or you can use the fit phrases for width and height separately, like you usually do in GCBD (the phrase I used in the examples just bundles those). Maybe I should add an example which uses one of those approaches.
[spoiler]For that, I would like to present an idea that popped up while I was thinking about one of your points during your initial rant:
When I was trying to use R&D to get a combat prototype working, I noticed how much of a major flaw the initial design of img_ref really is. The combat demo should have different teams fighting each other, each team having its individual colour. That colour should be visible over the the directional arrow (much like the arrow you see when selecting a character in the Ben and Jill example). Problem here was that R&D didn’t have any easy way to separate the arrow from the actual graphic of a combatant, so I would have to draw all 8 directional graphics of all the map actors for each team, instead of just adding the arrow later as an individual graphic. I realized that this would turn out to be an immense pain in the butt, so I had to rethink the way of how R&D prints map actors.
My idea: an activity buffer (although I use the term quiet loosely)
An object which would store any relevant data for printing a map actor (that would be the map actor itself and the current map-display) which an activity (that actually applies to nothing) would access. For animations, you could then write something like
Before map actor printing (this is the standard animation loop rule):
If current_actor of printing_buffer is animated and not idle, rotate img_ref of m_figure of (current_actor of printing_buffer) .
As for my own problem with the coloured arrow, I would add another list of lists of numbers to the map figure for the current graphics displayed. The actual activity would collect the graphics that should get displayed (completely independent of how you organize them in img_ref, unless you specify otherwise. Indeed you could specify that no graphics in the img_ref are used at all) and tie them up in that list into a neat little package which the map-display can then process.
The general procedure would then be: Pick a map actor → insert map actor into the buffer → carry out the activity → get actualized graphics from map actor → rinse and repeat.
I hope this will improve your personal freedom and might finally provide a solution to the To Phrases overkill I’ve got to deal with (as a similar structure could be used for environmental effects for example).
Any flaws in this approach?[/spoiler]
This needs to be clarified then. Making it a subkind was more an act of convenience since I wouldn’t have to deal with scope and whatnot. You can display a m_room at any given time without the player being present but placing or spawning a thing inside a m_room will also automatically move it there (at least this is the only limitation that I remember). Might go against the minimalistic approach I was advertising before, come to think of it.
I would rather keep it. Reason being that I think independent named rules to be easier replaceable (important if you want to switch layouts on the fly) than rules in the midst of an activity, with all that listing or de-listing or whatever. This is just my uneducated opinion though.
That’s hopefully not as important anymore, if my solution above actually works but still some nice trivia nonetheless.
Sounds awesome! But, to be honest, I wouldn’t have a clue how to do that off the top of my head…
Glad that you seem to enjoy it thus far
I hope you can get opinions from other folks. I don’t want to be the sole interlocutor on this!
Fair enough. Realistically, authors would probably have multiple floors and multiple walls, and so giving each type its own table isn’t a terrible burden; in fact, it’s probably a good idea. Ambitious ideas for the wall and border tilecells. I agree that this would be user-friendly–but would it be performant?
Bug alert: I just introduced movement to my map (still just following the Cyberspace example), and the t_walls don’t stop the movement of my map actor. Is there something that I need to do in my code to get the t_wall’s block effect working?
[spoiler][code]Section - Map
Floor is a t_floor. Tile-collection is {{100}}.
Wall is a t_wall. Tile-collection is {{102}}.
Dungeon is an m_room. The room-length is 10. The room-width is 10. The def_floor is Floor. The def_wall is Wall. “This is a dungeon.”
The m_actor of yourself is the Bowman.
Dungeon-display is a full-map top-down-display. The associated canvas is the graphics-canvas. The origin is {20, 20}.
When play begins:
carry out the map generating activity with the Dungeon;
spawn player on sector 2 and 2 in the Dungeon;
focus Dungeon-display in Dungeon;
now tile-width of Dungeon-display is 24;
now tile-height of Dungeon-display is 24;
open up the graphics-window;
dump map of Dungeon.
After map generating the Dungeon:
draw frame of Wall from 1 and 1 to 10 and 10 in Dungeon;
place Wall on sector 3 and 3 in Dungeon.
Every turn:
refresh windows.[/code][/spoiler]
Oh, OK. I thought you might be doing something funky with those properties. Setting them directly definitely seems to work. Cool.
Yikes, I’ll have to think about that.
Activities don’t require listing and delisting, regular old rules do. If I wanted to switch layouts on the fly, I’d just put the conditions in the preamble of the after rules, e.g.:
After map generating the Dungeon when the wizard is alive:
After map generating the Dungeon when the wizard is dead:
When you use a single named rules, you either have to include the conditions in the body of the rule (not very Inform-like), or you have to swap the rule procedurally (“now the built-up-rule of the Dungeon is the wizard-is-dead-construction-rule”).
But whatever. The built-up-rule isn’t bad, just extraneous. The “after map generating” activity is available whether it stays or goes.
It’s don’t think that it’s nearly as hard as it sounds. Here’s a start:
[code]To dump map of (R - an m_room):
say “The map-tiles of [R] are [map-tiles of R in brace notation].”;
say “The map-effects of [R] are [map-effects of R in brace notation].”;
say “The map-graphics of [R] are [map-graphics of R in brace notation].”;
say “The height-storage of [R] are [height-storage of R in brace notation].”;
say “The map-objects of [R] are [map-objects of R in brace notation].”
After map generating an m_room (called the place):
dump map of the place.[/code]
I’m just not sure which properties need to be captured. Actually, this kind of thing should probably be part of any debugging toolset you put together.
Gotta run but a few points before I go:
Yeah, the actual feedback has been pretty lacklustre, as had to be expected, I guess. It’s cool when your thread brings other topics up, like file prefixes, but you would like to hear people’s thought about your own stuff as well at some point. Hope that doesn’t come over as too brash
Pardon my curiosity, but did you get much feedback for the GCBD documentation?
Not a bug per se. You’ll need to define the behaviour of the generic wall effect (I haven’t done so since what a phrase considers as more specific can be rather wonky) so you’ll need something like
To ee_enter activate (e – g_ee_wall(?)) for (t – a mappable thing):
rule fails.
Provided that there is always at least one condition, which doesn’t have to be guaranteed, I would think. But you’re right, it’s nothing worth agonizing about.
Oh, that’s what you meant (that’s printing then copy and paste into the code, right?).
Don’t remind me. I hate debugging. So dull
None. But I don’t remember if I asked for feedback about it. I asked for help testing the extension, and got loads of interest, but zero follow-through. That was probably due to a pretty big blunder on my part–I asked for help testing the extension before I wrote the docs. (It was actually worse than just GCBD–I had all of the Glimmr extensions ready but w/o docs at the same time. An overwhelming amount of code, and nothing but the examples to guide you through.)
Maybe what you want to try is to make the changes you plan to make the docs, and then post a request for another eye or two to look over only the docs.
But never expect too much. Glimmr and R&D are fringe efforts. The community is pretty ineffective generally in its support for extensions, and even extensions that affect the core functionality of your standard IF (e.g., Smarter Parser) may only get marginally more feedback–and not all of it very nice, or very informed, as a recent thread will indicate.
I want to encourage you with all the force I can muster to include this (and any other similarly left-out phrases) in the extension proper. Phrases are very flexible, they can be overloaded, and I can’t remember every finding specificity to be wonky. If you name the rule, then authors can simply replace it if they need to, e.g.
To ee_enter activate (e - g_ee_wall) for (t - a mappable thing) (this is the walls block actors rule):If your predefined walls don’t block movement right out of the box, the extension will just look broken.
Yep. It’s probably best to print the results to an external file. Obviously, an author could use the same solution to avoid distributing an external file with the game (referring to the human-readable map import you’ve been working on). I can confirm that the code I posted isn’t quite enough; when I paste the code it produces, nothing displays. My workflow would probably be to include the procedural definitions in one extension and the pasted code in another. It would then be possible to switch between them just by activating one or the other extension.
I’m not sure that I understand every detail of what you’re proposing here, but rather than another data construct (such as a buffer) I think that this is actually the perfect place to use an object-based rulebook or an activity (the former is probably slightly more performant, but it’s not likely to make much difference). You as the extension author need only provide code for a single standard image and for facing images, and the author could substitute his own code as needed. For example, you do something like this using an object-based rulebook (pseudocode):
[spoiler][code]An m_figure has a number called the printed-image.
An m_figure has a list of numbers called the facing-images.
Definition: An m-figure is multidirectional if the number of entries in its facing-images is greater than 0.
Definition: An m-figure is unidirectional if its printed-image is not 0.
The actor-printing rules are an object based rulebook. The default outcome is success. [i.e., only one rule will fire unless we say otherwise]
An actor-printing rule for a unidirectional m_figure (called the target):
print target’s printed-image.
An actor-printing rule for a multidirectional m_figure (called the target):
print appropriate facing image for the target.[/code]
Very simple, and also very Informish. To add my own custom drawing rule, I just slot in a rule that is more specific than either of these:
An actor-printing rule for an animated multidirectional m_figure (called the target):
print the author-defined image reference for the target.
It’s up to me as an author to create a new data structure if I need one; the extension doesn’t have to try to create a buffer for every possible use. For your purpose (the separate directional arrows), you could do something like this:
First actor-printing rule for an m_figure (called the target):
print the appropriate arrow image;
continue the action.[the appropriate rule to print the actor image(s) will now fire as well] [/spoiler]
That’s what I’d recommend. Of course, I don’t know the extension well enough to have any idea whether it’s compatible!
Certainly, I’ll just test them out a bit more to see if there aren’t any unforeseen complications before I include them.
In regards of using rulebooks, I think I actually tried them out when I was looking for a solution to activate environmental effects. I think the big problem there was, as with activities, that they wouldn’t allow to use multiple parameters, as To Phrases do. There might have also been a problem with activating several rules in a row when I wanted to use only one, but I’m not sure about that anymore, it has been a year or so.
Another thing that you mentioned earlier was conditional compilation. I didn’t even know that something like that is possible in Inform 7. My concern here is that it wouldn’t work with the map - map-display cross reference I have in place (which is a list of map-displays attached to a m_room). Would it be possible to do something like this?
[code]Part 5 – Map-displays (if GCBD is not included)
map-display is a kind of thing.
Part 6 – Graphical map-displays (if GCBD is included)
map display is a kind of image-map.[/code]