I agree. I assume that the range would be different based on the towns?

It easily can be. In fact, here's a little trick that might help matters:

Each beacon's range could be calculated as a function of some number multiplied by its own scale.

e.g. Set range to ( 2048 * GetScale )

The construction set allows a scale to be set anywhere between 0.5 and 2.0, so this gives us quite a bit of flexibility in varying the range of the no-sleep zone. Using the value in my example, the beacon's range could vary from as small as a radius of 1024 to as large as 4096. Considering that a cell has a width of 8192, the beacon's area could cover as much as an entire cell to as little as one sixteenth of a cell.

Also, because the range is a function of the scale which is set as a reference value and NOT based upon the actual object definition, each beacon could have it own completely different range while still operating on a single generic script.

I think we have a basic outline of a sleep restriction script there.

That sounds 100% brilliant, Toccatta, simply brilliant. That is quite possibly the most elegant way I think that something like this could be handled - it is a nice and open system (gives the possability that one can do just about anything, but may suffer consequences in certain situations, much akin to theft in the game) that should be easy for modders to implement into their own mods.

I forgot to go back and look into things, but didn't you also mention a slick way to be able to handle the fires at all, or were we still at an impass due to the fact that the engine is glitchy with its water detection (something that should really be looked into, I think, by either MPP or MCP, just not sure which project that would fall under most)? If that can't be worked out, I submit the fact that no restrictions should be placed on it, and a method like MC should be used (though I think this no matter what, since it is slick) to give a difference in fire type for outdoors in indoors.

Hmmm, what should the next area of focus be for potential improvements. Sounds like we have methods of calculating Hunger/Thirst/Exhaustion to keep them open, an elegant way to handle Foods/Beverages/Alcohols, methods to handle the restrictions in regards to Sleeping/Fires, a more appropriate and elegant way to handle Food Distribution, outlines of methods to handle lore as best as possible (keeping local foods most prevalent and imported more rare), a general method to try and avoid too much Alchemy abuse possibilities via the additions with the mod, an ability to provide a ground framework to allow Gluby to progress with his attempt to balance Economy in Morrowind, and a fairly slick method to be able to keep this friendly in general for modders to utilize in their own mods (am I missing something here from all the discussions?).

Not really, no. My general opinion is that it's a whole lot of complex and unreliable code designed to force people to do what they want to do anyway (translation: unnecessary). The people that don't care if they're building a fire under water either would turn off that feature or wouldn't be running NoM in the first place, and the people that DO care would be smart enough not to try it. I understand that the point of NoM is to add restrictions to the game for the purpose of making players plan in advance. Having the requirement to eat, drink, and sleep add a new dimension of planning as well as improving role-play. However, I feel we should limit our restrictions to those which enhance the game without a significant risk of having the opposite effect.

After all, what can it really hurt? If a player attempts to light a fire under water and succeeds, it may be a bit immersion breaking... but the player has himself to blame. On the other hand, if the player attempts to light a fire in an indoor cell where there's no water and the game says that it's impossible to light a fire underwater, that will ALSO be immersion breaking. The difference is that it will be OUR fault, not the player's. Given the fact that some members have found correct water detection to be intermittent and unreliable, I'd prefer to err on the side of caution and leave those issues out.

I'm optimistic enough to hope that people are smart enough to not really need all that extra code. At the same time, I'm cynical enough to point out that it's unlikely the vocal ones arguing to include such code will be the ones pulling their hair out trying to create a reliable method of implementing it.

Well, in all fairness, I think it has been mainly me arguing in favor of them (standard Devil's Advocate as I am), and I do intend to do a lot of the needed leg work for this, but - that is neither here nor there really

I must say I do agree though, from what has been seen in discussion so far, and since you have reaffirmed that you did not in fact have a slick workaround for the general issues, then it should indeed be left out (as the simplest and most logical method of doing so seems flawed internally). Unless a project like MPP or MCP ends up correcting this issue (which I still maintain would be a good thing, as it was also mentioned to cause odd stuff with other mods like Water Life as well), there is little point to fiddle with this. Anyways, if it is at some point fixed, NoM could always get an update to add the now working restriction back in if desired at all by the community at large.

Playing a bit of catchup here.

Re: Bedrolls

Changing the bedroll scripts to eliminate incompatibilities with MC and other mods seems like a must-do, so I'm definitely in agreement there.

Re: Campfire/Bedroll/Water Level Checking

Hey, Melian, just a thought -- you say that the GetWaterLevel function returns an anomalously high or low value when called in a cell that has water unchecked? Does it do this in a "reliable" way, so to speak? As in, can we always expect it to be 10,000 units higher or lower than the highest static in the area?

I was just thinking -- if so, would we be able to simply include a check to compare the water level against the player's Z coordinate, and simply disallow the lighting of the campfire or the use of the bedroll only if it's within a certain range? This would, of course, fail to prevent setting up camp in the middle of a deep-sea diving expedition, but, assuming the answer to the question in the paragraph above is yes, would it not reliably prevent the most noticeable and egregious of the glitches?

Overall, I agree that increasing the player's already hefty, FPS-draining scriptload with an overly complex (for the tiny, simple purpose) is really not an acceptable tradeoff for preventing a player from setting her bedroll/fire in the water. But if it could be done simply, easily and relatively reliably, it seems like one of those things I personally appreciate in games. I always loved testing absurd but possible things to see if the developers accounted for this or that -- it's why I heftily respected the Infocom designers for those old IF games. For me at least, it's not just about preventing the immersion-breaking effect of a player getting away with doing an inanely absurd thing, but rather about a tight ship, so to speak. It always greatly increases the value of the experience for me, aside from specific RP immersion issues, to see that a lot of thought went into accounting for situational variation. That may be just me, though. But, again, to be sure, not at the cost of using an unreliable method or increasing the scriptload. It's a very, very minor little thing.

Re: Keeping Players from Sleeping in Towns / Toccatta's Detector Beacons

Agreed. That sounds like a great method, and fairly simple to implement.

Re: Vality's Grass and NoM

Hopefully we'll be pretty low impact in that regard, for the most part.

Regarding the beacon idea, would it possible to take an approach similar to the one taken by http://planetelderscrolls.gamespy.com/View.php?view=Mods.Detail&id=3846? The approach here, I believe, was to alter already existing common items (I.E. Kwama egg sack containers and such) with scripts to cause effects.

The "beacon" script could be added to (just as an example mind) torch brackets or other items that are most commonly found in cells where a separate beacon would have to be placed. This approach would have the added benefit of not having to make alterations to the cells themselves, thereby keeping down conflicts in those cells that are frequently modded.

It would also give the script a fair chance of working in a modded cell.

Thoughts?

Tizzo

http://planetelderscrolls.gamespy.com/View.php?view=User.EntriesListing&id=319848

I must be misunderstanding your suggestion, because modifying something which already exists in a cell is MORE likely to cause a conflict than adding something new. If you place an invisible object in a cell outside of the playable area, the chance that some other mod will come along and attempt to change it is ZERO. On the other hand, no matter what existing object you change, there is always a chance that something else will also try to modify the object.

And given the design of the beacon, the scale will have to be modified on a per-reference basis to get the radius set up correctly. Not only would that mean adjusting the size of an existing reference object, but it would also ensure that the cell information is changed. So your suggestion would not only NOT prevent the cell information from being updated, but would increase the possibility of conflict.

That is very much what I was trying to get at, you have just said it far better than any of my attempts ever (or perhaps somehow just neglected to place focus on). But, I also agree in regards to if things can be done nicely. I am still thinking that this issues with the detection of water might need correcting via MPP or MCP (as it stands, more than just NoM could potentially benefit from something like this). Again, though, I simply do not know which are this fix would be best applied to - MPP or MCP (though my guess leans towards MCP to make the non-selection of the check box for Interior Water denote no water in the area per the detection scripts).




I think I must ride in agreement with Toccatta here, unless we are both missing what it is you are meaning. The current method is specifically designed to avoid any kind of conflicts, though you are correct it would not account for mod added cells and such (this would be something more up to the modders making these, though as has been discussed before, I am fairly certain a handful will get patches provided by the project - TR comes to mind. It will also be easy for them to do this as we are also taking a focus to make things easy on modders, so directions and tools will be provided, much like they are now, to assist in this process), but I still maintain it seems to be the best method available to us to be able to accomplish what is desired.

I'm only guessing here, I haven't tested it, but I'm *assuming* that the default water level would be 0, and that this is in fact the problem since many cells have statics placed below 0 - sometimes (but not always) quite a long way below 0.

A side note to Red Eye: I guess it would be possible for MPP to set the cell to have water and set the water level low enough, but I'm not sure if that would be a reliable fix - wouldn't it be overwritten by any mod that changes the cell? If so it would be better to fix it in a mod that loads last or nearly last. Also, a great many modded cells have this problem, because the default position the editor puts stuff in when you create a new cell is well below 0 IIRC.

The most reliable water check I know of is the one I posted earlier. I use it for companions' z-pos fix while swimming (otherwise they only really follow on x,y, they don't move at all if you go straight down/up). Basically this would be quite reliable on systems where GetSoundPlaying is reliable (which is most). But like I said, you'll need a global script to figure out if the cell has water, because the sounds only play when the player moves. And it just won't work on some systems. But personally I'd say err on the side of false negatives rather than false positives.

I don't know of any check that would always be reliable, sorry.


Thank you for explaining this! I tend to think "If the player wants to cheat/do daft things they can always use the console, so why bother trying to stop them?". I never got why people bothered with that before.

The mod I linked uses a script on a few containers to prevent the effects of the mod from occuring in certain areas. I thought it might provide a useful example of how to prevent or limit something from happening via script within a given cell.

Plus, I wanted to plug a great little realism mod. =) Sorry it wasn't helpful.

Your idea for dynamically calculating radius using that function seems sound, but I'm wondering how processor intensive it will be. How fast is Get Scale?

Tizzo


http://planetelderscrolls.gamespy.com/View.php?view=User.EntriesListing&id=319848

About average I think, but even if it was slow it wouldn't really matter since you could use it once and set a var from that. Checking a var is about as fast as anything can be, and locals aren't lost with reloads.

Indeed, thus my blurb in regards to thinking it would probably be better for the MCP to try and correct this somehow, but I don't know if it would be possible in that project either, though I suppose a request could be thrown in the thread...

Ah well. I figured that idea had probably been hashed out and found unviable well before, but I had to ask. Thanks for explaining that, Melian.


:)

It's pretty difficult to pin down, it seems, and therefore eludes understanding during discussions, I think because it's really very ephemeral and rooted in psychological stuff that's fairly remote from what we think about (or even recognize) in daily life. For example, at least for me, I think also it's related to the issue of attitude appeal (beyond and apart from the usual issues of immersion and suspension of disbelief). You know the old cliche about nice people not being as attractive as people with a little bit of attitude? Why "they" like bad girls/boys? If the game is too squishy, too much of a pushover, it's just not as interesting. Personally, I want it to push back. To smack me when I get too far out of line (and sometimes to reward unusual cleverness). (And here I am referring to things apart from the usual things considered in the concept of "challenge" or "difficulty" -- I want the game structure to maintain its integrity, and not simply let me disrespect it from within its own structure -- hence the "tight ship" thing.)

I fully recognize, though, that this bit could be just my own quirkiness.

The only slow functions are those which have to check multiple objects (like GetDetected) or have to perform complex mathematical calculations (like GetDistance). The GetScale function simply reads one bit of reference data on a single object. It's about as fast a function as exists within the game. Considering the minimum CPU requirements to play Morrowind is 500Mhz , the function might take a millionth of a second or two.

And as Melian points out, even if it were a slow function, it only ever needs to be performed on any given beacon ONCE, and there's unlikely to be more than one or maybe two in any given cell.

Nah, not just you, I agree 100% with you, thus my constant pushes for things like restrictions and such. On the same note though, I do agree that they need to be left out in places where they will only hinder the game (decreased performance, inconsistent results, etc). As many ways to tighten up the ship as we can would be best, and I think in the end things that really bother people could be set to some configuration menu, ommiting only in places where it is simply no good for the overall product in the big picture (as it is looking like the water checks may very well be at this point in time).

I would just like to ask again: What is this about a gender variable added by MCP? I looked up all the MCP release threads I could find but couldn't find anything on a gender variable. =x

The variable ID is "PCGender". It's set from the char gen captain's greeting when he takes your char gen stats sheet (dialogue text is "First, let me take your identification papers. Thank you. Word of your arrival only reached me yesterday. I am %name. But my background is not important. I'm here to welcome you to Morrowind." - it's in greeting 1).

There is one difficulty with using this, which is that it won't be compatible with alternate char gen mods unless the modder adds it, and there's no way to tell if the player is male or if the var just didn't get set (default value is 0, male pc is also 0). But that's not really a big deal IMO, just mention it in the readme and give instructions on setting it from the console, or if that doesn't suit then keep asking the player during config.

I wasn't aware that the Morrowind Code Patch modified the chargen captain's dialog.

Perhaps someone has gotten MCP and MPP confused. Personally, I think it would be a VERY bad idea to design NoM 3.0 so that it relied upon changes implemented by MPP or MCP as that would cause the mod to break for those people that aren't using them. While there are some people that think MPP is a "must have" mod, that opinion is hardly universal. I have my own private bug-fix mod which addresses everything in the game which I feel needs to be fixed, so installing MPP would break quite a few things as it attempts to address things I don't want addressed or reverts things that I want fixed that others either haven't noticed or don't feel are broken.

I have neither the time nor the inclination to attempt to merge my current bug-fix mod with a project that others have put together regardless of how "must have" some people feel it to be. And while there is a very slim possibility that I'm the only person in the world that feels that way, somehow, I think it unlikely.

Making a mod require specific expansions is an accepted part of modding. Also, as a general rule, it's a great idea to attempt to make one's mod compatible with other mainstream mods wherever possible. However, making it RELY on another mod is a very BAD idea, except where the mod is explicitly intended as a patch to it.

The gender fix is added by the Unofficial Morrowind Patch v1.6.3b. Since everything from v1.6.3 is included in quorn's MPP (which is a continuation and expansion of the UMP), the gender fix is also part of that patch.

MCP does not make changes that can easily be handled by a plugin - it's main usage is for code level patching of the exe. It does not touch the PCGender flag.

UMP v1.6.3b has been around for a long time, and it's acceptance means that many people are likely still using it instead of the MPP (those unaware of the update or reluctant to use a beta). I understand what you're saying Toccatta but while there may be others running a comprehensive patch of their own design, I think we'll find that number to be few - most people don't have the inclination or perseverance to put a big patch together themselves, but want to use what patches are widely accepted in order to avoid conflicts. Anyone seeking out and asking about data fixes on these forums is going to be directed to the MPP at this point.

I do agree that one should avoid making their mod rely on another. It would be a simple thing to include the gender fix in one's own work exactly the same way UMP implements it, which would avoid conflicts and cover anyone not using one of the unofficial patches. Considering the amount of time the UMP and it's method for the fix has existed, and the fact that there are quite a few people using that method by virtue of having either the UMP or MPP in their active load list, that method should be a prime candidate if this project considers including such a fix.

I agree. It would be much more appropriate to include compatible solutions within NoM 3.0 to solve those problems. Keeping the implementation method compatible will increase the size of the mod only a small amount, and will ensure it neither conflicts with MPP (or UMP) nor needs to assume its presence.

However, it would be impractical at best to use identical implementations, since the gender variable is defined during character creation. If we don't want the installation of NoM 3.0 to require starting a new character, we'll have to find a way to configure the variable after character creation.

Asking a question during the configuration routine is acceptable as a last resort option. The configuration routine could easily be written to skip over that question if the PCGender variable is already set... but that presumes that MPP is coded wisely enough to NOT allow zero to be a valid value. Preferably, the PCGender variable will be one of two different non-zero values with zero indicating an unset status. On the other hand, if it allows zero as a valid value, then it's impossible to tell if the value is correctly set to zero or if it's merely unset.

Perhaps, instead of configuring NoM through a scripted series of messageboxes, we could have a "configuration NPC" appear to help the player configure NoM through dialog instead. That would allow us to use the same dialog-based tricks to set the gender without needing to ask the question.

Good point about zero value.

Looking at the dialogue entries for chargen captain, PCGender indeed gets set to 1 or 0; first depending on PC six = 1 (female), otherwise PCGender is set to 0. Obviously that should be corrected to set to 2.

I'm not sure how many mods are using the PCGender check (IIRC, PRE and Nudity Greeting Expansion by GlassBoy might - both dialogue mods), but most will likely be checking for PCGender = 1 since the whole reason for adding the global variable is to allow female gender specific responses. So if those were structured correctly, the dialogue would filter down to a response that doesn't need to check for PCGender != 1.

I'll make a request in the MPP v1.6.5beta thread regarding this. There's also the 'patchScript' included with UMP/MPP to set the PCGender variable in an existing savegame - that will also need to be updated.

Another option would be to make the default value -1 (or something else other than 1 or 0). But either way, it's generally a good idea not to have meaningful values that are the same as default values, especially if another mod might want to check the var. And IIRC, NoM has been guilty of this too.

If a mod checks for a global variable and it isn't present at all, won't the value return as 0? If so, then the default will need to be 0.

I did some further checking in PRE and NGE - both use multiple dialogue entries filtered by Male or Female to give unique gender responses, so those mods are not looking for the PCGender flag. I'm not really sure what mods might check for it without extensive research...