Jump to content

The possibility of Vahnatai as a playable race


Recommended Posts

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.

Link to post
Share on other sites
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.
Link to post
Share on other sites
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.
Link to post
Share on other sites
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.
Link to post
Share on other sites

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.)

Link to post
Share on other sites
  • 1 month later...

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.

Link to post
Share on other sites
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?)
Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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...'?

Link to post
Share on other sites

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?

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites
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".
Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...