Niemand

If you have a question, then ask it clearly, please. The piece of information that I think you are missing is that when BoA designers create shops in their scenarios they set a number which determines the pricing at that shop. However, until this analysis, no one actually knew exactly what the settings did, besides the general trend that higher settings made the shop's prices worse. Nioca has now determined quantitatively how the prices depend on the setting.

It's not that you're corrupting the value by reading it, I think, as that your act of reading it causes the game to notice that it is 'corrupt'. The game has a hair trigger for this particular alleged error, and as Thuryl says, it doesn't seem to mean business about resetting anything to 0. EDIT: And the project lives, if slowly! I, for one, am still working.

Originally Posted By: Excalibur So basically, you can't buy a spell from a shop once your skill in the spell reaches a certain level. No, not at all. As Nioca describes in some detail the game stops the price of spells from increasing to greater than the amount of money the party can carry.

Some very nice spading work. It's good to have information like this at designers' finger tips. One point that could be clarified: Does the price ceiling mechanism work the same for regular items as for spells?

I think that there isn't a whole lot of need for creating all of the towns by size at the start, although being stuck with the first town always as medium sized is annoying. I hope soon to finish porting the code I wrote for the Mac version which allows it to change the size of a town that is already in the scenario, which would give designers the freedom to make the first town whatever size they want.

I haven't yet taken the time to read all of the text in every cell, but that looks pretty good to me.

Originally Posted By: Arancaytar Speaking of which, as I said to ADoS privately, I would very much like the next Blades Forge to become a team project, because I'm not up to doing that on my own again (witness that the Forge hasn't really been overhauled in almost two years). Anyone who messes about with PHP and Drupal would be welcome. While I lack any particular skill to help, I would be excited to see that happen. (Although I stand by my offer to work on a desktop client to interface with part or all of the Forge.) One thing that I would personally be curious to learn more about is what the necessary work on the Forge actually entails; basically, what the project's development checklist looks like.

You know, it really would make the most sense to either continue the discussion where it was (SV) or just hold it where the most people are (here). Originally Posted By: Dintiradan Reviewers send an e-mail to the designer, talking about the scenario in depth. This is an interesting suggestion, but it would prevent designers from learning from the results of other designers' scenarios, unless designers made an effort to summarize and publish the feedback they received. I'm not saying that designers necessarily do get a lot of mileage out of the reviews they see of others' work, but it is something that the current system provides.

I'm still working on trying to ensure exact binary compatibility between old style savefiles across versions and platforms. The problem that I have currently run into is that the current Mac development version of the game cannot correctly read old or current Windows files in my testing. These findings are based on revision 120 of the source code, and the windows savefiles CHEESLOC.SAV(An original Windows BoE savefile,VoDT, Sweetgrove, party location(9,45), decrypted copy:decCHEES.sav) and WINTEST.SAV(A Win32_CBoE_1.0 savefile, VoDT, Fort Talrus, party location(7,6), decrypted copy:decWINTEST.sav). Using the aforementioned program version and files, loading fails, and in addition I have identified what appear to be critical incompatibility problems that occur before the program aborts loading: In the Windows savefiles the scenario name is found at offset 45658. Given that this is within the party_record_type structure, which is preceded only by the 6 byte header (3 16 bit flags), it is implied that the scen_name member of the party_record_type structure should be at offset 45652 wthin that structure. However, in the current Mac version, that member is at offset 46142 within that structure, a difference of 490 bytes. This causes reading of the scenario name and all subsequent data to fail, and implies that an unknown amount of data earlier within the party_record_type structure is also read incorrectly. For reference, the structure in question is: Code: struct party_record_type { int32_t age; int16_t gold,food; unsigned char stuff_done[310][10],item_taken[200][8]; int16_t light_level; location outdoor_corner,i_w_c,p_loc,loc_in_sec; boat_record_type boats[30]; horse_record_type horses[30]; creature_list_type creature_save[4]; int16_t in_boat,in_horse; outdoor_creature_type out_c[10]; item_record_type magic_store_items[5][10]; int16_t imprisoned_monst[4]; char m_seen[256]; char journal_str[50]; int16_t journal_day[50]; int16_t special_notes_str[140][2]; talk_save_type talk_save[120]; int16_t direction,at_which_save_slot; char alchemy[20]; Boolean can_find_town[200]; int16_t key_times[100]; int16_t party_event_timers[30]; int16_t global_or_town[30]; int16_t node_to_call[30]; char spec_items[50],help_received[120]; int16_t m_killed[200]; int32_t total_m_killed,total_dam_done,total_xp_gained,total_dam_taken; char scen_name[256]; }; The first three members definitely match, so the incompatibility exists in one or more of the members between food and scen_name. As though this weren't enough, the problems seem to worsen as reading the file progresses; by the time the program reaches the point of reading the field I was originally investigating (the party's position in the current town), it is reading form approximately offset 99526 rather than the correct offset of 98914 for a difference of 612 bytes. I'll continue trying to figure this out, but I wanted to ask: 1) Can anyone else (Celtic Minstrel) get the development Mac version to read these files (that is, I want to make sure that this isn't something I've somehow broken in my copy), and 2) Does anyone have ideas about how these incompatibilities came about? I'm stumbling around in the dark at the moment, so any clues would be helpful.

Indeed, it shouldn't be unreasonably difficult make alterations to import Warrior's Grove regardless of the size of the existing, about to be overwritten town. While doing so is mildly annoying in the case where there are already multiple towns, it should be trivial in the case where the only town in the scenario is being replaced. Originally Posted By: Cryolemon (I can program a bit, but hate c++ with a passion) Then you're in for a treat! The scenario loading and storing functions contain some marvelously crusty old C(-style) code. It's got lots of pointers, verbose error checking; it's great! (Or or you know, horrible, but it sure isn't properly idiomatic C++.)

Originally Posted By: Celtic Minstrel I'm still waiting on Niemand for the loading (he was working on getting compatible structures or something like that). Very sorry about the delay; my work has been expanding to fill every waking minute. I'll see if I can make more progress tonight. Which work is specifically actually dependent on my getting the old file loading to work?

Okay, so your mention of gzip in the first post was just a red herring. I would suggest then that there may be no reason to adhere to the tar format internally, just use something similar (blocks which know their name and length) but simpler (leaving out permissions data, owner name data, and so on) so that your block headers could be much smaller than the tar format's half kilobyte headers.

What are the 0, 1, . . . , 4.dat files in the save archive, and what is the difference among the multiple saveitemN.dat files? Also, are you putting every monster, terrain, or item definition in its own file, from what I read of the scenario outline? That seems a bit excessive. Lastly, I think this may have been discussed before, but will your header actually be compatible with the standard gzip file format, such that a normal gzip decompressor could unpack the file?

The point is that your posts here ought to be polite regardless of what happened on another forum.

Originally Posted By: Celtic Minstrel I don't think it would be too annoying, actually – if it's anything like BoE, the game just reads the keystrokes directly, so it would just have to look it up in a map or something to see if there is an associated command. This is true of the keys used for the editing tools but doesn't work directly for menu items, as a (deprecated) library function is used to do the lookup at the moment. Also, system libraries are handling reading the shortcut mappings from the resource file and set them on the menu items.

Programming non-menu related configurable keyboard shortcuts is pretty trivial; you need a UI for entering them, an interface with a backing store to save them, and replacing hard coded switch statements with searching a list to match the keystrokes to shortcuts. Source code for such would be rather unenlightening, as it would be closely tied to the program it came from. I would note that at least on the Mac side making menu shortcuts user configurable is at the least a non-trivial annoyance; I've seen it done but the system libraries aren't geared to make it easy.

Originally Posted By: Celtic Minstrel The special queue would now need to keep track of the time that the node was triggered, and when running through the queue we would have to store the current time, set it to whenever the node was triggered, call run_special(), and then restore it afterwards. This does make the code tied to the timer think that it wasn't delayed, by why is that a good thing? If it cares about the time at all, shouldn't it be given the actual time, not a false time in the past? Basically, if given the actual, delayed time, it's possible to write a little more code (add a few more nodes) in theory to correct for the delay, whereas doing so is impossible if the time is always reported exactly as the expected time whether or not such is true. I do agree that consolidating everything into a queue is the natural way to handle timers in general. As a matter of fact, if all timers were always in a priority queue, with the priority being how soon the timer should next fire, the entire operation of firing timers is very elegant: after advancing time, check the front of the queue to find out if the timer there fires. If so, run the associated nodes, and then repeat until the front most timer isn't ready to fire. (This may be what you were saying already, so sorry if I'm being redundant.)

My thoughts on the matter, based solely on your summary: For the first, it seems to me that your suggested method of dealing with combat mode sounds like a good idea, as it would make the overall behavior more uniform, assuming that doing so doesn't involve overly great technical difficulty. The second is much tougher, since it's basically a concurrent code execution problem. Breaking the first chain, the one containing the rest node if I understand correctly, seems like a bad idea, as it could leave the scenario stuck in an inconsistent state: the timer's chain doesn't necessarily have the knowledge to deal with whatever the first chain might have been doing when interrupted. The second option seems to me attractive, conditional on it not being difficult to implement and making sure that designers understand its implications. I can imagine that there are a number of simple things that a timer might do that wouldn't really interfere with other node chains containing a rest, like say, healing the party a little or some such, and it should be no big deal to let such things happen 'concurrently'. On the hand, there are big, likely plot-important node sequences designers might create which could interfere with each other in an ugly way if one included a rest and another was attached to a timer. One solution would be to simply warn designers about this, and leave it up to them not to build interfering code. Another might be to let a timer have a setting for what it should do it it would interrupt another node sequence, with possible options being to have it just run in the middle of the other sequence (fine for minor, non-interfering things), abort (fine for minor but interfering things), or defer until after the other nodes (for important, interfering timed sequences). This would be more technically involved, but would give designers a nicely fine level of control. Of course, there's always the last option, which is to leave the current behavior (which I assume is that timers are ignored during resting nodes?) and leave it up to designers to code around it. This is both the path-of-least-resistance and also might not be so bad, as this is a kind of odd edge case.

Shift+S should have previously been select instance, and Shift+Delete delete instance.

Originally Posted By: Nikki As a Windows-using BoA designer, can I just say that I do not particularly want a hundred-and-one shortcuts to select terrain, or to scroll the view, or to be able to search for a terrain by typing. I can already select terrain or scroll, with my mouse, and it really isn't that hard to find a terrain. What I do want are things like an undo function. A bigger view area (being able to see the same-sized area as a player would in-game would be lovely). A fill button. Those would be amazing. I'd like the "Clear All" tools fixed. I'd like the "place object" to keep the object I'm placing selected until I tell it to stop. And, most of all, when all that is done (because I'm sure a lot of it is), I'd like to know where I could find a STABLE, WORKING, and DOCUMENTED version of this editor. As it is I'm still using the Sourceforge build, because I don't want to download Ishad Nha's version, simply because I have no idea what I'd be getting. As grateful as I am to him for taking the time out to do this - and I am really stoked that we're getting the same awesome things the Mac users have - I do think he needs to know that there is a difference between making an editor to his tastes, and making one that will be useful to others. Just my two-pence worth. Undo/Redo is in and should be finished (In the non-Sourceforge version). The fill tool is programmed, but can't be put into the UI until we rearrange it as was done with the Mac version, as the additional buttons won't fit otherwise. The sticky object mode is easy to implement if we haven't already. These things are under way, but all require more of the precious resource of time. With regard to sticking with the Sourceforge build: I can understand this, and I would argue that the builds Ishad Nha has been posting are basically nightly snapshot builds, for the bleeding-edge enthusiast. We need to get a few more features put in and cleaned up and then we'll see about making a new release version that should be in good order for designers to actually use. (We will also hopefully be putting the Mac and Windows versions on a single download page again to cut down on confusion.) With regards to documentation, about the most that you will be seeing is release notes that describe what's been added. Jeff himself wrote 37 pages of documentation about the editor itself originally, which is markedly less than it needed. Add to that the fact we are still discovering new things as we look at the code, and that to usefully add material to a definitive document we would need to rewrite Jeff's documentation, and hopefully you'll see why this hasn't been done. I agree that it should be, but I for one do not have the time. (I did try to start, a year or so back, and still have, I think, the beginnings of a nice LaTeX document if anyone else really wants to pick it up.) This is also not a job that has to be done by a programmer; any user could write 90% of the necessary documentation and get clarifications from the people who work with the code.

I do not think that this is a good idea. The arrow keys are already used for moving the view (in the Mac version at least, and I think that the PC version should follow this, as it's what player/designers intuitively expect.) and are secondarily used to move the selected placed object. Giving them another meaning or changing their meaning would be confusing. Specifically, I don;t think that the described feature would itself, in isolation, have much use. When I go to select a terrain or floor there is a (sometimes lengthy) pause while I try to spot the one I want. Having done so, selecting it with the mouse is a very quick operation, while it would take additional time and thought to use arrow keys to move my selection from wherever it is to the item I now want to select. In short, I think that we don't need more or different ways to select terrains, floors, etc., but rather would benefit most from new and improved ways to locate such things within the palettes.

Quote: . . . I hope it will be intelligible and not use too much directx or opengl because those don't work so well on my compiler for some reason (Dev-C++). I would not count on the former, given what I've seen of the BoE and BoA Editor code. Not only was Jeff in a hurry while writing most of this code, I suspect, but he also seems to habitually use an indentation style that is, er, unlike any other I've ever seen. On the other hand, I think you can be pretty sure there would be no OpenGL or DirectX code, although I think this would be something we would work to change, as good, fast graphics for end users is a generally more important goal than ease of development. (Tridash is doing some tinkering in this direction with the 3D Editor, but it's still at an exploratory/experimental stage, I believe.)

It is at that. . . I should read that more often.

Quote: BASE_TRAP_XP and NUM_CHARS were not recognized by the module. Huh, you're right, those de seem to exist but be missing from the documentation.

What constants are unaccounted for?