*i

This is probably due to the way Blades formats the object. Try making the object a few tones lighter and see if that works.

Anyway, people need to assign priorities or we'll just give him the list as is.

DISPEL_BARRIER_STATE would be nice if it could be incorporated into creature scripts.

It also gave you ways to complete quests like the Healing Scepter without going all the way back through the upper complex.

Very nice. Would you be so kind to donate that graphic to the Louve and the graphics competition?

Okay, when you display a ood amount of text on the screen and are often offered choices, that is considered a dialogue box. Right now, it is impossible to put an image to go along with it. Play the old Exile games and you should notice a picture of a Slime by the text or something. We're really asking for this nice feature back.

Here is my list: 1.1 - TP+ (if nothing else, this one) 2.1 - TP 3.1 - WBN 3.2 - WBN 3.3 - NL 4.1 - WBN 4.2 - TP 4.3 - NL 4.4 - NL 4.5 - WBN 5.1 - WBN 5.2 - WBN 5.3 - TP 5.4 - NL 5.5 - WBN 5.6 - WBN 5.7 - WBN 6.1 - WBN 6.2 - WBN 6.3 - WBN 6.4 - WBN 6.5 - WBN 7.1 - TP 7.2 - WBN 7.3 - TP 7.4 - TP 7.5 - NL 7.6 - NL 7.7 - NL 7.8 - NL 7.9 - WBN 8.1 - TP 8.2 - TP 8.3 - TP 8.4 - WBN 8.5 - WBN 9.1 - WBN 10.1 - NL 10.2 - TP 11.1 - TP 12.1 - TP 12.2 - WBN 12.3 - TP 12.4 - WBN 13.1 - NL 14.1 - WBN 14.2 - WBN Also, having varibles preserved after reloading would be very, very nice and save a lot of trouble.

Welcome back, Aceron. Glad to see you back visiting again.

It's been a while, but try putting in a special after the stairway node in the chain, call it 'n'. (pick any number here between 0-99) Go into the next town you are linking and under node 'n' put the text description there, NOT in the original town you came from.

One limitation is you cannot make custom scenario icon graphics.

Matrices and vectors allow you to create a temporary, variable, and convenient ordered data structure. The problem I am having is that I want to store a variable number of components in creature scripts. Regular variables will not work unless I define a lot of them to ensure I don't run out under any situation. Here are some advantages: * Of an arbitrary size (only 30 for SDFs) assuming Jeff doesn't program stupidly. * Are created as a temporary file specific to a script and does not require reserving large numbers of flags. * When you have them in different, it would be hard to keep track using flags and you need to be careful not to overwrite and spill over. * Vectors and matrices should be able to store integers instead of just values 0 to 255. Okay, I admit there are ways to do this with flags, but I'm having a hard time trying to organize it and I suspect other players will as well.

The only reason I design in Blades is because of the community, because there is an audience. That, and it's good to have a hobby. Blades of Exile is not dead, maybe to Spiderweb it is, but to the community, it is not. I will probably not design in it anymore, but there are still a LOT of good works in it. Actually, I think Jeff and co. don't think they've abandoned it, they just drastically underestimate the amount of service time that is required. Seriously though, they should really remake their Blades of Exile page with pointers to the big resources for it. I think it is time they stop pretending to service a product they don't really want to and aren't really doing. Also, BoE, the game and editor, should become open source software. They can still sell and market it for those without a compiler and the donations can still make them money. But seriously, so much has changed about the engine that it really doesn't matter anymore. It would be nice to be able to rip through the guts of that program and maybe even fix a few features that don't work. However, they'll give you the Monopoly argument. I hate to say it, but that is a false analogy because board games really do not get outdated. Perhaps we will reach a time when computer games will NEVER become outdated because we will have maximized all that can be done with computing, but I doubt that will be for many centuries. Those are my feelings at least.

Kel -- Think you could give everything a numbering system? For instance 1.0, 1.1, etc. for the first category, 2.n for the second and so on down the list. It would make things easier to talk about and vote on. Should variables be disallowed in the run_imported_script() calls? How will they be handled? I've always assumed this would be like call_global_state().

If you want to take the time to build something, go ahead. The community can always use duplicates of something in case something falls into the void of cyberspace.

Spell libraries wouldn't be necessary, but just serve as a way to tell which spells we want a certain monster to use. Of course, this is probably not implementable anyway, so I would put priority as quite low. I suggested it as an alternative to the deny_spell() command which seemed limited. Kel, think you can modify the set_immunity call such that it reads: set_immunity(immunity_type, value);

The ever so helpful Linda Strout of course.

More suggestions: Data storage and Manipulation vector v1(n) matrix m1(m,n) Placed in the variables section. Creates either: a vector array of size (1xn) or a matrix array of size (mxn) to store data. If full matrices are too much, vectors would be fine. v1(i) m1(i,j) Returns the ith component of vector v1 and the i,jth component of matrix m1 respectively. General Calls run_imported_state(file_name, state_number); run_imported_state_continue(file_name, state_number); Runs state state_number out of file file_name. The former call ends the current call whereas the latter finishes the given call. See set_state() and set_state_continue. Improved Spellcasting Calls If we want to suggest something that can modify the way creatures cast spells, why not make it a bit more streamlined. cr_spell_lib(file_name) import_spell_lib(file_name) Placed either in scenario data script for the former and in the INIT_STATE of creature script for the latter. Gives a range or library of acceptable spells to be cast which is stored in a text file like a script. If call is not given, defaults to some default spell library. Use of this call in a creature script clears the current creature's spell library. add_spell_to_lib(mage_or_priest, which_spell, spell_level, spell_frequency); Adds spell (mage spell for mage_or_priest = 0, priest spell for mage_or_priest = 1) which_spell at spell level spell_level to the library text file. Monster casts the spell seldomly for spell_frequency = 0, uncommonly for spell_frequency = 1, and commomly otherwise. I'm not sure if these are implementable or not, but it should be a good way of modulating what spells creatures can cast.

You could always do something like: Code: i = 6;while (i <= 60) { change_spell_level(); i = i + 1;} I can't recall the exact call that changes spell level right now, so I could be wrong on that. Put this in the entry state with each spell you want to omit and you should be fine. Just make sure summoned creatures cannot be casters or place it to run periodically in the START_STATE. But seriously, the real problem with deny_spell() is it requires engine modification to the coded spellcasting AI. This is very unlikely to happen as it will create version problems among the games.

I'm still not convinced that it is even doable without major engine modification, let alone necessary. This seems like a MAJOR modification for such a little gain. What will significantly be improved by it? All I see now are periferal things that could be done other ways. Keeping the list reasonable is the only way we have of this being considered.

If the player wants to cheat, they will find a way. If the only reason for deny_spell() is really to ensure against that, then there is no reason for it. If players want to cheat, let them. It's their loss.

One call that would be nice: get_immunity(immunity_type) Returns a value from 0 to 100 depending on the assigned immunity value. set_immunity(immunity_type) Sets a value from 0 to 100 to the immunity_type. It is possible to remove spells from an NPC using the change_spell_level() calls. Although this call would be nice: cast_spell(mage_or_priest, which_spell, spell_level, is_forced) For creature AI scripts only. Causes the creature to cast spell which_spell at spell_level depending on mage_or_priest regardless of mage or priest spell ability. If is_forced is 0, the spell is only cast if the creature has enough spell points, otherwise the spell is always cast.

I was around since the beginning of Blades of Exile with people like Derin, JtP, Aceron, Akhronath, etc. Zaloopa actually joined after the community began, I remember his entry into the community with his failed mailing list. The way I see it, we have the following ages: Antiquity -- Anyone around at the beginning back in 1997. The Aceron Age -- Anyone who participated on Aceron's message board would qualify for this. The Lyceum Age -- Anyone who joined post-Aceron, but prior to the creation of Ikonboard. The Ikonboard Age -- While Ikonboard was around. The UBB Age -- Our current age. Can someone put some dates on these?

The reason for polls being removed for the time being is that they take up way too much of the server space and UBB provides no easy way to purge them.

Kelandon -- Would you be so kind as to add it to your list of "calls" in the suggestions post? Thanks.

Yes, very nice. Thank you, Kel. And yes, I do mean the lighting level that the party has produced. A get_light() command would be nice as well.