Jump to content

xSeries released


Xyx

Recommended Posts

I decided to write some scripts for my party and summoned creatures while replaying the game, and I would like to share them. The scripts hold a middle ground between the game's default scripts and Cirerrek's eSeries in that they do some fairly clever stuff but don't try to control every facet of the game.

 

There's a rather extensive ReadMe included, but to sum up the main features:

  • Doing "just enough" (neither too little nor too much), helping the player focus on the cool stuff.
  • Healing the party at the press of a key.
  • Configurable fighting style.
  • Automated buffs.
  • Automatic trap finding.
  • Huge improvements in the AI of several summoned creatures.

I would love to get some feedback on my work. I am quite taken with my work myself, but then I suppose I would be. I'm curious about things like:

  • What's the verdict? Useless? Awesome?
  • Did I miss any really important abilities?
  • Is a script for the (mostly) vanilla game still relevant in this day and age of endless mods?
  • Should I host my work elsewhere? Like, on this website?
  • Should I make a WeiDU setup?

You can currently download the scripts here: xSeries10.zip

Link to comment

I wonder if anybody still around knows who has raised from the dead :)

It certainly has been a while, but I couldn't keep a good game down and I couldn't leave the scripts alone. :) Clicking a bazillion times to heal my party was all it took for me to reinstall ConTEXT and NearInfinity.

 

On a technical side I can say that summon AI may conflict with some popular mods (e g Spell Revisions or aTweaks).

I shall mention in the ReadMe that the summon AI is totally optional anyway. The party script doesn't refer to it at all.

 

Suppose I'd want to generate a bit more exposure for my work... how should I go about that? Is it OK if I post it on GameBanshee, Ironworks and/or Sorcerer's Place, for instance?

Link to comment

Those sites aren't really current with BG anymore - you'd probably get the most exposure by uploading it to the miscellaneous mod section of spellholdstudios.net. I like the idea - might want to make it Tutu-compatible too, which pretty much consists of putting an underscore (or variable for it) before any item references, if you have any.

Link to comment
might want to make it Tutu-compatible too, which pretty much consists of putting an underscore (or variable for it) before any item references, if you have any.

I'm referencing MELFMET (Melf's Minute Meteors), BOOT12 (Gargoyle Boots) and XBOW12 (Flasher Launcher). So all I'd have to do is rename that to _MELFMET, _BOOT12 and _XBOW12 and recompile and it'd work in Tutu? I don't have Tutu installed anymore, so it's a bit hard for me to test. I assume that would break it for regular BG2, right?

 

I found that BG1 doesn't need custom scripts as much, though. There's far less going on, especially in the healing/buff department. But, if I can support Tutu this way, I'll gladly do so.

Link to comment

Wow, really? I have literally not been around for ten years, so this is all new to me. Then how do you do it?

 

Why is it inadvisable? I can imagine the summon AI would conflict with other mods, but the .bs file?

 

I did include the source code, by the way.

Link to comment

Instead of

COPY ~mymod/**/foo.bs~ scripts

you can use something like

COMPILE ~mymod/**/foo.baf~
COPY_EXISTING foo.bcs ~scripts/foo.bs~

 

Edit:

  • Should I make a WeiDU setup?

(The implicit answer is 'yes'. All mods today use WeiDU. It is beyond an expectation.)

 

 

As for why it is inadvisable: when you compile a script the compiler resolves a lot of symbols into numerical values. A compiled script is portable only so long as all symbols resolve to the same values on all installs. But that need not be the case today, which means that in order to be portable a script needs to be compiled against the target installation (i.e., when the mod is installed).

 

Re: Tutu. All three of those items are by origin from BG2 so they are not underscored in Tutu (only resources from BG1 are).

 

But the conventional way of enabling Tutu compatibility while preserving BG2 compatibility is to use a variable (commonly called things like TUTU) which is set to "_" if the mod is installed on Tutu and to "" (null) if the mod is installed on another platform. You then prefix your resources with this variable, so that, upon variable evaluation, the result is things like "_boot05.itm" or "boot05.itm" depending on platform.

Link to comment

Thanks! Nice to see that there are still people from "the old days" around.

 

All mods today use WeiDU. It is beyond an expectation.

Guess I'll have to learn about making a WeiDU setup, then. Can you recommend a tutorial?

 

It would be nice to offer summon AI as a separate component.

 

when you compile a script the compiler resolves a lot of symbols into numerical values. A compiled script is portable only so long as all symbols resolve to the same values on all installs. But that need not be the case today, which means that in order to be portable a script needs to be compiled against the target installation (i.e., when the mod is installed).

Does this apply to anything other than IDS values?

 

I had to circumvent a compiler problem for some spells that aren't listed in the IDS files. For instance, the innate Bhaalspawn power of Cure Light Wounds is SPIN101.SPL, and it isn't listed in SPELLS.IDS. Instead of HaveSpellRES("SPIN101") I used the equivalent HaveSpell(3101), which I suppose is sort of hardcoded. Would that cause problems? I suppose I could just switch everything over to the SpellRES versions and use NearInfinity to compile.

Link to comment

 

Guess I'll have to learn about making a WeiDU setup, then. Can you recommend a tutorial?

 

It would be nice to offer summon AI as a separate component.

For distributing scripts it is easy.

Just fill in the blanks:

BACKUP "mymod/backup" //mymod=your mod folder, e.g., xseries
AUTHOR foo //some address where those who have problems with the mod can reach you

VERSION 1 //or whatever you like
//README "mymod/foo" uncomment if you want to ship a readme along with the mod

BEGIN "Name of your first component"

//COMPILE, COPY_EXISTING and other actions


BEGIN "Name of your second component"

//and so on

The WeiDU readme contains extensive documentation. If you want translations and stuff you can basically look at any mod for examples.

 

Does this apply to anything other than IDS values?

Not as such. If you have text strings and variables and such you also need to compile at install time.

 

Say, if I'm making a WeiDU install anyway, I can add custom strings to Dialog.tlk as well, right? I wouldn't mind some clearer DisplayStringHead() feedback.

Yeah. The advantages of using WeiDU are probably more persuasive than some nebulous warnings about non-portable scripts, anyway.

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...