Niemand

Cool; I have free time this weekend (I passed my preliminary exam today!), so I'll take a look. Edit: So beautiful. where doing it man where MAKING THIS HAPEN (Making the main window resizable. No hugging is necessary at this time. Fancy OpenGL drawing might be necessary, though, as scrolling this thing eats a frightful amount of CPU cycles.)

Slarty's point is that Jeff probably knew how much work it would be and so didn't even attempt it in the first place. There are (probably, Slarty has looked more at the BoE code than I have, I'm guessing) no sections of code anything like what would be required, and Jeff has a tendency to leave that sort of thing lying around. (For an example of a feature that Jeff probably was planning to include but abandoned, see the 'location' datatype in the BoA implementation of Avernumscript. The game interpreter recognizes it and there are a couple of valid operations with it, but nothing more.)

Quote: Stain/object/field placement could also become a new "tab" in the tile window, couldn't it? That is a very good point.

Quote: would it be worth asking about releasing the BoA source again now that Avadon's out and (apparently) doing ok? It's getting toward being a good time, yes. Part of the concern is however, that we want to convince Jeff that if granted the source code we'll actually do something with it. As I recall, the last time it was brought up with him he wanted to know what the community had accomplished with the BoE code since its release, and there wasn't much that could be pointed to to impress him. I assume that it's partially about the fact that it does take a bit of effort on his part to get his code all packaged up for the world to see, so he wants to know that the effort would be worthwhile. Also, he has to beleive that the good derived from the community working on the code will in some sense outweigh the small benefit Spiderweb has from holding onto the code and continuing to sell the game now and again. He did hang onto the BoE code for a full decade after the game's release, and while BoA is shading toward that age, it isn't there yet. I think that when we next request that he consider releasing the code we should be able to point to several concrete accomplishments/strengths of the community. The 3D editor is certainly a highlight, and if in the next version or two we can get ready the interface changes we've been discussing here we'll have good grounds to argue that we have gotten a good deal of value out of access to the code and importantly that we continue to do so. Ideally we should also be able to point to a healthy amount of activity in designing scenarios, which we may not be able to do very well at present. In short, I'd like to be abnle to argue convincingly to jeff that if he hands us the code something interesting will happen. Finally, we, or at least I, would like to be able to be somewhat ready with ideas of what we want to do with the code once we get it. I have a number of ideas, but none of them is anything like as ready as it could be. Something which might be a good activity for us as a group over the summer would be to draw up a roadmap of what exactly we would do with the code starting the minute we got it. This wouldn't necessarily be for showing directly to jeff, but just so that we could ensure a degree of productive activity and make the project more robust against individual people wandering off or being too busy to contribute. The early parts of the list could be pretty easy like where to put the code (do we want it on Google Code, on Github, or for someone like me to host it?) and which of the known bugs we would tackle and how exactly we would try to resolve them (Items don't stack when given via char_give_item, so let's make 'em stack). It would then get more speculative, but work up from changes we are fairly certain we can make easily (maybe: replace PICT resources with PNG image files) to bigger harder things that would take a substantial amount of work (rewriting the drawing code to use something other than Quickdraw). -------------------------- Getting back to our earlier topic, shoughts about remaking the tool palette: Here's a tentative break down of the existing tools into categories: Click to reveal.. Basic Drawing: pencil small paintbrush large paintbrush small spraycan large spraycan paint bucket Advanced Drawing: Set Height Draw Rectangle Fill Rectangle Bounding Walls Swap Walls Change Terrain Randomly Copy and Paste copy terrain paste terrain (View modes -> terrain view window) switch 2D/3D toggle zoom toggle realistic (Drawing mode -> tile window) floor mode terrain mode height mode creature mode item mode 'Object' creation create special encounter (create/edit sign?) create room rectangle place terrain script place waypoint place spawn point Town Entrances place north entrance place west entrance place south entrance place east entrance Object and Field Placement make space blocked place web place crate place barrel place fire barrier place force barrier place NE/SW mirror place NW/SE mirror Stain Placement place small blood stain place average blood stain place large blood stain place small slime puddle place large slime puddle place dried blood place bones place rocks Select Object Eliminated: autohills -> within current drawing tool delete waypoint -> within editing details for selected waypoint clear space -> make objects, stains, etc slectable and deletable (blockage?) In the obove listing, the object and Fields category could be reasonably expanded to include stains. This would then leave a space for the eyedropper (more on the eye dropper in a moment), since it works out most nicely to have an even number of categories. Select Object is so importent that it is its own category. The eyedropper is annoying, since it is rather different than most tools, an sort of doesn't belong with the rest of them. Acorn (from which I'm stealing the entire UI idea I'm building up here) handles this by treating the eyedropper specially, making it a pseudo tool whose icon is associated with the color wells rather than the other tools. We could do something similar by putting the eydropper in the tiles window. We would have to figure out haow to fit it in so that the design would look deliberate, however, and not just like we accidentally put one button off by itself. For those who haven't used Acorn, here's how its tool palette behaves (See this screenshot): It has two main sections, with the left being the array of tool category buttons, like selection, painting, or cropping. The right section is the details of the current tool or category, and if the category includes mutliple tools there are buttons for selecting among them. Also in this area any settings or details of the current tool are shown. A nice touch that I would like to duplicate is that when a tool is selected within a category the icon for that category changes the the icon of the that tool, instead of matching the first tool in the category. In addition, each category remembers the last tool used within it, so returning to a category which has been used previously returns to the tool last used in that category. So, finally, here's a mockup I made of a how we could replicate this: Image The size isn't well determined; I just picked border widths that looked nice and left enough space hozontally in the detials section for eight tool buttons across the width. One disadvantage of this approach is that it makes the tool palette relatively bulky, particularly since it ends up being close to square, on smaller screens fitting it in with the main view window (we need a clear, consisent name for that thing; maybe just main window) and the tile palette may get tricky. This could be made worse by the fact that we still haven't solved the problem of where to put all of the stuff that's currently in the 'left text lines' which is very necessary for accessing a selected object's properties. One possible path would be to use the toll details space for this when the current tool is the selection tool, but this might be tricky to do without bloating the toll palette window badly (I think that creating some kind of tabbed interface may be necessary to be able to shoehorn in all of the details for complicated objects like creatures, wherever we put them). In terms of coding, what would these changes require? To start with, the code which draw the tool palette and 'right text lines' would have to be totally rewritten, preferrably with such things as a separate function to render the details section for each tool/tool category. The mechanism for recording which tool is in use currently would need to at least be extended, and preferrably replaced, which would be a big job but would lead to cleaning up some of the worst code in the editor (giant switch statements over arbitray magic numbers representing the various tools, and hideous loops which mix determining which button was clicked with carrying out the button's action).

Quote: I've put drawing mode controls onto the tiles window, so cycle drawing mode can probably go now. Looks like a reasonable first step. To go with this I ought to finally get the keyboard shortcuts properly included in one of the menus as menu items, rather than being secretly hard-coded into the keystroke handling code. Another thing we should perhaps do (and I'm by no means saying that you should do it now, I'm just thinking out loud) is that maybe the buttons which affect the display mode of the terrain view should be separated from the drawing and object manipulation tools and put into the (now stand-alone) terrain view window. Other buttons/tools which should be eliminated eventually are Delete Waypoint, Clear Space, and Edit Sign. The autohills toggle should probably become some sort of subsidiary of whatever drawing drawing tool (if any) is currently in use, and only be displayed when in terrain drawing mode. Quote: I'll try to get the tiles window resizable, and as a temporary thing stick the text that goes under the map onto the tools window, and then I'll put the messy code on the svn as a branch (I'll try and make it nice and clean after I've finished exams in june). I wouldn't even worry about making the tiles window resizable yet, that should be a relatively simple thing that we can do later once we have the thing working consistently. On the other hand, if you feel like tackling it, by all means go ahead.

Congratulations on another scenario release, Bain. With regard to hosting, I would be willing to store it for you, but you can always just put it on the Blades Forge, which Aran built for this very purpose.

Originally Posted By: Celtic Minstrel Originally Posted By: Niemand The harder part will be doing a good job with the cluster of random buttons in the second and third rows that do fairly unique things, although a number of these I've been trying to do away with altogether anyway. Which buttons do you mean? I mean buttons like cycle drawing mode, change terrain randomly, erase nav point, edit sign, and so on. Most of them are useful and necessary, but they don't break down into associated group;s quite as obviously as most of the rest.

Quote: I wasn't too sure what to do with it for now either; I moved the "Now editing *blah*" stuff to the window title, but that doesn't help with the text you get with creatures / encounter rectangles / etc. Ah. Unfortunately in recent versions I've elevated the importance of this part of the interface. One thing that we might consider is to take this as an opportunity to do away with the 'Town Details', 'Edit Creature', and such dialogs by making a unified inspector which changes contextually. The trick will be to avoid making it huge, in terms of space taken up on the screen (since the Town Details window, for example, has a lot of junk in it), and also not go too far the other way giving it a zillion annoying tabs that the user needs to constantly switch between (like the inspector windows in Interface Builder, Keynote, and a whole lot of Apple's recent software). EDIT: Since you mention it in your edit above, I thought I would reverse my decision not to mention trying to simplify the tool palette. My inspiration here is the Acorn tool palette. As you note, something like half of our buttons are types of objects and stains, none of which gets used very frequently. The harder part will be doing a good job with the cluster of random buttons in the second and third rows that do fairly unique things, although a number of these I've been trying to do away with altogether anyway.

Ooh! Pretty. I would be very interested in getting this code into the repository once you think it's fit to show to others. (We could always make a brach to stash it in until the kinks are worked out.) One thing that we do need to keep in mind is giving designers a way to see how much will be visible to the player from a given point, for making cutscenes and the like. Currently we do this in a sort of brute force way, by making the editor's isometric view box the same size as the game's, but we could introduce a frame to mark or mask out the not-visible-to-the-player portion of the view. Quote: I was thinking that maybe the toolbar could go at the top and be more stretched out?, say with just two longer rows rather than 6 short ones. Do you mean as a separate window, or within the main window. I assume the former, since the latter would interact badly with the main window's size changing, potentially. EDIT: Just to clarify: What have you done with the chunk of the interface consisting of the text normally shown at the lower left of the window, below the terrain view? If the answer is that you've ignored it because what you have is a prototype, that's fine, but we will need to reincarnate it somewhere. Possibly it should be merged with the tools palette, or possibly we should totally redesign it as a new inspector window. Neither option really grabs me as sounding great, so I'll think about it.

Quote: I deleted all my Spiderweb games to make Avadon run faster. Uh, just so you know, that's really unlikely to help in any way whatsoever.

I certainly wasn't claiming that mutually assured destruction makes us all totally safe, merely that rules for non-nuclear weapons could retain old forms since empirically there isn't much overlap between nuclear (and more generally weapons of mass destruction) and non-nuclear weapons.

Originally Posted By: *i Part of the problem with a lot of these high ideals of warfare is they arose post World War I, designed to try and "civilize" mass conflict between global superpowers. With the advent of nuclear weaponry, such type of warfare really has become obsolete. To the extent that major powers are virtually unable to attack each other, and so at least one side in any conflict must be a minor power. In fact, it isn't clear, then, why the conduct of war and the laws governing it would need to change, given that the threat of nuclear weapons is, in some sense, decoupled from that of conventional war, which is the only type of war which has actually occurred (with the exception of the two nuclear bombs dropped on Japan by the U.S. at the end of WWII) since nuclear weapons have become a threat.

Originally Posted By: Duck in His Old Hat Quote: Do "changes" include graphical tweaks? Like, swap out a wallset, replace all the default trees... I think a few small graphical changes like this should be allowed. The point of this contest is to produce fun and creative scenarios, and if you need a little change of scenery to make that happen then go for it. Just try not to go overboard and completely overhaul everything. That sounds like a good policy, as I understand that the idea is to create a level playing field for making scenarios that don't involve a lot of laborious terrain drawing (and also so that experienced designers don't completely steamroll the beginners using technically detailed ideas). I'm not sure if I'll enter or not (as this will depend on whether I can think of an idea for a scenario), but if I don't enter and another judge is needed I would be happy to help out in that way. (And, in the spirit of the first part of the post, if I do enter I won't try to subvert the rules by overwriting the all terrain at run-time. )

Quote: Anyway, I'll use cr_small_or_large_tempate = 0 from now on. The thing to do is not to always set this property to zero, but to select its value depending on which size graphic sheet you're using for the creature in question. (Maybe you already understood this, but I thought I'd speak up so as to be certain that you wouldn't run into an unpleasant recurrence of this problem again later.) However, for your specific case a value of 0 is definitely what you want, for the reason B.J.Earles noted above.

It's both how I interpret the wording in the docs, although it isn't totally unambiguous, and what I see in practice. (I used this in BoR.)

I'm not sure if it matters, but looking at some of my code I've usually used a value of 1 for the third parameter of approach_waypoint (the distance to approach within). It might also be a good idea to check the return value of the approach_waypoint call so that you can know within the script whether the character decided to move or not. Also, just as a sanity check: if you based this script on basicnpc, are you certain that you either removed the fidgeting and return-to-start code, or made sure that the code you showed above comes before it?

Not so, they are stuck with whatever is set as their cr_default_script, which is normally basicnpc, but can be changed.

Yes. It requires defining (or modifying) a creature type and setting its cr_special_abil attribute to 29. According to the docs: Quote: Divides in two when struck. New creatures use the default script for the creature, don’t drop treasure, and don’t give experience. Creatures with this ability don’t regenerate health. You can find all of the creature abilities listed in section 2.6 of the editor documentation.

The aliases in the Time Machine backups are perfectly good and point to real stuff. (Technically, they are directory hard-links, I believe.) The reason for the funny folder names is that if one item in a folder changes, Time Machine doesn't want to duplicate the whole folder just to include the one changed item. So it makes a new folder into which it puts the new version of the changed item and links to all of the other items as they existed in the previous backup (since they are still the same as they were in that backup). In short, the Applications are exactly where you would expect them to be: they are in the backed up Applications directory. The exact nature of that directory may be a bit unusual, but that shouldn't be cause for concern. However, it sounds like what you want isn't to pull out individual files or directories, but to restore the entire system. See this support article, specifically the section titled 'Restoring your entire system from a backup'.

I recently read the first two books (Dauntless and Fearless) of Jack Campbell's The Lost Fleet series and found them worthwhile. Here are some more book-reportish ramblings: Click to reveal.. The main character, Captain Geary is an officer of the Alliance who is effectively promoted to admiral of the main Alliance fleet in first few pages of the first book. This arises because virtual all of more senior personnel in the fleet are massacred in a trap disguised as negotiations by the other side, the Syndicate Worlds (the 'Syndics'). Geary ends up in charge because he has recently been recovered from an escape pod in which he has been in suspended animation for approximately a century; in the intervening time he has been assumed to be dead but viewed as a hero. So, not only is he virtually worshipped by many but his date of rank far predates any other captain in the fleet. At the start of the story the Alliance fleet is trapped in the Syndicate home star-system after a strike deep into enemy territory which turned out to be an ambush engineered by the Syndics. After the killing of the senior officers Geary is able to organize the fleet enough to fight his way out of the Syndic home system, but they are still extremely far from friendly territory, and must find a way to fight their way through without being surrounded and finished off. A key plot element is that two modes of faster-than-light travel are available. The older mode can be used to make jumps to adjacent star systems, with transit times of a few to several weeks. Beginning a jump requires reaching a certain point on the outskirts of the first system and the jumping ship arrives at the corresponding point in the second system. The only equipment needed for this method is the ship's engines, as well as knowledge of the available, naturally occurring routes. The second method relies on man-made gates which are networked together so that a ship entering any gate can exit through any other gate in the same network ('hypernet'). This not only allows ships to travel directly to their destinations, but may also be faster than an equivalent single jump using the old method (although I'm not entirely clear on this point). Both sides in the war have their own, incompatible gate networks, which do not overlap (since obviously neither will allow the other to build gates in its territory). The Alliance fleet was able to enter the Syndic home system directly because the equipment necessary to access the Syndic gate network was leaked to them in order to bring them into the trap. Only one ship in a group need to have this equipment for the entire group to be able to travel the gate network, in the case of the Alliance fleet only the flagship, Dauntless has the equipment. In addition to trying to prevent the destruction of the majority of the Alliance's naval assets, Geary must try to return the hypernet access equipment the the Alliance where it can be duplicated. This would potentially allow all Alliance ships to use the Syndic hypernet, while the Syndics have not gained access to the Alliance hypernet. It is presumed that this would give them an edge which could turn the tide of the war. (I was about halfway through the first book when I recognized the reference of a ship named Dauntless, trapped deep behind enemy lines, carrying data vital to the survival of Civilization. The ship name doesn't quite fit right, as it should be Britannia, but then again it survives (at least for two books) to continue its mission. At any rate, this didn't look like coincidence to me, and made me happy.) However, the fleet cannot take much advantage of hypernet access for the time being since traveling to any system with a hypernet gate would mean that the syndics would be able to rapidly move in superior forces, so they must spend most of their time skulking in little visited systems. Things which contain more spoilery material: Click to reveal.. One component of the story thus far which I didn't find terribly convincing was the author's mechanism for the hero to change the rules so that his fleet actually stands a chance. Namely, supposedly in the hundred or so years that Geary has been out of circulation space fleets have ceased using carefully coordinated tactic and instead mostly rush at each other in undisciplined mobs. Geary begins retraining his fleet in using deliberate formations and tactics, which increases the relative strength of his force. While the basic idea that a well organized attack or defense can defeat a disorderly charge seems fairly sound, the justification for the supposedly now standard lack of tactics is a bit weak, namely that the vast majority of fleet officers are very poorly trained due to rapid turnover from high casualties. Another aspect of degeneration which the protagonist is required to combat is that the Alliance fleet has become drastically more brutal, either not taking prisoners or executing prisoners after their surrender. This seemed like a reasonable move on the author's part, which serves both to establish the hero as a definitely good guy and to show that the Alliance is in serious danger of losing (philosophically speaking) regardless of the outcome of the battles. A final major element, which has only just begun to show by the end of the second book is the implication of an alien power existing on the far side of the Syndicated Worlds from the Alliance. The evidence given is circumstantial, such as a vault which the fleet finds at an abandoned syndic outpost which has been previously broken into using odd tool sizes, the curious way in which the Syndics have pulled back their far border and reinforced systems with little discernible value and importance, and the curious way that both sides in the war developed hypernets at almost the same time, with the actual inventor being unclear. Suspicion is increased when it becomes clear that there are multiple ways that hypernet gates can be used as weapons against societies reliant on them, as their destruction could either destroy or strand ships currently in transit and can also be used as bombs with variable yield with a very high theoretical upper limit. I assume that when the author spends a substantial amount of space hinting at something like this he intended to take it somewhere; I'm curious to see where that turns out to be. I'm rather looking forward to reading the remainder of this series, although it may be a while given the number of new books I still have left to read at the moment and the amount I've spent on books in the last couple of months. (I don't recall whether I've mentioned it before, but Borders closed down their really convenient location right near where I live, and I considered it my civic duty to help out with the clearing at the clearance sale.)

Originally Posted By: Lt. Sullust This is not to say that all is lost; rather, I think we may be able to find a solution through technology to implement 'pseudo'-magic. Basically I envision using nanomachines, as well as a control device to manipulate the machines in the desired manner. I hadn't yet gotten around to mentioning these books in the 'What have you been reading?' thread, but if you thought of this idea you might like Mayer Alan Brenner's Dance of Gods series. Hopefully drawing the connection between your idea and the books isn't too much of a spoiler. Originally Posted By: Dintiradan The difference between magic and your pseudomagic is that magic doesn't risk turning the entire world into grey goo. Also, "real world" magic and spells would probably involve patents, licenses, and DRM. There would be competing nanomachine vendors having different implementations. So any given magic user would only have a license with one vendor, be it Illusions Incorporated or the Black Magic Company. (I'd be surprised if this doesn't already exist as a short story somewhere.) This reminds me of Heinlein's Magic Incorporated, although in that story the magic was more of the traditionally supernatural form without any technological basis. Still it's a good story exploring how magic might fit into modern society (none of this nonsense with secretive groups hiding in plain sight everywhere, which while admittedly not a totally stupid idea, gets old as a treatment of magic). As you note, though, there are probably other stories less well known (at least to me) which treat a more similar idea. With regard to the actual original idea here: This is basically an attempt to implement Clarke's third law literally. The main issue, as I see it, is that nanotechnology as, envisioned by many science fiction authors really just isn't plausible. Consider the most simplistic of all nanomachine stories, the gray goo scenario. The nanomachines aren't expected to be all that sophisticated; all they do is take apart any matter they encounter and rebuild it into more, identical nanomachines. Issues arise quickly, though, such as: Assumedly each of these nanobots (being the variety nicknamed 'gobblers' in a few stories I've read since all they do is eat everything in order to reproduce) needs a certain distribution of elements to make. Perhaps it needs to be 20% carbon 10% oxygen, 8% iron, and so on. So what if I drop one into the ocean? It will be surrounded by hydrogen and oxygen, but (relatively speaking) very little else. If I walk outdoors and drop one on a rock it will have easy access to silicon and oxygen (from the rock, depending on what kind of rock it is, anyway) and nitrogen and more oxygen from the air. In either case there will be traces of other elements around, which could be collected to form a new nanobot, but most of the material available is useless in any given location unless your nanobot is also equipped to transmute elements. As a result, only a small fraction of the earth would ever get converted into nanobots, assuming no transmutation, including much of the surface as well as the core (which is not only lacking in variety but also quite inhospitable to most kinds of complex molecules). Gobblers might sterilize the earth's surface, but they would hardly eat everything. Next, how does one get the gobblers to not attack each other? One might not care, since they might be able to devour the earth anyway, but then again they might not, and it would certainly be an issue for designing any more useful nanobot. Not only then is it a problem that in order to make a nanobot think more about what it's doing it will need to be made much large, in order to have some kind of expanded computational ability (even assuming some kind of computer using components far smaller than anything we can hope to make in the foreseeable future), but also that it needs to be able to see what it's doing. How does one make a nanobot 'see' it's surroundings, at the atomic or molecular level? How will it interpret this data so as to understand the 'forest' (object of interest) from the 'trees' (atoms or molecules nearby). Will one try to make the nanobots communicate amongst themselves? That will take even more processing capability as well as communication hardware, which will further bloat the size of each robot. As a result of considerations like these I would argue that it is not possible, based on the extent of our present scientific knowledge, to ever create nanobots which can do generalized assembly or disassembly in a non-well controlled environment. Creating very small machines which do complicated, specialized tasks may very well be possible, but may also require highly specialized (and potentially forever macroscopic) equipment to do so. (A number of years ago I read a science fiction book which I consider very stupid hinging on nanotechnology. In one scene the protagonist has been captured by the badguys. He manages to make a phone call, or make his voice heard in the background of someone else's call, and his deus ex machina nanomachine supercomputer detects his voice (since it sifts through all phone calls made anywhere in the world at all times) and dispatches a swarm of nanobots through the phone lines. The nanobots arrive in the room shortly and disassemble all of the badguys, but not the good guy, supposedly by recognizing his DNA. Problem: How do they recognize his DNA without eating the top layer of his skin? How do they not keep eating further into him as each new robot that blunders into him needs to eat enough to recognize who and what it's eating? A much better book with regard to its treatment of nanotechnology is Ladybug, which involves machines which are small, but not molecular scale. (In fact one of the machines is large enough that it is the titular ladybug).)

What's going on here, on the surface anyway, is that the game is pulling graphics for those creatures from the wrong sheets. The incorrect ones it's using are the ones of automap icons, apparently, and I'd assume that the crashing is because death animation frames are on the bottom row of creature graphic sheets and the automap graphic sheets are small enough that the game ends up trying to grab data from off of the bottom of the sheet. As for what's causing this, I'm not sure. Which scenarios are affected, and which objects (creatures, items, terrain) show problems? (I'll look into the example from your screenshot, but a sense of the larger pattern might help.) Does the problem go away if you just re-download the scenarios? (I doubt it will, but it would be nice if it would.) From the mention of unhandled exception errors, I assume you're on Windows?

That's newer than the Spiderweb version, but still rather old (before 2007, or some such). See this page for a link to download a newer (but less stable[1]) Windows version. Note that the download link on that page acts a bit funny and you may have to right-click it and use 'Save As', or copy it an paste it directly into your browser's URL bar. [1]: After the BaAEdRemake team wandered away things got a bit less organized, and we don't currently have a nice, neat release of the Windows version of the editor. What we have should instead be considered something like a 'nightly build'. If you prefer not to mess with that until we have it better organized, the BoAEdRemake version is still a big improvement over the original editor, and will serve you well. (The Mac situation is less confused, but that doesn't help you, unfortunately.)

Quote: Would it be too much work to get the editor to parse such comments and replace the meaningless "Memory cell 0", etc labels with actual descriptive labels from the comments? Might require standardizing a format for the comments, but it seems like it would be a very, very useful thing to do. It could be done, and I'm not sure it would require much more format standardization than we already have, at least to reproduce the notes already included. I've noted one minor formatting issue which would have to be worked out, and something would have to be added to support short descriptive names which would fit in the editor UI, but it seems like a reasonable thing to attempt. I'll get my ideas in order, hopefully, and make a new thread about it.

I see what you mean; there is something funny about that link. Unfortunately I can't do anything about it, as it's pointing to a file on another website, which is where I assume the oddity has to be (since there's no other difference on my end between that link and the Mac version one, which works normally). It does work for me if I right click on the link and choose the equivalent of 'Save As', otherwise you can find another link to the same file on Ishad Nha's website, which is where it is actually located. Sorry about the confusion.