Grimrock

Hopefully I did it, by keeping track of ids, and searching inventories, alcoves, containers and ground before reviving the projectiles, plus having a map for those projectiles who need to change (like magic arrows) or not to be respawned at all.

However I had to do it with grimq, so in the new version the LoG framework is mandatory.
Will upload in a few hours after more testing (everytime I test, I find something ).

Uploaded a new version which fixes problems with projectiles.
It also adds some new features:

EXTRA-DATA
==========
You can refer to a variable called "data" in monster hooks. It's a table. Put whatever you want there, that data is always relative only to the specific monster in the hook, and automatically released when the monster dies.

PROJECTILES
===========
Due to how the switcher works, it needs to know a little more data about the projectiles running in the game. In particular if a projectile should not be respawned if it hits the monster, it needs to have the following line:

defineAiSwitcherProjectileReplacement("projectilename");

If a projectile must be respawned, but in a different form (like "fire_arrow" which becomes "arrow"):

defineAiSwitcherProjectileReplacement("projectilename", "whatitbecomesname");

Standard magic arrows and quarrels are already defined by the main script.



NOTE: I had little time to test this, so please report any bugs and I'll try to fix them asap (which will likely be later than you think )

I tested, it works fine. By cons, between when the monster dies and when he gives throwing weapon, there as a lag of about a few seconds. Not visible on your little mod demo, but really visible on a larger mode (about 3 seconds in my mod)

Otherwise do I have to add the script to a script_entity as in the demo or it is already included in the lua? I think both works

Another question:
What is the "1202" in the print text: "appending contents of container 1202" (1202 or other number)

Thanks for the update.

Appending blah blah is a bug in the release of grimq in the framework.. don't worry it's just the print.

About the lag: it's because it does a whole grimq.find as opposed to a findEntity to check if the item still exists. This finds the item wherever you have put it, including containers inside alcoves and whatever. Since this is just to prevent a bit of cheating, I think I can use something in a next release which just checks the world, the items in the alcoves (but NOT inside containers inside alcoves) and into the inventory (containers included) which covers 99% of the thing in 0.1% of the time