Grimrock

Maybe it's the framework version that changed something - I'm on an older one and maybe the newer one is doing something differently with loading of modules.

But if I understand correctly, fw_addModule("exsp_default_log_spells") should create just an empty script entity...

Try the init like that, importing directly the two exsp luas:

well, nothing changed without addModule, importing lua works fine i suppose

here is crash log, first line brought me an idea, that the definitions are not loaded properly, so i tried to put them in that init.lua (but maybe its total nonsense )

Ok, I installed the latest version of the framework, and indeed it doesn't work anymore for me either. So I have to get in touch with jKos to see what happened. It has something to do with loading of modules and initialization. The "default spells" modules tries to call a defineSpell function in the exsp module, but for some reason it's not loaded yet (it was working fine before ). That's certainly where your original "duplication" bug came from. I'll look into it tonight.

Hi Pecen,

I've updated the lite version to 1.5.1, which should fix the problem: https://drive.google.com/folderview?id= ... sp=sharing.

Delete all the exsp folder, unpack the new one, and just import the exsp_init.lua at the end of your init.lua.

Yes, now it works almost fine, but you miss to add .lua at the end of exsp_init.lua, next version will be perfect
And for my curiosity, the catch was in adding autoexec function to defs, is it right?

Exactly.

It didn't have the autoexec, so that the default spells could be loaded before potential custom spells (which had an autoexec). It's because you need to call defineSpell() before any potential cloneSpell()... It was working fine before, but now it seems all calls to script entities put with fw_addModule have to be made after everything has been loaded. But adding the autoexec was not an issue for EXSP Lite for now as it's not meant for using the spell plugins system.

I'll think with Xanathar and jKos on how to handle the load order issue for the full EXSP.

PS: Thanks for the little error catch, I'll update the file .

That's weird, I didn't change anything which affects to the load order (as far as I know anyway). I just added one init-function call and replaced the timer which calls the logfw_init:main-method with pressure plate.

Hmm, well I fixed it anyway, script entities are now spawned in same order as they are loaded, I thought they were spawned in that order, but apparently they weren't. Maybe I have done some stupid changes by mistake, don't know/remember anymore

Just download the newest version of my framework and it should work (link is in my sig).

I was using the spells in EXSP in a test dungeon (that I had exported) and encountered a problem that I can't see a way around (with my limited scripting knowledge):

They don't always grant exp.

I think it might be a small timing issue between the spawning of the damageTile and the execution of the spell itself, because most of the time the spells (both default and custom) grant exp, but sometimes they don't. All spells have a chance of this occurring whether its a simple fireburst or a more complex spell like ice cone or energy beam and it happens with all types of creatures. It really doesn't impact what I'm doing as I like the limited range of spells the game already has (with the possible exception of the lack of a healing spell) but I thought I'd mention it regardless.

The spells are nice however.

EDIT: Of course, I haven't ruled out the fact that one of the modules might not have been loaded correctly or that one of the other mods I was using might have negatively impacted on the framework.

Yes, unfortunately, there's no hook to trigger when a spell hits a monster, and I had to resort to complicated mechanics to get the same result, but they rely on timing issues so they are not a 100% reliable. As the main detection is on a onGui timer (the fastest possible in LoG), the faster your frame rate, the more reliable it is.

What happens, in detail:

1. Each flying spell scans what's in the tile ahead of it on each frame.
2. If it finds a monster, it registers its id and matches it with the spell's id.
3. If a monster is hit (triggered by its onDamage hook), it checks if that monster's id was registered by a spell.
4. If yes, and that spell doesn't exist anymore, it deduces that it was that spell that hit the monster and
a) cancels normal spell damage
b) triggers the onMonsterHit hook
c) reapplies damage via damageTile with the champion's ordinal
5. If a monster is immune to a damage type, there's a secondary check which triggers when a spell that is tracked disappears. If the spell sees a monster in the front on one frame, and the spell doesn't exist the next frame, it deduces that the spell hit the monster and does the steps in #4.

As said earlier, little timing issues are inevitable with that. At least, it's a few xp lost, not game-breaking...