Exult Forum

Warning: This thread is intended for discussion about the details on some features that are yet to be added to Exult -- and in some cases, might not even get that far. Also, I would prefer to discuss these things before rushing to implement it.

I will start with a brief recount of the original (mailing list) discussion and the ideas in there, just to give enough backgroud to everyone reading this.

--------------------------------------------------------------------

After some of the initial problems with the release of the Keyring mod, Dominus suggested adding a patch identity:

This would help a lot in narrowing down the problems people have with patches AND/OR to quickly spot potential solutions when people come
and say that Exult doesn't work anymore (and the only problem is that
they are still loading a patch at startup).

I then suggested making a 'mod manager' of sorts which would compartmentalize savegames and the patch dir for each mod. My initial suggestion was a 'mods' folder which would include one file per mod giving Exult the relevant information; Exult would enumerate these files -- and ask which mod, if any, the player wants -- at startup.

Dominus then suggested compartmentalizing the gamedat dir, for the same reason as the savegames would be.

Jeff liked the idea. wjp suggested two different manners for the mod list:

Option 1:

Main menu: Black Gate, Serpent Isle

Black Gate submenu: BG, BG with keyring patch, BG with island demo
patch, BG with other patch, ...

Option 2:

Main menu: Black Gate, BG with keyring patch, BG with island demo
patch,
SI, SI with fixes patch, SI with...

wjp also suggested doing away with gamedat dir entirely and just loading everything into memory.

Jeff, wjp, Dominus and me were leaning towards option 2; no one else gave an oponion. Jeff also noted that we would have to add scrolling.

I suggested also having the mod files include a command-line parameter (similar to --bg and --si) so users are able to create shortcuts to start their favorite mods directly.

Jeff suggested using it also for Exult Studio (to edit a mod's files).

Dominus then derailed the thread (:-P) by suggesting taking over Pentagram's ini system.

--------------------------------------------------------------------

This concludes the mailing list discussion. In this thread, Dominus suggested a versioning system for mods to prevent problems when a mod expects a different version of Exult than the player has.

I suggested omitting incompatible mods from the menu (which would have an expected version number in the mod file). Colourless suggested that, instead, the mod be listed in the menu as being incompatible.

--------------------------------------------------------------------

That is all of the required context for the discussion. Now for the new stuff.

The menu should evidently have support for new games as well as mods. We would also have to redesign the basic menu layout if the big winner is option 2 (above) -- or, for new games, even if option 1 wins.

I was thinking about a 2-column layout for the basic menu; something like this: Currently, the clickable parts (the game names, setup, exit, etc.) are shapes of their own -- it might be best to create a (vga?) font for Exult to render the game/mod names with.

Another important thing: while I know how to do (efficient) file enumeration in Windows, I have no clue about how to do it in other systems. Therefore, (1) either someone will have to do it (for non-Windows systems) using conditional compilation, (2) we will have to do find a platform-independent way to do it, (3) we will have to standardize the names for the mod files (which could create conflicts) or (4) we will have to find another system. Ideas?

That is all I can think of for now.

it's looking good Marzo.

Now, as maintainer of the Zaurus port, I would like to remind you on the small footprint for memory on that machine. I would rather we used less memory than more, and more flush to the gamedat dir.

Artaxerxes

File enumeration code already exists in Exult for savegames, by the way.


Also, while I don't have Exult here, I seem to remember the gamedat size is fairly small compared to the main static map. There's much more to gain by unloading static data more often.

File enumeration code already exists in Exult for savegames, by the way.

That one assumes that file names conform to a certain standard; I was thinking something more along the lines of how Baldur's Gate loads files from the override dir without the filenames conforming to any standard (the item (3) I mentioned above).

Artaxerxes: We haven't done much work on reducing memory size, so there are probably some opportunities in "gamemap.c" for flushing static data, probably as a compile or runtime option. I'd imagine a first step would be to start keeping track of the amounts of memory used for various data so we could see where we could improve.

Marzo: I wonder if any our current fonts would look okay.
And here's an option 1.5: Have the main games show up in the top-level menu - "Black Gate, Serpent Isle, NewGame, etc.", and have a "Mods" button next to each one that brings up a second menu with that game's mod choices.

I suggested this ages ago, but maybe now with a lot more in place and things de-hardcoded (to an extent) we can actually implement it.
--------
Peter M Dodge aka Wizardry Dragon
Lead Designer,
Ultima VII: The Feudal Lands

I like Jeff's mod button suggestion, othewise I do think it all sounds good.
Any thoughts on the versioning?

(and sorry for derailing the original thread even though I do try to keep others from hijacking threads here, I do that myself sometimes - not worth replying to, since it would hijack THIS thread )

Any thoughts on the versioning?

I was thinking about having the mod's file include an entry for the version of Exult it expects; for example, after the release of 1.4, a mod could have '1.4-R' as the required version, while another mod could have (e.g.) '1.5-CVS', indicating that the mod requires the latest version from cvs.

It is kind of simple, I know; any other ideas would be appreciated.

That sounds fine. Should we assume that newer versions of Exult should always work with older mods, assuming that R > CVS? So if a mod is marked '1.5-CVS', then Exult 1.5R or higher would accept it.

Should we assume that newer versions of Exult should always work with older mods, assuming that R > CVS? So if a mod is marked '1.5-CVS', then Exult 1.5R or higher would accept it.

For CVS and release versions, I think we would be safe to do this; I see no reason why the mod would fail to load in the release if it loaded correctly on the CVS leading up to the release. But between releases, things can get trickier... but it may be possible with enough care.

how about dates? if you put it in YearMonthDay order, it is easy to see if a required version is more or less than the version we currently have. For instance, if the mod needs 20060711 and you've just got the CVS as of today, it would be 20060717 and since 20060711 < 20060717 you would be fine.

just an idea...

Artaxerxes

For instance, if the mod needs 20060711 and you've just got the CVS as of today, it would be 20060717 and since 20060711 < 20060717 you would be fine.

It could work; it could lead to problems for those that self-compile the CVS, though, if they compiled from older code.

Thought: it could be neat if the main menus were customizable through XML or some other file format, for people that want to create their own games from scratch.
--------
Peter M Dodge aka Wizardry Dragon
Lead Designer,
Ultima VII: The Feudal Lands

Yes, I think that's what we're aiming for.

If this is implemented, would it be possible to include the more popular/stable mods as part of the Exult download?

File enumeration code already exists in Exult for savegames, by the way.

That one assumes that file names conform to a certain standard; I was thinking something more along the lines of how Baldur's Gate loads files from the override dir without the filenames conforming to any standard (the item (3) I mentioned above).

After taking another look at the referred code, I realized I was being stupid; I am using it now.

Just an update status: I still haven't commited it to CVS (I will work on Exult Studio support for this before I commit it), but here is what I've got so far:

The explanation: games are defined in exult.cfg; they use the same structure as BG and SI do, with the exception of accepting an extra tag: ''. An example in action (extracted from the exult.cfg I used for the screenshot): If there are enough games, scrolling buttons appear; there are four possibilities: 'first', 'previous', 'next' and 'last' which change the current page (each page with up to six games).
Each game also has a 'mods' folder; in this folder, you drop in 'modname.cfg' files (one per mod) to 'register' the mod. If a game has any mods, the 'show mods' menu entry appears. An example is the 'keyring.cfg' file which was used in the screenshot: Of these tags, the only 'required' ones are '' and ''; all others have sensible defaults: Also, I have implemented mod-loading through command line parameters: you have to specify the game as normal ('--bg', '--si' or '--game ') and you specify the mod with '--mod '. It will load the mod with '' equal to ''.

How does it look so far?

looks confusing at first, but the cfg makes sense then.

Perhaps you could just show the sound icons only when sound is missing.

Perhaps you could just show the sound icons only when sound is missing.

I like that idea.

I like the way it looks, except that perhaps the 'NEXT' and 'SHOW MODS' buttons should be shown in a smaller font, or a different color.

Now, if the user has a 'patch' directory specified in 'exult.cfg', and is also using a mod, should the mod's 'patch' take precedence? I think Dominus suggested that we print the 'patch' directory used during startup, and that would be a good idea no matter what we decide. (And I don't think we should look in more than one 'patch' directory.)

I like the way it looks, except that perhaps the 'NEXT' and 'SHOW MODS' buttons should be shown in a smaller font, or a different color.

I was thinking about a different color perhaps; I was going to make a red-ish version of the font to draw the 'WRONG EXULT VERSION' warning; maybe I instead I can make a greenish font (or two, due to the hot tracking...) and use it for the warning as well as for the navigation items. Making a smaller font may present readablity issues, so I think I won't do that.

In any case, I have followed SB-X's suggestion and I have also moved the 'SHOW MODS' button a little closer to the corresponding game button.

Now, if the user has a 'patch' directory specified in 'exult.cfg', and is also using a mod, should the mod's 'patch' take precedence?

That is the way I have coded it so far; the mod's 'patch' completely overrides the 'patch' directory from 'exult.cfg'. Also, the mod's title is printed in stdout (e.g., 'Starting a BLACKGATE game with the 'keyring' modification') if a mod is being used.

The yellow SI font should be good, I think.
--------
Peter M Dodge aka Wizardry Dragon
Lead Designer
Ultima VII: The Feudal Lands

Strictly speaking, SI doesn't really have a font for the title screen (neither does BG, for that matter) but it has different shapes for each menu entry instead; but you are right, making a SI-looking font would look good. I will have to edit the main menu palette in any case.

Say, it'd be neat if you could tie Exult and Pentagram together (in a way) through the title selection screen.
--------
Peter M Dodge aka Wizardry Dragon
Lead Designer,
Ultima VII: The Feudal Lands

This all sounds really good!

"Say, it'd be neat if you could tie Exult and Pentagram together (in a way) through the title selection screen."

The trouble is that the title screen is part of the Exult program. What someone could do, though, is create a separate launcher program that could start up Exult or Pentagram. Maybe it could start up other Ultima's as well using Dosbox.

Pentagram already has it's own integrated Menu system in it that's already used for Game/Language/Version selection for U8 as well as the Crusader Games. Would kind of be redundant to attempt to integrate that with Exult stuff into a seperate program.

Pentagram Menu:

One though that just occurred to me: should we have mod-dependent key bindings? An example would be for the keyring in the keyring mod, so that the user could use the keyring by pressing 'k' (and 'try_all_keys' with ctrl+k) and still be able to use 'try_all_keys' by pressing 'k' in other mods.

The Pentagram menu looks very good; I like the layout a lot, as well as the game icons. Earlier, I had thought about the possibility of having icons for the games/mods in Exult too, but it would require major palette editing for it to be possible...

Hmm. Maybe a more radical menu redesign? Gratuitously stealing ideas from Pentagram ;-p ? Something like: start with the Exult logo as normal, then switch to a Pentagram-style menu, with the Ankh in the left, the 'Exult' in the top and a list of games somewhat similar to the Pentagram screenshot (as in: game icon in the left, the game title in one line, the sfx icon and the 'view mods' button below the title and a box surrounding it all); the Exult version and main menu options (as well as navigation buttons) would be retained in the bottom (or maybe could form a vertical menu underneath the Ankh in the left). A major redesign of the palette, with a small extension to the cfg files would allow icons for the games; and all this wouldn't be too hard to implement given the way I have done things.

Thoughts?

I like Pentagram's menu but don't favor changing the style of Exult's completely. It's been around for so long anything else wouldn't look like Exult.

And I am certainly not advocating dumping everything

Here is a mockup (made in GIMP) of what I have in mind:

(the icons have been grabbed from an Ultima icon dll; of course, the final icons for BG and SI would not be these; and, of course, I haven't made the palette yet)
And yes, I do realize that the titles are still in two lines It looked better that way.

I'm not sure I like that. Probably too much colour
It's getting too cramped and I do think we could consider a new start screen that takes all these new features into account while being designed instead of "patching" it onto the old screen.
Don't get me wrong Marzo, you are doing a great job working inside the old design, I just question if your ideas really work with the old one.

Probably too much colour

Yes, I had that same feeling; the icons are probably too much (and would require MAJOR palette surgery...).

It's getting too cramped and I do think we could consider a new start screen that takes all these new features into account while being designed instead of "patching" it onto the old screen.

True, very true. The first thing to do would be not to limit the start screen to 320x200; that would help resolve the 'cramped' feeling. Switching to the lower resolution (or window size, for those that run it in windowed mode) could be done later, when the game has been launched. I will look into that.

In any case, changing window size/resolution would help with the sfx icon; it is being really hard to find a place for it...

The first thing to do would be not to limit the start screen to 320x200

An afterthought: perhaps making the menu a higher size/resolution *and* not using scalers could be better -- you know, making a higher resolution version of the fonts used.

Yes, that would look better. I'm not sure how hard that would be.

Yes, that would look better. I'm not sure how hard that would be.

Trivial apparently; just increasing the size of the menu screen to 400x300 reduced cramping enormously, without even needing to redo the fonts or turn off the scaler or anything. And now, up to 10 games/mods can be shown in each page without much clutter.
Now the question is: should the games (and mods) menu be vertically centered or as in the following picture?

Arguments for being vertically centered: BG and SI are in more proeminent spots, being easier to find. Also, reduces a big empty space in the center of the screen.
Arguments against being vertically centered: Adding new games alters the position of all the other games, and forces the player to get used to the new layout even if he wants to play the old games. The Exult logo in the background remains visible even with the addition of many games.

Looks good so far. Marzo, can yhou commit that or send the code to me before 18:00 EST-4? Reason I ask is I have a few ideas for code modifications I want to try, but In am going to be out of town and offline as of 19:00 tonight, so yeah, it'd be nice if I actually had the code to play around with
--------
Peter M Dodge aka Wizardry Dragon
Lead Designer,
Ultima VII: The Feudal Lands

Marzo, can yhou commit that or send the code to me before 18:00 EST-4?[...]but In am going to be out of town and offline as of 19:00 tonight

Sorry, but I wasn't home all day today; by the time I got home, it was well past the time you specified (which I assume was GMT-4?)...

I just commited the changes.

I'm looking forward to testing this when I return home in a week

I wish I was able to comment on it but it was a long weekend here in Canada...

Requiring a screen size of 400x300 or whatever it was is IMHO a really bad idea as the Zaurus does not support anything higher than 320x240.

Artaxerxes

Requiring a screen size of 400x300 or whatever it was is IMHO a really bad idea as the Zaurus does not support anything higher than 320x240.

I didn't know that; I will make a Zaurus patch that takes it into account.
[edit]: Are there any other ports with similar limitations, so they can also be addressed in the patch?

I tried it last night and it looked great. It even showed all the empty 'junk' games I've created with ES over the years.

I will make a Zaurus patch that takes it into account.

The patch is made and commited.

It even showed all the empty 'junk' games I've created with ES over the years.

Exult Menu: forcing the cleaning of cluttered cfg files

On a more serious note, the thought just occurred to me: these changes should probably be mentioned in the docs section.

yeah, I haven't done anything on the docs since there was the question some time ago whether to keep the online docs only for the last version and not for CVS and I wanted to tag the docs section and then work on the 1.4x docs that would go out with the snapshots. Just haven't had time to do that yet (the whole music section needs to be updated)

A thing that popped in my mind: right now, the mod cfg files do not handle relative paths very well (basically, they end up being relative to exult's base dir); I was thinking that they should probably be relative to the mods folder, but that might be confusing.

So perhaps I could add a new (optional) configuration specifying where the paths should be relative to; for example accepting the values "exult_dir" (default), "cfg_dir" (i.e., relative to the 'mods' folder, where the cfg file is) and "mod_dir" (for example, "/tfl" for the TFL mod).

Any thoughts?

I think it's fine to be relative to exult dirs or if not entering the whole path. normal users just get confused by the relative one anyway.

I was thinking more about having the modder distribute the cfg files ready for use -- for example, by distributing a zip file to be unzipped to the 'mods' folder which contains the cfg file and directory structure; it would be convenient to be able to specify folders relative to the cfg file in that case (or just use the default ones). I see your point, though.

I can see your goal. Perhaps instead of another config. option you could recognize, say, "/tfl", like we do internally for "".

You mean having the config file paths 'understand' paths with "" in them? If so, the only problem I see is that the '' would have to be XML-encoded... which is admitelly not much of a problem.

Yes, that's it. Maybe "__MODS__". Hopefully, the user wouldn't have to know about this, since the mod author would provide the config file.