Niemand

We have that already, you can do better than just sizeof and also use offsetof to examine structure layouts, which I did (See this post for details). The numbers of bytes by which we're off are large enough that I'm not sure I'd blame padding alone, although we've been trying to get that under control from the start. The job isn't impossible, as in theory we could always add enough padding bytes to both platform's definitions to make them match, but it would likely just be better, given that we can distinguish the two platform's files, to just have separate reading routines to handle them, if we can determine what the important differences are. In part this has stalled a bit since I hadn't gotten around to trying to do the same layout examination of the structs from the Windows side, so so far we've only seen half of the picture.

Is five dollars such an impossible amount? The pricing may be a little odd, but it hardly seems a matter worth getting upset over.

Cake It's only a cheap, store-bought one, but hopefully this rectifies a mistake which has apparently gone unnoticed by me for years.

You know, you can always release an updated version of your scenario to correct plot mistakes or clarify things that players misunderstood. You don't have to do so if you don't want to, but you also can if you don't feel that your scenario is living up to its full potential. The major alternative, which you seem to allude to above, is to just take the mistakes you made and learn not to make them again, which is certainly a key skill in any line of work.

In the Mac version of the game use the Options > Party Location menu item. I don't know if there's any way to get the coordinates in the Windows version.

The coordinate system is easy, if unintuitive: The NW corner of the town is point (1,1), with the x coordinate increasing to the East and the y coordinate increasing toward the South. I fear I don't recall all of the details of the puzzle, but I believe it hinges upon destroying the three ctrystals on pedestals in the NE, SE, and SW corners of the town so that the key bearer can't escape when you try to kill it.

Quote: Being on Windows I don't know exactly what Niemand's program actually does or how it works. I could have a stab at porting the source code to Windows What it does is load all of the PICT resources (graphics sheets, as far as BoA is concerned) in a cmg file, let the user pick one and pick an icon from it, and then display all 1024 possible adjusted versions. I would be happy to see an equivalent windows program written, and my source code is of course available, but I would warn that essentially none of it is directly reusable: it's virtually all user interface and graphics code that would have to be replaced to deal with the completely different libraries supplied by Windows. Also, the code itself has some rather sloppy aspects that shouldn't be imitated. Since the 3D Editor already does most of the necessary types of work (loading images, producing adjusts, and drawing on the screen basically), it should be possible to scavenge bits of its code for a starting point.

Exporting to a text file wouldn't assist the player all that much, in that it would still be up to the player to assemble and organize the text, although it might be better than nothing. Some thoughts on the matter: In order to index things neatly, they need to be labeled. Do you make the designer provide labels that are used when storing text? Do you attempt to auto-generate labels based on the context (Seems like a tricky thing to do, but impressive if done right)? Make the player enter labels when recording text? Do entries persist forever, must the player manually remove them, or are they automatically purged? For instance: what if the player uses the same party to play a scenario twice, possibly making significantly different choices the second time through?

I didn't figure you would, but for completeness I had to mention it.

There must be some cap as long as one uses standard integer types. In this case, Jeff used a signed 16 bit integer to store the amount of gold so there is a fundamental limit of 32767 (2^15 - 1). He likely just decided that it would be easier for players to remember if the limit were set at an easier to remember number. What CM plans to do, I think, is to reclaim the sign bit of that integer (since amount of gold never needs to be negative), allowing the stored amount of gold to go up to 2^16 - 1 or 65535. In general there are two alternatives to handle bigger numbers: The first is to use a wider integer type, which even on current computers is only practical up to requesting a 64 type as no commonly available CPUs have (non-vector) registers big enough to hold anything larger. The second is to implement one's own arbitrary precision type, which will entail far more programming work and cause arithmetic to be much slower, as operations will require many CPU instructions working on smaller chunks of the data.

I think he probably means the ones at the start of this thread; they do go somewhere, but neither points to the advertised zip archive.

Actually, that's already been done: there is a general town base class, and subclasses of it exist for the current specific sizes. At present, however, the base class is abstract, so while it has the entire interface for arbitrarily sized town, it disdains to supply an implementation (either that or CM does ). This would be pretty easy to rectify; the tougher problems would be making the save format handle arbitrarily sized towns and setting up the user interface to create and manipulate them in the editor.

Quote: The thing is, dynamically allocating a two-dimensional array is a little tricky. So I'd prefer to avoid it. It not that hard: Code: int rows, columns; //somehow set rows and columns//with the STL: vector< vector< foo > > array1; array1.resize(rows); for(unsigned int i=0; i<rows; i++) array1[i].resize(columns);//with pointers: foo** array2; array2 = new foo*[rows]; for(unsigned int i=0; i<rows; i++) array2[i] = new foo[columns]; //deletion is just the same process in reverse (Disclaimer: I just stumbled out of bed, so those examples may be flawed, but the basic concept should be sound.)

Did you kill anyone there the first time? As I recall, if you kill anyone it will be discovered while you're gone and everyone will hate you when you return. However, that very mechanism might have a bug, which would cause everyone to hate you the next time you entered the town. Anyway, if you still think it's a bug (quite possible) and you have any more details, please send 'em to me; I've been considering revisiting and updating that scenario anyway, and bugs must be crushed.

I would argue that the level ranges aren't stupid at all in concept. They are exactly 'expect to enter at around this level' phrased as a range of levels which should more or less be workable. What's foolish is when designers make them too wide, as it dilutes their meaning. As I recall, I never really got the combat in AVM to be as challenging as I wanted, so I doubt it will kill you if you're a bit under-level.

I think that this should be a rule, and in the past I have deliberately tweaked the vampires' summon level so that they can't summon themselves. It's not too hard to just adjust each creature's summon level so that it is more difficult to summon than anything which it can itself summon, which is logical as well, I think. I agree with Dinti that summon cascading is a nice effect that shouldn't be strictly eliminated. (The other place where it goes bad in BoA specifically is when it hits the rather low ceiling for number of summoned monsters, so that nobody can summon anything. Ogre mages are the alternative culprits to vampires for this, since they use summoning spell a lot, and can themselves be summoned, although they at least cannot summon themselves.)

Your problem is, I think, the line in the documentation which says: Quote: This call only has an effect when it is called as a result of the party encountering a group of creatures outdoors. If you want to use this call, I think you need to set the encounter to call an outdoor script state when met, and put the call in that state.

It made a major appearance in the Empire Archives in A2.

I've just checked in changes which should alter the 3D view size to match that used by the game itself. I think I got all of the relevant changes that were need to make this work, but somebody should check me to make sure i didn't overlook something. Glancing over the ToDo list of major changes we have: (struck through items are completed) Add Undo/Redo support Correct 3D view size Rearrange tool buttons in order to... Add eyedropper, floodfill, terrain copy, and terrain paste tools Add creature and item palettes Fix crashing in BoE import feature(*) Replace delete last town feature with delete current town Add change town size command Fix Change Outdoors Size to not scramble data(**) Add list views when selecting town/outdoor section to load and when selecting town/outdoor section to import * If I understand correctly this is fixed. ** If I understand correctly this is a problem. Am I overlooking anything important?

Quote: Well, when you guys were updating the Mac version, you did have the opportunity to do all that. You guys just didn't take it, that's all. The opportunity (to abstract out platform dependencies) has existed since the code was released, and hasn't gone away. However, it is a very large task, and players were clamoring for executables that ran, bug fixes, and feature additions. Quote: Also, considering that you guys used Carbon for the Mac version, something eventually will need to be done, since that API has been deprecated for quite a few Mac OS X releases and is probably scheduled to disappear soon... The game was already written with Carbon, that was not a choice made by the open source developers. Also, that framework is not deprecated, try reading the relevant documentation. While is does appear that Apple may deprecate it in the future, that hasn't come yet, and switching BoE away from Carbon would require rewriting a vast amount of the code. It would also preclude merging with the Windows source, since it would involve rewriting the game in Objective-C. (To switch to Cocoa. Your other choice is to use a multi-platform library like wxWidgets or Qt, which will still entail a huge amount of work.)

Quote: Alorael, who picked up some Brandon Sanderson books and found the writing rather unbearably poor. This makes him worry about the Wheel of Time, which he still likes even while everyone else hates it fervently. I find this odd, as I liked Sanderson's writing just fine. (I agree with you in liking the Wheel of Time books, though; while some were better than others I found them all worth reading at least once. It just seems to be fashionable to dislike them.)

Though short, it contained much interesting action, and was very much to my satisfaction.

*Sound of head hitting desk* I wish somebody had pointed that out sooner. Oh well, it was fun math problem, and I may look into the details of the effects that the manual doesn't describe quantitatively.

Inspired by Nioca's recent research, I decided to revisit a problem that I first started working on some time ago, namely spell formulas. So far I have derived what I believe to be a complete formula for the damage inflicted by Bolt of Fire. Method: All spells were cast on a completely unarmored, level 1 goblin, defined thusly: Click to reveal.. Code: begindefinecreature 255; import = 21;begindefinecreature 21; clear; cr_name = "Goblin"; cr_level = 1; cr_default_attitude = 4; cr_species = 1; cr_which_sheet = 1521; cr_summon_class = 1; The caster was my usual guinea pig, Ampersand, a level 1 character with utterly minimal skills. Certain skills were boosted in small increments to determine their impact. In order to determine a damage formula, I made certain assumptions about its general form. These were: -Only positive integers are used in calculations -A non zero number m of dice with side values [1,n] with n another positive number -A non negative constant may be added to the sum of the dice rolls I did not allow for dice to have side values beginning at a value larger than 1. While I don't have a proof of this, my scribblings indicate that doing so leads to no increase in generality. With these constraints it is possible to enumerate all of the possible dice combinations which could produce an observed distribution. Denoting such a combination as [m]d[n]+[r] where m is the number of dice, n is the number of sides, and r is the added constant, the mean of the resulting distribution is in the range [m+r,mn+r] with mean µ=(m+r+mn+r)/2=(m(n+1))/2+r. This last expression can be solved for n to give n=(2/m)(µ-r)-1=(2µ-2r)/m-1. We can place conditions on the set of dice based on the range of the observed distribution; these would be exact except in real sampling the tails of the distribution are difficult to resolve, so the best we can do is to require that the range of the theoretical distribution be greater than or equal to that of the observed distribution. Letting the observed minimum and maximum be a and b, respectively: m+r≤a, mn+r≥b. These conditions will be redundant, either being of equal strength or with one being stronger than the other, so we can just choose to always use the stronger one. Assuming that this is the minimum condition (if the maximum condition is stronger we can rewrite it as though it had been the minimum condition) and using the assumptions that r≥0 and m>0 the possible solutions are confined to a right triangular area on the mr-plane. For each of the m,r pairs in this area we can compute the required value of n from the mean formula (n=(2µ-2r)/m-1), noting that we can additionally reject all pairs for which 2µ-2r is not evenly divisible by m. (This form in which the 2 has been distributed over the difference is useful because µ may be half-odd-integer and this form allows us to work exclusively with 2µ so that only integer math is required.) Having listed all (m,n,r) combinations which could produce the observed results it's fairly straightforward to evaluate which is the closest fit to the data. At the moment I simply evaluate the theoretical distribution of results from each set of dice by brute force, tallying up every possible combination. These distributions are then compared to the data using a chi squared test. I'm not implementing this test quite correctly at present, as apparently it's supposed to be done only on counts not of proportions, but i don't think this makes a material difference since I ignore the magnitudes of the resulting values, as I only need to compare them relative to each other. Results (So far): At this point I have only had time to collect data on the Bolt of Fire spell's dependence on the caster's Intelligence, Mage Spells skill, Magery, and spell level. The raw data, along with the code of the analysis program can be downloaded here(8 KB). Many goblins died to bring us this information. (Over 3000 of them.) Since a character cannot have less than 2 INT and 1 MAG and 1 level of the spell are required to cast it at all, this was my starting point. I tested 10 settings listed here as INT, MAG, Magery, Spell Level: Code: Setting Formula-----------------------2,1,0,1 2d4+32,1,0,2 4d4+32,1,0,3 4d5+6 (6d4+3 is a close second fit)2,1,0,4 8d4+33,1,0,1 2d4+44,1,0,1 2d4+52,2,0,1 2d4+42,3,0,1 2d4+52,1,1,1 2d4+42,1,2,1 2d4+5 This implies that the general formula is: Code: Bolt of Fire damage = (2*Spell Level)d4+(INT+MAG+Magery)

The docs do contain charts covering the same topic as Nioca's first chart, yes. (I had forgotten that.) However, they do not contain most of the data that he posted as best I can tell. There is, however, a curious discrepancy between Jeff's and Nioca's charts for selling items; Jeff claims the effect of different sell_adjustment values is far stronger than what Nioca shows. I suspect that the documentation may not be in agreement with the software.