Exult Forum

I have a (couple of) question for modders based on the changes I am working on, and some I *might* make depending on responses: have you ever used patches to "shape_info.txt"? If the answer to the previous question is "yes", have you ever used patches to the "animation" section?

The reason I am asking is because I am considering replacing the current system with one less powerful than it, but still capable of doing everything the originals did and a bit more. The new system would not be compatible with the current one, though, which would break any mods which use patches to the above section of the aforementioned data file -- and which is why I ask.

The major reasons for the switch would be that (1) the current system is far more powerful than I think will ever be needed, (2) it would be much easier to add editing capabilities to ES for the new system I am thinking than it would be for the current system (a couple of orders of magnitude easier, more or less). Since I *am* adding editing capabilities for ES for most (if not all) data it does not yet edit, the latter reason is very persuasive for me

Although not a heavy modder I suppose I am a modder regardless.

But no, I have not used that file (yet ).

I used some that didn't work. They were basically copy pasted from BG and just changing the shape number to what it should be. I never really messed with it much and just ended up deleting them so it won't affect me. Will this also help fix the broken animation problems that pop up once in awhile?

Will this also help fix the broken animation problems that pop up once in awhile?

What broken animation problems?

Well, like when the shorelines desynchronized in SI.

It will make no difference, as that particular problem was fixed long ago.

I have no experience with those files yet, as I am mainly working on graphics for different themes, in order to continue to improve in my Ultima VI-VII-style artistic abilities. Though I am curious as to what new things we shall be able to do. I have many ideas which will lead to questions about E.S., though I was waiting to get a certain amount of graphics assets completed first.

But since it is brought up...

One question is, will we be able to have more than 32 frames of animation for objects that rotate? 32 feels rather limited. And another would be, can we assign a different set of animations for certain equipped weapons? For example, a ranged weapon not being swung like a melee weapon, but rather a new set (if drawn by someone) for ranged weapons? One project that I am working on has far more ranged weapons than melee.

One question is, will we be able to have more than 32 frames of animation for objects that rotate?

If I understood you correctly, the answer is 'no'.

And another would be, can we assign a different set of animations for certain equipped weapons?

You can already change the specific frame sequence for each weapon (from a limited set of choices), but the frames used are the same in all cases.

Neither of these answers is likely to change anytime soon.

Thank you Marzo, for the reply! I'll probably put my sci-fi/modern-era projects on hold then, at least for now. Some guns just look way to silly being swung like a two-handed sword, plus I was hoping to add gun-flashing animations for some of them.

The question about the 32 frames was referring to a post where you mentioned to me that more than 32 frames would be tricky for objects that rotate, but objects that are stationary with more than 32 frames (monitors, flickering flames, etc.) are working ok for me.

Re: The question about the 32 frames: Yes, I thought you meant that. Note that objects with more than 32 frames can (theoretically) animate, they just can't rotate.

About the guns: one set of frames which you can use which hardly causes any swinging is "straight fast". If you set it for the weapon's projectile frames in the weapon tab, there will be 2 frames of shooting which give The question about the 32 frames the idea of "pointing" from a guard position than swinging. You can look at the crossbow shape to have an idea: when facing east, the attack would involve frames 1, 3 then 1 again after the shot.

Since shoreline animation issues were referenced, it seems appropriate to ask: Does the shore still rapid performance decay? A few months back being near the shore caused my framerate to rapidly approach 0.3 or worse.

That still happens to me, on close-to-current snapshot.

I also haven't done anything with those files before

I have made significant changes for TFL.

Changes you haven't committed yet, I gather; do these changes involve anything in the "animation" section? In any case, it (hopefully) shouldn't be too difficult to upgrade to the new format.

Not to my knowledge ... though I have to ask what the point in 'downgrading' something that isn't slowing down the game in any significant way is.

~ Wizardry Dragon

though I have to ask what the point in 'downgrading' something that isn't slowing down the game in any significant way is.

Well, it is not being 'downgraded' for slowing down anything. Here is an elaboration of why it is being downgraded: for starters, it is far more powerful than would ever be needed; all of the relevant* original animation cycles form a tiny subset of all that you can do with the present system (the same is true, BTW, of the new system). The present system is also far more cumbersome than it needs to be; for example, compare the SI bubble animation fix in the present system: with that of the new system: Or compare how the animation cycle of planets would look like in the present system: vs what it would look like in the new system: There is the additional problem that the present system has a very odd behavior when it comes to patches: you could, for example, have a patch that overrides only part of an animation cycle. Taking, for example, the planet animation, if you patched it with this: This cycle overlaps two cycles in the original data. When Exult has to decide which cycle to use, it would never pick the patched cycle as it is added after all the other cycles: thus, for frames < 6, Exult would select the cycle beginning in frame 0, for frames between 6 and 11 it would pick the cycle beginning with frame 6 and so on. And since the animation cycles in the present system are generated from TFA data (as they are in the new system), modders would not have a basis for comparison.

The final nail in the coffin of the present system is that it would be an awful load of work to fix the patch behavior above and implement a way to consistently edit it in ES. More work than it has been to implement editing of *all* currently de-hard-coded data (plus some freshly de-hard-coded data that hasn't yet been commited), including the new animation system.

I think you can see my position...

* The original games had some animation cycles which Exult doesn't emulate -- the xor cycle (new frame = old frame ^ 1), the randomly-slow cycle (frames advance with 25% chance) and the very odd cases 3 and 4 of TFA.DAT (which I haven't been able to figure out yet, although 4 seems to be a randomly-slow version of 3). None of these are ever needed in the original games, and are present only for non-animating shapes. Although to be fair, Exult *does* handle the "random frames" cycle, which is also never used in the originals.

Random tibdit that may or may not be related: being able to easily give different shapes names would be appreciated, though this may have been added in my internet absence and I just havent figured out how to do so yet.

~ Wizardry Dragon

different shapes names would be appreciated

Unless you mean frame/quality names (i.e., different names for different frames/qualities of a given shape), you can already give names to shapes (and for a long, long time). If you *do* mean frame names, there is no way to edit/change them yet.

there is no way to edit/change them yet.

Although I must say that this may change soon.

That should change soon. I requested that feature back in like ... '05, I think, and got told it should be simple and added soon.

~ Wizardry Dragon

FYI, all the Exult-part of the code for frame names, as well as the data for the original games, are done. I am still writing the ES-side; when I finish with the loads of changes I am doing, frame names will no longer be hard-coded.

I am still writing the ES-side;

Which is now fully done.