*i

It could, but it would be impossible to preserve backward compatability in that case.

I've been rethinking (I didn't edit because it is a major shift in thought). That it would be better to just do one node. It sets a pointer to reference to a flag. If you change the value of the flag, the pointer value also adjusts. This way we do not need any comparison or other tests, just one node to reference. A loop structure would look like this: 1: Set Pointer 10 to reference flag 100,0 2: Set flag 100,0 = 0 3: Give Mage Spell (-110) [reference pointer 10] 4: Increment 100,0 by 1 5: If 100,0 less than 10, goto 3, else goto 6 6: Set Pointer 10 to reference flag -1,-1 (nullify)

To better answer your question, there are four nodes planned: Set Pointer: sets a pointer to a specific numerical value (which may be another pointer). ex1a = pointer ID (0-99), ex1b = value to set Pointer to/from Flag: transfers data from a pointer to a flag and vice versa. sd1,sd2 = flag. ex1a = pointer ID (0-99), ex1b = 0 for send value from pointer to flag, 1 for send value from flag to pointer. Note that set flag can do the send value from pointer to flag. Pointer arithmetic: does expression a +/- b = c. ex1a: pointer a, ex1b: pointer b, ex2a: pointer c, ex2b: 0 for add, 1 for subtract. Pointer c may be the same as a or b. Compare pointer?: Does a comparison of a pointer with a value (or another pointer). ex1a: pointer id (0-99), ex1b: value, ex2a: 0 for equal, 1 for greater than, ex2b: special to jump to if condition met. Total cost is four nodes. But it drastically expands the power. I thought about using flags, but as is we need two values to reference a flag which is difficult to port into one individual field.

Yes, the current nodes for manipulation are: Set Pointer, Pointer to/from Flag, and Pointer Arithmetic. I'm working on comparison ones now.

I've been thinking and I plan on introducing a new concept into OBoE that will drastically expand its programming power. A pointer is a value from -100 to -199 that when inserted into a node field references a value specified in an array of length 100. Why do we care? Because as of now it is impossible to insert a dynamic value inside a field. Suppose I want to create a node to give all of the level 4 mage spells. Currently I would need to create a unique node for each one. With the pointer, I can put a dummy value (say -110 representing variable index 10) of 0. After I call the add spell node, I can increment the value of the pointer by 1 and recall it until I have given all of the mage spells. I've done some basic testing and it appears to work. Before implementing this, I need comments. The one cost of this power is that it will break current save files. I may try to fix this, but I don't know how quite yet. Any comments or objections?

I have been playing around, and I have figured out how to give the ability of a monster type to call a scenario special node during its combat turn. This works sort of like START_STATE in BoA. I put it in the same place as radiating fields and summoning monsters. This modification is to combat.c I need to add more nodes to facilite better handling of this, but it should improve what people can do with their monster types. Comments?

Test.

Quote: Note: by "units" I mean the classes (C++), that still have to be designed (I have designed only those for the "generic" game engine up to now). Remember there is a fine line between elegance and readability. While the BoE code as is can be a hack at times, try not to go overboard with your classes as to make the whole thing unreadable by people without lots and lots of C++ experience. If in doubt, err on the side of readability. It is not a crime to use procedural logic if it is simpler for others to understand. Also, we should probably distinguish between the efforts in OBoE, which I see as a broad class to describe the various efforts going on. I'm currently making changes to the source code, more in the actual game side of things. If you deal with that at all, make sure you keep things distinct between the two efforts. OBoE specifically is not meant to be forward compatable. In other words things created in BoE will work with OBoE, but not necessarily the other way around. Anything that is still compatable in every way with the old BoE, should just be a subsequent release of BoE. If you want to do something different, I would ask (nicely) that you select some way to distinguish your OBoE project from the one I am doing. It's likely the two would be combined eventually. Since there are compatability issues already in OBoE, (things created in it will not work in BoE) we should distinguish or plan to combine or something.

I'll give it a look.

I don't recall a Tower of Magi in Nethergate.

You are correct, I was quick with my words. Either way, you know what I meant.

I just made a few changes to the Give Mage Spell and Give Priest Spell nodes. All of the modifications were to specials.c. The changes are as follows: 1) It is now possible to access the level 1-3 spells. The index for these is 100 + spell number. 2) It is now possible to take away spells. If the extra1a field is <= 0, the spell is given, if it is >= 1, takes it away. Comments?

Primarily because that's how Jeff had it. The -1 is there for backward compatability.

Bain posted this earlier, but I made a new one. Preliminary rules are as follows: The deadline is August 1, 2008 at 11:59 pm board time. Scenarios from both Blades of Exile and Blades of Avernum will be accepted. The categories will likely be similar to last time including Newcomer category. To be eligible, you must not have had an entry in a previous annual contest (does not include short scenario, 1/10, or other "themed" contests). More to follow later.

Hello. This topic is to discuss ideas on how best to document the changes made in OBoE. Do people have any ideas on a good way to do this? Node limit has been removed. Command key is an interrupt allowing a quit option during node execution for debugging. Petrification touch has been added/fixed. Select PC now allows random PC selection by CPU. Town Hostile node has been changed to a Set Attitude node. Give Mage and Priest Spell nodes now have ability to access level 1-3 spells as well as take any spell away. Town visibility node has been fixed. Version of OBoE is stored at beginning of save file for better tracking. Pointers to flags and associated values allow variable-like input to nodes. Campaign flags allow communication between scenarios. Relevant affect PC nodes now affect monsters as well. If a monster dies during a node, it will no longer throw an error. Likewise with any other special called during a special execution.

I modified the town hostile node into a set attitude node. It still behaves like a town hostile node under the default behavior (all fields -1), but allows the user more control of the attitude of the creatures. The following functions were modified: items.c :: a new function set_attitude was created. items.h :: added void set_attitude at bottom specials.c :: node call goes to set_attitude instead of make_town_hostile The behavior is as follows: Extra1a: Specifies lower monster limit (-1 for first monster) Extra1b: Specifies upper monster limit (-1 for last monster) Extra2a: Specifies attitude (-1 = hostile type A, 0 = friendly, 1 = hostile type A, 2 = neutral, 3 = hostile type Any comments?

I have just made a modification to specials.c to the Select PC node. This node now has the option (if field extra 2a > 0) to have the computer randomly select a PC rather than the player choosing one. This gives the player to randomly target PCs, and is valuable in things like special spells. Comments?

Protection from petrification items give immunity to it, of course.

That's a design choice and you can penalize scenarios that use it too heavily. However, I don't see why it shouldn't be an option. It definitely can make fights interesting.

You are correct, I already removed it. I'm not sure why Jeff did that, a placeholder perhaps?

Turns out Jeff outright forgot this one. I coded it up myself in combat.c. For a chance of being petrified I did this: r = (random # from 0 to 100) - target level + 0.5*attacker_level if (r > 60) turns to stone Petrification resisting items and magic immunity protect. Are people okay with this?

Update: I took out the node limit entirely. It is now possible to quite the game during a node sequence by hitting the command key during execution. The same dialog for the quitting in combat comes up with options to quit or cancel. I wanted to make this nicer, but I had trouble getting it to handle menu commands. Basically, this is primarily used as an emergency feature for infinite loops, so I didn't want to put too much effort into it. The following changes have been made to the code base: run_special in specials.c has been modified. Node limit has been added, num_nodes has been changed to type int, and a call to a new function node_interrupt has been added. node_interrupt has been added to bldsexil.c that checks for the interrupt of the command key and gives the quit prompt. This was also added to bldsexil.h. I'll send what I have to Khoth. I think this is probably good. If anyone wants to make it better, feel free, but I think I am (for the most part) finished with this part of the project.

I guess I hate to ask, but is this the stock issue Blades of Exile Scenario Editor, or one of the compatability updates that people (esp. Khoth) have been doing?

I'm finding grep to be a very good friend in this endeavor.

Sounds neat, could you enlighten us on GtK+ a bit. I've read the wikipedia article on it. However, could you specifically state what you want to do related to BoE? Thanks.