spellbook changes via usecode?

[Profho]

Hi everyone!

I'm writing a mod (for Serpent Isle) and decided to include new spells.
I found out how to replace the "old" spell functions via usecode but am
facing problems with adjusting the needed reagents (and availability) for
the "new" spells.
Is there a way to define the needed reagents for a spell via usecode (yet)?
Or do I have to stick to the predefined values set for the old spells?


Thanx in advance,
Carsten.

P.s.: As this is my first post I want to thank the exult team for their
outstanding work. I would never have been able to even think about writing a mod without it: Thank you.

[marzo]

Is there a way to define the needed reagents for a spell via usecode (yet)?
Or do I have to stick to the predefined values set for the old spells?

No, it is not possible to change the requirements. You can add back reagents, but the player would need them to cast the spells beforehand.

[Vasculio294]

So are you saying, that you can bring back the resurrect spell?

[Profho]

Yes, you can bring back the resurrect spell.
I'm pretty sure as I did so

A few spells seem to be a lot more difficult - if not impossible:
How to write "wizard eye" when the usecode compiler keeps telling me that it doesn't know "UI_wizard_eye" ?^^

Either I still have to learn a lot about usecode (which is quite probable) or the needed intrinsic just wasn't implemented.

[marzo]

How to write "wizard eye" when the usecode compiler keeps telling me that it doesn't know "UI_wizard_eye" ?^^

Either I still have to learn a lot about usecode (which is quite probable) or the needed intrinsic just wasn't implemented.

It is because this intrinsic is BG-only. See here for the full documentation of all Exult intrinsics.

[TdI]

>It is because this intrinsic is BG-only. See here for the full documentation of all Exult intrinsics.

And for a good reason too. Having Wizard Eye would reveal some of the game hacks and the "corrupt" state of the world.

[Profho]

Thanks for your help / answer(s) so far, Marzo Sette Torres Junior.

After reading the file I still have some questions though:

- The compiler claims not to know "UI_stop_time" although this intrinsic is
(in the file you linked to) not classified as BG-only. Looking up the spell
in the Serpent Isle usecode file I had the impression that the spell stop
time is supposed to always fail - am I getting something wrong here?

- I would have liked to create a new spell: levitate all. My problem
was / is that I couldn't find a way to set the flag "fly". I found a file
declaring the flag "fly" (among others) as "type flag" - is there a way
to set those via usecode?

- As I tried to write a longer sequence of events in a usecode function
I was pretty surprised that the game seems to get ahead of itself:
sprite effects are interrupted by conversation parts e.g.
Is there a way to force the game to wait and execute one thing after the
other? (besides "after x ticks call 'nextfunction';")

[marzo]

The compiler claims not to know "UI_stop_time" although this intrinsic is (in the file you linked to) not classified as BG-only.

Edit: The marker is there indeed; but due to the fact that I (for some deranged reason) aligned the symbols with tabs instead of spaces, and that tab-size is 4 in my editor, the symbol is farther out to the right than it should. I will make a revised version of the doc correcting this.

My problem was / is that I couldn't find a way to set the flag "fly".[...]is there a way to set those via usecode?

No; it is shape-dependent.

As I tried to write a longer sequence of events in a usecode function I was pretty surprised that the game seems to get ahead of itself: sprite effects are interrupted by conversation parts

This is because usecode doesn't estabilish a time-sequence for the functions (such as, e.g., Baldur's Gate scripts do): while the commands are executed in the specified order, and can depend on previous commands for their results, all their visual and sound effects happen at the same time.

Is there a way to force the game to wait and execute one thing after the other? (besides "after x ticks call 'nextfunction';")

Basically, script blocks. They can be used to create animations, but they are a 'sub-language' of their own inside UCC. I had a tutorial in ESGuides, but the site is down; I will add it to the Exult CVS, but in the mean time you can get it here.

[Profho]

Thank you - exactly what I was searching for.

Thanks to your help I begin to believe that completing this mod is
"only" a matter of time (and will) after all.

[drcode]

BTW, allowing you to change the reagent requirements is something we'd like to support in the future.

[Profho]

I'd be very happy if you talked about the very very near future


back to the wizard eye spell once more...:
I tried to write a work around and would like your ideas and comments on this:

The basic idea is to combine the set_camera intrinsic with a "remote control" for a char:

At first I created a new shape with 32 see-through frames.
Next step was to aplly this shape to a npc.
When the spell function for wizard eye is called via doubleclick I move this npc to the Avatars position.
(The npc is ethereal, can fly, swim etc)
Next is to set a global flag (wizard_eye_active in my case) to true.
In the Avatar's usecode I define that if this global flag is true I expect a click from the player (UI_click_on_item).
The see-through char is supposed to walk to the clicked-on position then.
To continue the remote control I need to call the Avatar's function again (<== not really sure about this part.)
until the amount of x ticks has passed and the scripted part of the wizard eye spell reverses the whole process.
If I'm not mistaken this should be quite similar to the wizard eye spell.

But this is just theory yet.
Before posting I tested this and as a result the game instantly crashes when I cast the spell.^^
(no complaints from the compiler though...)

Does anyone know why exult crashes? Or may be you got any ideas how to write wizards eye another way?

[marzo]

BTW, allowing you to change the reagent requirements is something we'd like to support in the future.

And it is something which is in my to-do list, along with a Gump manager (which would be required for effectivelly allowing additions of spells in the spell book instead of replacements).