DrakeTheDragon

I think "controlvar = 3" was so "controlvar > 1" previously allowed for the chest to always be opened without answering the question "again" every time. That's what the "Activate" call in "OnActivate" was for after all. Having to do the riddle only "once".

Hmm, that's so unearthing old memories of my own initial failures when making my dragon teeth. So what exactly did you do with those meshes? You took the Khajiit teeth, imported them into Blender (how? which way?), reshaped them so they fit a human head and then exported them into NIF again (again how? which way?)? Teeth in Oblivion are both, mounted to the "head" bone, so they follow along the character and stay in place at the head, and shape and expression morphed, so they move along when the mouth moves, always according to the morph key currently applied. I don't know if Khajiit teeth have other morph keys now than human teeth or the like. But I do know the connection to the morph files (EGM & TRI) is easily broken by many ways of import/export and editing tools in Blender. Vertex count "and" order need to stay 100% untouched by any means, or you'll need to create a new morph file set. Are you trying to use the edited teeth NIF with the human EGM/TRI files, or did you also copy along the Khajiit EGM/TRI files for the teeth? (If they're Khajiit teeth, they won't work with the human EGM/TRI files and vice versa due to different vertex count and order in both.) Now, I do know the head meshes also have some, what I call, unapplied translation offsets to get them into place above the shoulders. The origin (0-point) of the actual mesh must be where the head node is, relatively. That's why when you import a head mesh into Blender it will be sunk into the ground (maybe also turned or tilted, can't recall). However, you don't want your head to be between your feet, so you give it some translation upwards and back/forth until it sits at the head bone's place. If this translation is "applied" in NifSkope, that is the vertices' internal position gets updated accordingly, then the morphs will no longer work, as they are based on offset from 0, which will then be between your feet again. That's why I call it "unapplied" translation. I'm not sure how exactly it is with teeth, but pretty sure they're also located in dependence to the head bone node. Though their NIFs never have them offset, so it likely doesn't matter here. If you did "move" them in Blender though (the Khajiit snout is a bit longer/more protruding than the human mouth, so you likely did), then there's only 1 of 2 ways that'll be right. Moving the origin, as in Object Mode, is not the right way. Not sure how much change one can introduce to their location in Edit Mode before the morph offsetting will go screwed. My memory's quite fuzzy by now when it comes to details from those many years back, but I do recall I did have to meticulously im- and export only from and to OBJ back then, every time making absolute sure the "keep vertex order" option was definitely checked, and I never could use any of the fancier scripted deform tools, as those would've certainly messed vertex count and/or order up.

Well, from what I know about normal maps, they are these 3 color channels (red, green, blue) for a reason, each channel giving shape in a different one of the 3 directions. I actually have no idea what could happen when making one of these channels black or grey, well, other than removing this channel's impact from the 3D shape. What I do know though is, the specular map from other games in Oblivion is found in the alpha channel of the normal map. That's why it has to be so bloody damn dark, if you don't want it to shine like crazy. Additionally it seems to work as some kind of multiplicator/factor for all the other surface effects as well, like the "highlight" texture apply type making things plasticly shine or the "EnvMap2" hardcoded material name making surfaces reflect a pre-rendered environment map for a metal or glass effect. All these are either emphasized or diminished by the amount of white in the normal map's alpha channel (i.e. specular map). The glossiness, of course, is just that. The higher it is, the more glossy (wet look) the surface will get. Turning down the specular part of the material does get rid of the specularity effects, too. But changing these settings for a hardcoded, game-controlled material like "skin" is not guaranteed to have an effect. Not all but most of these are overridden by the game according to your slider choices in CharGen. And some special skin shader for other rendering effects is also laid over the surface of such objects. But even if the material setting you change will survive into the actual game, if you did it to a body part mesh, you'll have to re-do it to every body part mesh inside every clothing or armor item's NIF you're ever going to wear. The body mesh NIFs are only used by the game while the actor is naked/not wearing any other thing. Every item you equip will replace the body inside/underneath. Additionally, the game uses 1 body for all races. So what you change in its materials will effect them all. With Blockhead you can isolate the last problem by making "only 1 race" use this particular custom body mesh. But when it comes to clothing and armor items, the previous requirement still stands. I'm far from an expert in texturing, much less materials, though. So that's just what I know. And ever since Argonian Beautification and having had to convert one set of skin textures to all bodies in existence in the past I'm seriously inclined to staying the hell away from all other bodies but Robert's Male/Female, due to the hell I had to go through making scaled and structured textures not look horribly warped and stretched everywhere on all of the others. Never again, I tell you. :pinch:

Very. The resulting normal map must be almost completely see-through in most cases. Every bit opaqueness will create some shine. Most surfaces do shine at least a little bit, so I'm never making them 100% transparent. But it's always very close. When it comes to skin textures it's often a matter of taste though.

Still curious to learn which size the array returned by "PlayerRef.GetTargets" has here. My guess still is it's "0", and that is why the "let" fails.

Actually I think Nexusboiz is right. The array does not need to be constructed, if it's used as the target of a function returning an array. But QQuiz will know better than me which one is right. Additionally it won't hurt to first construct it and then overwrite it with the function's return either, to play it safe. But think of it like the "ar_Construct" call is taking place -inside- the "GetTargets" function call. However, the "GetTargets" function does sound like it won't really work when called on the player but only when called on NPCs. You know, the game's internal combat AI handling, who's to attack who. Additionally I recall discussions from the past where no easy solution could be found to get a reference to the enemies currently attacking the player. So this function having been the solution all the time would be surprising. There is a simple way to check that though. If "ar_Size arrattackers" returns "0", as in a mandatory check before trying to access a potentially inexistent array index, then the function didn't return any attackers.

"SetEyes" said "invalid inventory object"? That doesn't make much sense. It's nothing to do with inventory objects at all. So you fixed it by using a totally different function instead? But it's a function from Blockhead, an OBSE plugin, that is it, too, requires the CS to be launched with OBSE support, which you now do apparently, so that's good. Still wondering why the "SetEyes" function of all things is giving you errors here. Maybe it complained about the wrong/an inexistent EditorID being given as parameter for the eye type?

Visual Basic is the 3rd language I learned. The language is Basic still, but it's also got a drag&drop editor to piece together windows and dialogues. Then you can right-click on buttons (or similar) and add Basic code for what to do when it's clicked. Hmm, that was in 7th class I think. Man, that's far back in the past.

No, that's not how the "SetEyes" function works. If the CS wiki says something like "eyes:ref" or "npc:ref", it's a combination of the name for the parameter and the type, but it still means only a simple parameter or variable. The way it's typed inside the script above is the correct one already, and I think EyeDarkSeducer is also the right EditorID. The only way the CS can't know the function is when it was launched without OBSE support. The remarks at the end are also no sign you're inside the CSE. They're just copy&pasted from a script that was written in it before. If you then start the normal CS without OBSE, the remarks will still show up inside the source code.

You're making good use of the "1 array per kind of data with identical indices each" concept in your scripts so far. But you can definitely store a ref and 6 floats in 1 array index, very handily accessible even, if you use an array of StringMaps. I am, or was, doing it quite a lot in my own scripts, as I'm used to data structures like these from database interfacing, data modeling, in PHP, Java, C and stuff. [ 0: { ref: "ff345a", posX: 10.5, posY: 10.5, posZ: 0.0, angX: 0.0, angY: 0.0, angZ: 0.0 }, 1: { ref: "ff345b", posX: 10.6, posY: 10.6, posZ: 0.0, angX: 0.0, angY: 0.0, angZ: 0.0 }, ... ] (That's closer to JSON actually, but it's easier understandable what the structure is.) In ObScript with OBSE it'd be set up like this: array_var aMyList ... let aMyList := ar_Construct Array let aMyList[0] := ar_Construct StringMap let aMyList[0]["ref"] := <some ref ID> let aMyList[0]["posX"] := 10.5 let aMyList[0]["posY"] := 10.5 let aMyList[0]["posZ"] := 0.0 let aMyList[0]["angX"] := 0.0 let aMyList[0]["angY"] := 0.0 let aMyList[0]["angZ"] := 0.0 let aMyList[1] := ar_Construct StringMap let aMyList[1]["ref"] := <some ref ID> let aMyList[1]["posX"] := 10.6 let aMyList[1]["posY"] := 10.6 let aMyList[1]["posZ"] := 0.0 let aMyList[1]["angX"] := 0.0 let aMyList[1]["angY"] := 0.0 let aMyList[1]["angZ"] := 0.0 ... ;You can even iterate over this construct later as usual: array_var aItem ForEach aItem <- aMyList PrintToConsole "item index: %.0f, item name: %n", aItem["key"], aItem["value"]["ref"] PrintToConsole "pos: (%f, %f, %f)", aItem["value"]["posX"], aItem["value"]["posY"], aItem["value"]["posZ"] PrintToConsole "ang: (%f, %f, %f)", aItem["value"]["angX"], aItem["value"]["angY"], aItem["value"]["angZ"] Loop Needless to say in my scripts I'm often using functions to create 1 StringMap item per call. Typing out a "let" for every index and every field each will quickly become a typing overkill.

That is the correct syntax, yes. What exact runtime situation does lead to the error you receive? You aren't trying to skip indexes or start with numbers other than "0"? Oh, but there's one more thing that should be taken care of: For every "indexA" you'll also have to call "let arrayVar[indexA] := ar_Construct Array" as well at one point to initiate. You cannot simply go like in PHP or C et al and decide about the array's dimensions just by setting another index, nor can you declare it as a 2- or N-dimensional array right from the start. Every dimension has to be specifically initialized as another array for every index.

You need to comment out the entire line, not only the variable name, more like so: ; short ELSDlabhiReffollow However, that's not the same name it was complaining about before: "Variable dahlablifollow unreferenced in local context."

Raising "BottleIndex" at the end of a "while" it will be taken care of never to exceed the max index. Raising it at the beginning of some conditional block, where no condition checks for how large it already is, can easily go beyond the max. index of the array you're trying to access. You should definitely add in a check there before the array access. And I wasn't telling to use one kind of increment instead of another. I was telling there was one line in the "State == 12" block which was neither and to me didn't look right: Let BottleIndex := + 1It was still inside the first reworked script, but I can't see it anymore inside the last. So it was also fixed along the line.

As far as I know setting a "ref" variable to "0" or better yet an "array_var" to "ar_Null" (and there's something with "string_var", too) does exactly that. But that's only in certain specific contexts. Other than those there are no pointers that I know of in ObScript/OBSE.

What is "dahlablifollow" meant to be in this context? The EditorID of the follow script package? No, wait, "unreferenced in local context" means it was defined somewhere but never used. For whatever the reason the compiler doesn't like unused variables in scripts. Either use it somewhere or get rid of its definition at top and the error should go away.

I couldn't yet look through the entirety of the work flow, but do check your "BottleIndex" in all States. It's very often increased like in a loop, but only very rarely reset to start over. Especially there's one loop situation in State 2 where it starts with an increment, but "BottleIndex" was previously already set to "1", so this loop will always start at "2", as can also be seen in the output above. Don't think that's intentional or is it? Though I'm wondering... The printout above is coming from State 30 only, not the one where I'm seeing "BottleIndex" be "2" at the start. And yet, even though it neither starts at "2" nor is allowed to reach "46" within the loop, that's what the printout says. Is this perhaps just a timing problem, "printc" firing shortly "after" the increment before it in code took place? It's pretty weird either way. And there's one line right at the start of State 12: "Let BottleIndex := + 1", which either isn't correct syntax to begin with or won't do what I think you want it to do. If it "does" accept the "+ 1" and won't take it as an error, then it will simply set "BottleIndex" to "1". It does look like it's intended as another increment though, which types like this it won't do. Increment in an OBSE statement is "Let BottleIndex += 1", or as you previously did "Let BottleIndex := BottleIndex + 1". Maybe I'll be able to give it a closer look again later, when there's break or I'm done with work, and after a good night morning's sleep.

Well, if you really want an official response in regards to whether releasing something is fine with the rules, you should ask one of the Community Managers about that. They decide, when things are unclear. As a rule of thumb, if an author already made a statement about their permissions, be it in the popup or written in their description or readme or even a text file somewhere, and said statement can be reproduced when asked, permission is usually considered granted. You definitely don't need to contact and ask those authors again who already used diverse means to publicly give their okay, unless you really want to make sure your intended use is also covered by this or you're unclear about some of what they say. A simple mistake in interpretation of permission terms won't automatically lead to some sort of punishment. In most cases only the file page in question will be removed, or sometimes you'll also be asked to just remove the infringing contents yourself instead. So that's it basically regarding the official terms and protection of copyright. However, especially in cases of so-called fan work, you'll also often get into another legal territory, where brands and names are concerned. These cases, however, will usually not be treated as a violation of the terms. You do release your work, however, on the basis of a single request from the brand holder leading to its removal from the site. The large MERP project of the past coming into mind here, trying to recreate the entire world of the LOTR franchise in the Oblivion game, which was completely removed from the scene once the franchise's lawyers showed up to intervene. Fan work of any kind is always on the merit of implied permission, which can always be denied by the franchises at any time. It'll usually not result in much more than the removal of the work, especially if no money is involved. But don't quote me on that. But that's just me telling from personal experience now. Questions like these are way above my pay grade, and I'm only responding here because Oblivion modding is my thing. You seem to be a very talented newcomer to me. It'd be a shame losing your (future) nice quality work due to only a misunderstanding of the rules. I create a lot of random things inspired by an even bigger lot of random sources myself, well when my free time allows for it. It's just never a 1:1 copy of an existing work or design. That's just not my thing. I want my own. Doesn't mean much of it isn't still looking very close to the source material in many points. If you're afraid of Nintendo intervening should you label your work with the LOZ or Sheikah name, why not making it something else instead, perhaps even more close to the lore (I don't like that term myself, but hear me out) and call it Akaviri design, or whatever. It is in its basis just asian and ninja designs after all. Would just need to get rid of the potentially trademarked logo then. It's already no 100% identical match anyways due to the different game design. A few texture changes here and there, and only those "in the know" would be able to draw the connection still. But that's just what "I" would be doing, and for different reasons, too.

Hmm, can't say I've ever had a problem with it so far. If you tell it to remove 30, and it has 30, then it removes 30. Where are your parameter variables coming from? Did you check "StackSize" really was "30"?

Well, the most simple reason for why changing a script in C leaves all internal connections intact and in the CS(E) doesn't is the difference in compilation flow. In C, when you edit a script, nothing happens immediately. You have to recompile the whole project again first, which does every file. In the CS(E), when you save a changed script, "then" it's automatically compiled, but only the 1 script you saved, not the others. Unless you at least re-save these, too, they won't update their machine code. Besides, something's giving me doubts that ObScript is really compiled into assembler for use in the game. I'd rather imagine it's another different proprietary language or code only GameBryo uses. But the result is the same. ObScript is source code, like the text files in C, and saving them starts compilation into (game) machine code. Man, that's memories, designing and running primitive CPUs, with RAM and registers and all that stuff, in hardware simulators at university to get the hang of how they work. I kinda miss those times.

Still not sure which of the shadow-introducing mods you might use, Oblivion Reloaded or ShadeMe, whichever one also introduces actor shadows like that. But it could very well be the mod you removed, "Improved Fires and Flames", was introducing weird or too many light sources into this cell, as you were also told on Reddit. The commenter only was unaware the original game has no such shadow system they were talking of by itself but needs mods first to even introduce these effects. It would also be fitting you see it flicker whenever you move. If I recall correctly the shadows from these mods are cast in relation to the player position, so it doesn't have to calculate shadows in a place a hundred miles away and unseen but only close enough to you. It's already causing weird shadow pop-ins, moving shadows and other oddities on distant objects in many videos of it I've seen.

Man, don't call me such things. I'm far from a Messiah or whatever of modding. I just know a few things about it and have a habit of telling them to everybody who asks. Back in the days that was the norm around here and everybody did it. Nowadays... only few of those I passed it on to even seem to share it with others still. I'm by far not the first who knew all of this, everybody, but don't let me be the last. I won't be around forever. You need to also pass this knowledge along, else it'll be lost at some point in time. But back to topic, I'm afraid I'm seeing another mistake. No idea exactly why "GetNumItems" returns 1 here, if you say the container should be empty. But GetInventoryObject is again "zero-based". You asking it to give you item #1, when it's item #0 you're interested in, can only fail when there's exactly 1 item inside. You want to know what "GetInventoryObject 0" is but are asking for 1 instead. It would be really interesting to know what "0" is now. Could it even be there's just an unplayable token, as from Maskar's, inside?

I'm not sure you will find any direct culprit. To me it almost looks like the NPC is stepping into and out of shadowed areas repeatedly, like once every step of the stairs? As there were no such shadows or lights in the Vanilla game, I wager a guess you're also using some plugin-less (thus not showing in your load order) mods changing lighting, shadows and such in your game, else the shadows I've seen in the video would not exist. Does the flickering also happen while they stand completely still or only when they move around?

I was wondering... you said you did all the manual stuff, so I was half-expecting/accepting you also edited your Oblivion.ini, but... I also need to keep in mind how many people told me this already while they completely missed editing the "correct" INI file. They say Oblivion.ini but got "oblivion_default.ini" instead, not inside their "MyGames/Oblivion/" folder but inside the actual Oblivion game folder, which is the wrong one and won't have an (immediate) effect. You doing it manually the fonts weren't correctly changed, but once you did it with a manager (BAIN = Wrye Bash) it worked? That does sound like you could have actually gotten the wrong file for your manual editing before, or your manual editing was somehow done wrong. Now I wonder which it was. If you don't mind elaborating that is.

You do know you can toggle the display mode in the CS(E) from line numbers to offsets, too? If I have the "offset", I won't have to "find" the line.

Would this help? https://cs.elderscrolls.com/index.php?title=GetPlayerSpell