The possibility of Vahnatai as a playable race

[Slarzahl]

No, but it would require a much larger investment of programming and testing time than any other minor change has. You'd need to change the storage structures for terrain types to accomodate more terrain types; change the way terrain types are written to and read from scenario files as well as save game files; and either (1) change the way NPCs are handled, including data structures, read/write, and numerous manipulative calls, to allow for a much larger number of total NPCs, or (2) add significantly to the spaghettilike combat and movement code to allow for all aspects of interaction with these pseudo-NPC terrain types. And probably something else that doesn't occur to me, because I'm not intimately familiar with the code.

 

In other words, NO.

[Celtic Minstrel]

Originally Posted By: Cryolemon

As I said though, if you added it to a new terrain type that wouldn't exist in old scenarios, it wouldn't break the game.

But if that's all you want to do, it's exactly equivalent to making a monster that can't move, so why not just do that?

Keep in mind that there are plans to extend/remove the preset-monsters-per-town limit. Actually, that might be one of the things already partially done.

[Cryolemon]

Originally Posted By: Celtic Minstrel

Originally Posted By: Cryolemon

As I said though, if you added it to a new terrain type that wouldn't exist in old scenarios, it wouldn't break the game.

But if that's all you want to do, it's exactly equivalent to making a monster that can't move, so why not just do that?

That's a good point, and if it's not simple to program (as the previous post seems to imply) then there is no point at all.

[Lilith]

Originally Posted By: Celtic Minstrel

Originally Posted By: Cryolemon

As I said though, if you added it to a new terrain type that wouldn't exist in old scenarios, it wouldn't break the game.

But if that's all you want to do, it's exactly equivalent to making a monster that can't move, so why not just do that?

It's not exactly equivalent, since a monster-that-can't-move can't block visibility and must block movement.

[Celtic Minstrel]

That's true. The game mechanics don't allow for attacking something that doesn't block movement though, so I don't see that as an issue, and I suppose if you wanted visibility blocked you could have a special terrain type that you always place below the monster, which blocks visibility and is changed when the monster dies. (Though this is not possible at this time except by giving each individual instance of the monster its own special node.)

[JtD]

The problem with the "just use an immobile monster" remedy is that the limited amount of monsters that can be placed in a town makes it impossible to replace very much terrain & still have creatures in the area. If I'm not mistaken, the limit was 50 last time I checked. Hardly enough to really get the job done.

[Cryolemon]

Originally Posted By: JtD

The problem with the "just use an immobile monster" remedy is that the limited amount of monsters that can be placed in a town makes it impossible to replace very much terrain & still have creatures in the area. If I'm not mistaken, the limit was 50 last time I checked. Hardly enough to really get the job done.

It was mentioned above that the limit will be raised, although what to I don't know (is 65535 asking too much?)

[Celtic Minstrel]

The limit will be raised. 65535 is not asking too much, but more likely it'll be limited only indirectly by the max size of a vector<> and by available space, so assuming plenty of the latter the limit would probably end up being 4,294,967,295.

 

But I'd be more inclined to call it "unlimited", since no-one in their right minds would be putting four billion monsters in a town anyway. I suppose I could artificially impose a limit, but it would be something still ridiculously large, such as 5000 for example.

[Niemand]

No sane person will object to you calling numeric_limits<vector<T>::size_type>::max() unlimited, I think. It might be reasonable to limit it to the number of spaces in a town, but once you go to dynamic allocation the great thing is that you don't need to make a big deal out of picking arbitrary limits.

[SkeleTony]

Just a quick note/observation/question:

 

I see this rationale for not correcting certain game-balance issues or adding features which might alter game balance because old scenarios will not work(as well) because those designers, way back in the day designed their scenarios with these bugs/balance issues in mind.

 

Correct me if I am wrong(I probably am) but if someone wants to play the old scenarios shouldn't they do so using the original BoE instead of new open source updated versions? I mean I myself have both versions on my hard drive(they are ridiculously small in size in this day and age of 500 GB to multi-Terabyte hard drives.). I mean isn't this kind of like the coders on the new Duke Nukem 3D versions NOT doing what they have been doing(3D High Resolution packs, Windows and Linux ports etc.) because 'Map makers who created their maps back in 1997 did so with the limitations of the OLD Duke Nukem(DOS/Win 95) and their maps won't work with these new proposals...'?

[Slarzahl]

Original BoE will not run, or will not run easily, on most modern computers.

 

I don't understand the fuss, though: how hard can it be to make a preferences item that says "leave rarely encounted exploits and bugs that some old scenarios make use of intact" and then make the relevant lines of code conditional based on that boolean?

[Celtic Minstrel]

Harder than you might think, but certainly doable.

[Slarzahl]

I assume the harder part is just dealing with the preferences window, and not the actual control flow statements, which should be pretty simple, right?

[Celtic Minstrel]

I wasn't even thinking of the preferences window. The control flow statements might sound easy, but consider how many of them you'd need and how dispersed they are likely to be in the code.

 

I don't know if the preferences window would be hard. It actually might not be.

[Slarzahl]

I assumed that most existing changes made to OBoE would not be relevant to this option -- just things that you suspect might break old intended behavior. Fixing miscoded monster ability effects, that kind of thing.

[Celtic Minstrel]

Things like miscoded monster ability effects won't need a preferences setting. There should be a check when loading an old scenario that does something like "if a monster has Petrification Touch, change its ability to Disease Touch", for example. The point being that the only flag necessary is the scenario's version number.

 

One case where a preferences setting might be desirable is the implementation of the two resurrect spells, which apparently did not require Resurrection Balm as they should have. That could just as well be handled by checking the scenario's version number, though.

[Slarzahl]

Right, the issue comes up because some old scenarios might have been INTENDED to have the behavior for an ability listed in the documentation, rather than the effect that ability actually had in BoE, and just never noticed the weirdness. On the other hand, other scenarios might have intended or even relied on the undocumented behavior. Just an old/new scenario flag isn't enough for this, hence my suggestion to make one giant player-controlled flag.

[Celtic Minstrel]

Well, if there's a player-controlled flag:

1. It would only be considered if the scenario's version is the older version.
2. Changing the flag in mid-scenario would require re-loading the scenario to get the full effect, since some of the legacy stuff is handled by conversion-on-load.

 

I'm not going to say there won't be one. I'd prefer for there not to be, but if there are a lot of bugs that some people designed around and others ignored, you'd be right in saying it's kind of important to let the player be able to decide.

 

 

Although, a third alternative would be that, upon loading an old-format scenario, the player is given a "Legacy Options" dialogue box which allows greater fine-tuning of the legacy compatibility controls. This would also need a preference for whether to display the dialogue at all.

[Slarzahl]

I don't think there are lots, but there are definitely a few: I know there were one or two messed up monster abilities that many people used, intended the labelled effect, but some people used intending the coded effect.

 

The "Legacy Options" dialogue box sounds like a good idea to me.

[JtD]

I could definitely see the "Legacy Option" being a good compromise, but I don't know how easy it'd be to implement.

 

And for though keeping score, the old games won't work at all with 64-Bit. God forbid the "Compatibility Mode" actually do something... For those with Linux, the Exile Trilogy installed & works just fine on newly my acquired 400mhz Linux laptop & the most recent iteration of BoE I have works well too(Thank you Wine).

 

Anywayz, a significant increase to the monster limit does allow for the option of destroyable terrain, which is awesome & I would so use it. 1 recommendation for that, though. I would recommend amended the game to where you can set the Monster's speed to 0, so you wouldn't have to set each placed terrain monster to 'immobile'. This change would make the idea doable on the sort of scale anyone who would use such a feature would be doing.

 

Also, it would probly be easier to just recompile the original BoE & use it cover legacy scenarios, but the "Legacy Option" would be more awesome. Either option will allow people to make the required changes to the game to improve on it.

[Celtic Minstrel]

I thought it was already possible to make a monster immobile by setting its speed to 0. If it's not, it's probably a bug, and should definitely be changed.

[JtD]

It wasn't an option. I could never set it below 1 or 2(I forget which). There was a specific setting to make the creature not move, but it had to be done for each individual creature. For breakable terrain, it's way too tedious & wit would better to be able set the speed to 0 and/or add an immobile option to the Monster template itself... That 2nd opens up some brutal options, like Door Ninjas... It can't leave the space, but it can beat you down just the same.

[Cryolemon]

Originally Posted By: JtD

It wasn't an option. I could never set it below 1 or 2(I forget which). There was a specific setting to make the creature not move, but it had to be done for each individual creature. For breakable terrain, it's way too tedious & wit would better to be able set the speed to 0 and/or add an immobile option to the Monster template itself... That 2nd opens up some brutal options, like Door Ninjas... It can't leave the space, but it can beat you down just the same.

Lol at the phrase "Door ninja".

[Celtic Minstrel]

And yet, I seem to recall some of the default monsters (such as living statues) having a speed of 0...

[JtD]

Respect & fear the mighty door ninja! My gaming group & I encountered 1 in D&D, it was devastating... Some didn't make it out alive... Those who did were changed forever...