Constantine

I broke down and wrote it anyway, which concludes my initial vision for the project. The first beta release containing the full feature set can be found on GitHub.

Wow thanks! Could you write a tutorial on how to use your tool?

Time for an update. Right now I can:

• Repair a couple increasingly uncommon bugs with tileset headers: 1 with PVRZ-based tilesets and 2 with palette-based tilesets.
• Remove tiles from PVRZ-based and palette-based tilesets using one of two methods: Pop (removes N tiles from the end of the tileset), and RemoveAt (removes N tiles from the tileset starting at the specified tile).
• Add tiles to palette-based tilesets using one of three methods: Push (add a number of tiles to the end of the tileset), InsertAt (insert a number of tiles into the tileset before the specified tile), and Replace (replaces a number of tiles starting at the specified tile, adding tiles to the end of the tileset as necessary).
• Create a new palette-based tileset from a series of tiles.

 

I'll be working on exporting a palette-based tileset as a series of tiles next. In the meantime, tho, I'm looking for some design input concerning adding tiles to a PVRZ-based tileset and creating a new PVRZ-based tileset. I won't be messing with the PVRZ files themselves, so that leaves us with the ability to Push, InsertAt, and Replace the 12-byte data blocks of the PVRZ-based tilesets. This can be achieved in a number of ways.

 

First, one could pass PVRZpage, XCoordinate, and YCoordinate to three variables of the add function. This would mean you would have to call the Add function for each tile you want to add. The down side to this is that with the current implementation, the tileset header must be read each time the function is called. Not the most efficient, but not terrible. One bonus to this would be the freedom to generate tile data on-the-fly, having to store nothing on disk.

 

Second, one could have each PVRZ data block saved to a separate 12-byte binary file. The files are passed to the Add function via a REGEXP (just like the palette-based tiles currently are). This has the bonus of being directly parallel/comparable to the current palette-based implementation so would be the easiest for me to code. Downside is the inefficiency of filesize on disk, greater number of files shipped with/managed by the mod, and unnecessary number of disk reads.

 

Third, one could have the entire series of tiles one wanted to Push, InsertAt, or Replace in a single binary file. Better efficiency all around, but perhaps less flexible depending on one's needs.

 

Fourth, one could pass a variable to the Add function that contains all the tile data blocks to Push, InsertAt, or Replace. Basically a combination of options one and three. How this variable is populated would be up to the modder using the function.

 

The Create function would use the same procedure as the Add. Thoughts?

Oh dear. I honestly have no idea which way is the best! Let's just keep in mind that you probably won't be needing to insert tons of tiles at once. I was thinking of shipping several BAM (or maybe BMP) files with the mod and inserting them into the certain TIS file during the installation (along with the other necessary modifications to the are files of course). Something like that. Anyways, do you already have a release date yet?

You haven't mentioned whether the mod is for the classic games or the Enhanced Editions. In the latter case TIS files are much smaller (several kb instead of MB) and can easily be modified with WeiDU. File format is described in more detail in this post. It's just a matter of adding one or more tile data blocks and providing a small PVRZ file with the new graphics.

 

Theoretically it would also work for the classic games if you don't mind converting the TIS to the new EE format with tile2ee, making your changes and converting it back (with the same tool).

It's for EE. Well, that's a relief. Now if only Sam will provided us with the right code

In vanilla games, it is 256 x256, but you can use split bams. I display a 540 x 320 animation bam split into 6 cycles checking the "Draw all cycles" box in the Animations tab.

Thanks alot.

Instead of adding your door image to the tileset, make it a BAM file and place in the area as ambient animation. Positioning can be calculated based on the tile size and tile offset.

You can set time of day when animation is active, so one for day version and another for night will work fine. Dusk and dawn are problematic, however, because of dynamic lighting adjustment. I've seen it almost working for dusk with day animation's light source flagged off, but not for dawn.

Thanks, maybe I'll try it out. Please remind me what're the maximum BAM dimentions? I vaguely remember that it can't be of any size you want.

If you need it for a mod, just ship the updated tileset. I don't even think there was at least one that added new tiles to existing area? That, and since doors themselves are among the most complex structures for random people to bother, you aren't gonna run into compatibility issues.

 

PS You can also kind of fake the door with a bam overlay, without touching the tileset itself, but it doesn't work too well for day/night areas (namely during dawn/dusk transitions) and would need scripting activate/deactivate, so you can't really use it as a "normal" door that player can interact with.

Yeah, turned out it's the only way.

Could you please elaborate a little bit, how I can fake a door via a bam? (I don't need a real door really, I just thinking about using "doors" to add interactive content, like the bridge under temple district).

 

There's an old polygon/door tutorial somewhere for DLTCEP. Patching the mos is possible, but the code won't look pretty (binary file).

Well, the tutorial is here ... there's ugly weidu code in various mods that add areas one could go and take a look at.

 

And you do really nothing with a door... as it's just a graphical binary element on the map. You need an entrance(&exit) point that transfers you from one map to another. The DLTCEP tutorial is there for that as well.

I'm aware of this old tutorials, but they can't patch in the door bitmaps. All other stuff like polygons, entry points etc. are pretty easy to add via weidu. You can modify vertexes, regions and other relevant stuff, but you can't patch in a stupid door to the area, because there can be no door without a bitmap

Sure you can, it's just lots of pixels and tedium, like I mentioned. The other stuff is point or polygon based, so much less data. Calculate the region you have to change and then alter each byte one by one to the target ones. Maybe someone already wrote a function or generator for that, but I'm not someone who would know.

If you already have a BMP of the tile you want to patch into the TIS, the code to do so is not that difficult. In fact much of the needed code has already been written, one would just need to write a wrapper function/macro around it. If this actually hasn't been done before (which surprises me), I'd probably be willing to take a crack at it.

 

Well I just blundered into why no one has bothered to do this before: WeiDU's filesize limitations with COPY. This makes the whole concept useless for any decent size area, such as the ones you'd usually bother adding open/closed door tiles to. WeiDU really does suck... I'm basically half way through anyway so I may continue creating the necessary functions as an academic exercise, but they probably won't be that useful in the long run .

Bad luck Anyways, I much uppreciate your effort! Better to have the code if this weidu function will ever be fixed.

 

There's an old polygon/door tutorial somewhere for DLTCEP. Patching the mos is possible, but the code won't look pretty (binary file).

Well, the tutorial is here ... there's ugly weidu code in various mods that add areas one could go and take a look at.

 

And you do really nothing with a door... as it's just a graphical binary element on the map. You need an entrance(&exit) point that transfers you from one map to another. The DLTCEP tutorial is there for that as well.

 

I'm aware of this old tutorials, but they can't patch in the door bitmaps. All other stuff like polygons, entry points etc. are pretty easy to add via weidu. You can modify vertexes, regions and other relevant stuff, but you can't patch in a stupid door to the area, because there can be no door without a bitmap

Hi averyone,

I wonder if someone got an idea of how to add a new door to the area - complete with new open/closed tiles from bmp or bam files? I know I've asked this question some years ago, but frankly, no one had a working solution back then.

I think this matter is important because now if you want to add a door to the game, you should provide the whole new tis file with your mod, and this is obviously a very bad way to go.

You can even backstab those mushrooms that summon myconids (if you can work out which side is their "back"). Minotaurs are on my to-do list anyway.

yeah it's funny all right, being able to "backstab" a mushroom, just remember that if someone has no actual back for rogue to hit to don't mean that it cannot be backstabbed and vice versa. this is IMO of course. this is why you cannot backstab jellies, they just don't have any vital organs or other weak spots that you can hit, but you can easily backstab golems which don't have any organs too, but may have some weak spots that a rogue can hit.

great mod BTW, I m looking forward for other useful creature revisions from you!

I'd vote against making more generic monsters immune to backstab

Afaik, backstab immune monsters are as rare as talkative Stalkers in this game.

maybe you're right, but afair most bosses are immune, and there's really no excuse for a minotaur to be immune, remember that backstab isn't just an attack from behind that by some magical means do an increased damage, but rogue's ability to find the foe's weak spot, thus an increased damage output.

They should me immune to Maze (they never get lost, but why would you use Maze on a Minotaur anyway?), have Power Attack (chance to stun?) and Bull Rush - gore attack with horns (movement speed increase, charge nearest target, short lasting Hold/Stun/Slow effect?). In addition, they're never caught flat-footed (immune to backstab).

I'd vote against making more generic monsters immune to backstab. rogues are pretty useless in combat already, lets not make them just a walking lockpick/disarm machines early in SOA, because they already are in TOB.

Mist of Eldath

Like all clouds it should be non-friendly. I don't think it will severely reduce it's power.

I'm instead with those saying that to be appealing it should be party-friendly. How can it be useful if it heals all opponents? o_O

At least, it could be useful for clearing out dungeons full of undead.

Fog Cloud

I'd like to know what other players think about making creatures within the fog semi-invisible. One more thing, implementing it would make this spell the ultimate anti-thief spell as true invisibility would be impossible, not even via hide in shadows...it really doesn't convince me.

You know my mage likes theese anti-thief spells very much, the thieves are a tiresome bunch most of the time

Beware, new 4th lvl spells are coming!

Bring it on!

Spell Immunity

Yes, let's get rid of it. Ridiculously OP spell with a lame concept.

Sunfire

I'm thinking about renaming it Fireburst as per PnP (perhaps it's just me but the "sun" part is kinda "out of place" imo). I think the current solution is really fine, but feedback is welcome. PnP version uses d8 dices for damage, but I'm not sure this spell needs more dmg output, does it?

Rename it, the closer to Pnp the better.

Dispel & Remove Magic

I think that these spells are overpowered at high levels so I would not mind a cap. But I seem to remember most people disagreed.

Yeah, dispel should not be all-powerful at high levels. Don't know how it's working in SR. From my point of view, if dispel goes stronger with caster level, so should the protections. In that case, 20th level mage should easily dispel a meager protections of low level casters, have some difficulty to cancel spells of mid-level caster, but to remove a fellow high level mage's protections should be relatively difficult.

Fire Shield

I would welcome the use of a single slot for this.

+1

Dimension Door

Move to 5th level as a Greater DD. Caster receives an innate refreshable DD for a limited time. LOS is required.

So we have two options:

* moving the current version to a lower lvl (perhaps I'm mad but I'd say even 1st lvl could be fine, especially with Line of Sight limit)

* moving it to 5th lvl as you suggest

Let's see what players think about it.

I actually like Adranis' suggestion. Worth a try IMO.

Charm

So much more useful for the human player. Are you able to make charmed party members act hostile? Or else disable the ability to control charmed creatures (which would make the spell so much less appealing).

As I recall, they already act pretty hostile, the melee classes at least. However, it would be nice to assign the custom script to charmed character according to his class, so warrior could fight in melee (It's the default behavior for the enemy-charmed characters, isn't it ?), rogue backstab, mage cast some spells available to him and so on.

I wouldn't recommend to disable control of charmed creatures, that's for sure.

Chill Touch is actually pretty good, but nobody uses it. The cold damage goes right through Stoneskins, and the weapon is considered unenechanted so it goes right through PfMW. It also grants +4 Thac0. The on-hit Thac0 drain has a save, but if you can get enough attacks in on a powerful opponent it can save you some hits. Temporary Strength drain might be better, but could make it overpowered as this can instakill. Maybe temp Str drain with a 3 round duration?

 

It is really good for F/M and Bard characters to disrupt enemy spellcasters.

I think it nearly useless for mages as meleeing is almost always worse than shooting good old MM from the safe distance.

Enemy mage with Stoneskin but without MGOI?

Cloud Spells

As I said, there's little I can do about them. On one hand I hope SCS AI can handle them relatively well, otoh if players want to heavily exploit them, let them do so and ruin their experience. It's not an exploit you can do "by accident", you have to purposely "cheat" to make them cheesy.

 

The only two things I can think of to limit them and maybe help the AI are:

* reducing duration to 5-6 rounds

* reducing AoE from 30' to 20'

The latter in particular may help SCS AI in quickly escape the area when doable. Let me know what do you think about it.

I'd vote not to touch good old cloudkill at all, it's good as it is. If you can't resist the urge to cheat, it's only your problem.

So the ADHW's nature of not being magic damaging spell is not enough for you, right? It's because your precious mages with advanced AI prefer to cast it on Mordies (thus exploiting a bug) or what?

I don't think I'll dignify that with an answer.

I'm shure you don't. By the way, "dignify"? Man, are you some megalomaniac or something?

So the ADHW's nature of not being magic damaging spell is not enough for you, right? It's because your precious mages with advanced AI prefer to cast it on Mordies (thus exploiting a bug) or what?

Let's not turn (a so far rather humorous) discussion into an argument... For the record, SCS(II) mages isn't really DavidW's precious mages, they're precious mages for a whole slew of people.

Fine with me.

AOT: in case someone's counting, I'm with the players who're thinking that Conjurations should bypass MR.

Perhaps you could clarify how your "common sense" is intended to differ from my "realism".

Only after you'll explain how it's real to "dehydrate" a sword-shaped plane of force with ADHW

 

Since ADHW doesn't exist, and neither do sword-shaped planes of force, obviously it isn't real.

 

I assume you mean "realistic". In which case, I don't recall claiming that it was.

 

Not to mention that the spell description clearly states it works only on living creatures.

 

This doesn't obviously have relevance to my question. To recall the context: I asked if the proposed change to ADHW is based on realism rather than gameplay. You suggested that it was based on "PnP rules and common sense". I asked how your "common sense" differs from my "realism". I'm happy to believe you did intend some serious point by the term, and weren't just resorting to hyperbole, but the question stands.

I thought you've proposed to leave ADHW as it is because it's current behavior looks "realistic" for you for some reason.

So the ADHW's nature of not being magic damaging spell is not enough for you, right? It's because your precious mages with advanced AI prefer to cast it on Mordies (thus exploiting a bug) or what? Or maybe I just misunderstood your point?

Perhaps you could clarify how your "common sense" is intended to differ from my "realism".

Only after you'll explain how it's real to "dehydrate" a sword-shaped plane of force with ADHW Not to mention that the spell description clearly states it works only on living creatures.

Sadness. At least ADHW has a huge AoE, thus even if cast upon Mordy it will probably take most of the battlefield.

 

I take it this is a change based on realism rather than balance? (In pure gameplay terms I think it's unfortunate.)

I take it this is a change based on PnP rules AND common sense.