Oblivion Mod talk:Modding Terminology

Modules, Records, Formids...... WHAT????

I am a newbie in modding, and I found the second paragraph to be quite confusing, mixing computer science terminology that makes the reader having wrong assertions about the meaning, while using a vocabulary I don't even find nor encounter within the CS itself nor the scripting references on this web site... One example:

In particular, records the define placed objects (references) are just as much records as are the base objects they're derived from

Confusing... If the explanation was more clear, it would compensate as we could easily make links with "usage vocabulary" we regularly encounter, and thus it would be a great asset in the sense that it would also teach us about how to use (and more over understand) that vocabulary when taken within Oblivion Modding and TES4MOD context..... But it's not the case unfortunately : we need to GUESS what the author wanted to say or illustrate. And when you are a newbie, this is a real PAIN as you are confronted with "mucho texto" to read and understand at the same time, making links between pieces of information you gather here and there... It the end it is as if this "informative information" was targeting those who are already acquainted and knowledgeable but without teaching them anything new. I don't know for the rest of the article though, as this rebutted me from continuing. Please, can an anglophone correct that paragraph, or can someone make it more straightforward? Thanks. --Unsigned.

Point 1: The paper is not really aimed at newbies, but rather at people trying to make sense out of the mess of terminology used in the existing TESCS. If you're a newbie to TESCS, this isn't really going to help you. Rather its more useful if you're working on tools, or if you're working with OBSE scripting functions and need to understand just what it is a function is returning. :--Wrye 22:42, 10 September 2007 (EDT)

• What do you mean by In particular, records the define placed objects (references) are just as much records as are the base objects they're derived from? Sorry if this could sound unpleasant since you said that you came up with this text after many days of work (...) and since you seem to be the guy who have provided the Wrye Bash utility (kudos!), but I am myself a computer scientist, with at least 12 years of experience in my backpack, and I don't understand what you meant in that sentence --HawkFest 23:54, 10 September 2007 (EDT)

I just looked at this and it seems pretty clear to me. The type of record that defines a placed object is the REFR. A REFR describes the location of the item and some more details about its position (such as who owns it). The entry also contains the FormId of the item being placed. This might link to a ALCH record for a potion, a ARMO for armor, a FURN for furniture and so on. The ALCH, ARMO etc records are base objects and the REFR is derived, since it couldn't exist without the others. Is that a little clearer? --Rpeh^Talk 00:33, 11 September 2007 (EDT)

Thanks for your clarification. I've read over your links and I understand much more where this is leading to. On the other hand, sure it's clear for you since you ALREADY know what this sentence tries to say (you even provide a link), but read the sentence, and tell me honestly if it is well-constructed for any other programmer/developer/analyst who don't already know what's this all about. Remember, I got on this page since it is entitled "Modding Terminology". But if that terminology needs you to be knowledgeable about it before hand, while you actually want to be "knowledgeable about it" (the reason to get to this page), essentially due to the fact that the sentence I gave in example is not well constructed in regards to the english language (and thus in regards to comprehension), it then becomes a dead end. --HawkFest 01:03, 11 September 2007 (EDT)

Actually this morning was the first time I ever read this page (although I was familiar with the Mod File Format page). I happened to notice it on the Recent Changes and thought I'd take a look. A few clicks later and I understood what it meant. The original sentence is quite terse but if it spelled everything out in the same detail I did, the article would be five times longer and people would be put off by that instead! Anyway, I'm glad it helped. Good luck with the modding! --Rpeh^Talk 01:14, 11 September 2007 (EDT)

Don't worry about the length of text. I'd rather read one page of text for clearly understanding something, than limit myself in trying to decipher one liners: "less" is not "better", Marketing paradigms are not good when it comes to the understanding/comprehension of some issue, especially when it comes to explaining abstracted ideas rolled-down to technical considerations... That said, while I am still battling with a light bulb I'm trying to make static so it could be used as a remote Activator... Is this possible btw? I want to summon this light bulb from activating a book, a bulb which in turn would get an onActivate custom script triggered when in the vicinity of the player (some kind of a light switch that would provide much more than just its lighting) - so thanks for your good words, it's appreciated! --HawkFest 02:47, 11 September 2007 (EDT)

I'm afraid I can't help with the actual modding - the only reason I looked at the format pages was to learn how to grab data so I can post it on the wiki. I ought to say here that I think you're being somewhat over-critical of the page. The whole Tes4Mod section only exists because Wrye spent time setting it up to share his knowledge and research with others. Most of it hasn't been touched by anyone else so it's not surprising if the pages only supply the detail he thought it important to include. If there's something you feel ought to be improved then feel free to improve it. The worst that will happen is that somebody reverts your change! --Rpeh^Talk 03:22, 11 September 2007 (EDT)

Point 2: As the "vs. Programming Technology" section makes clear:

Programmers are likely to find CS terminology particularly confusing. The CS use of "object", "parent" and "reference" are all pretty much completely independent of the programming meaning of those words.

I.e. TESCS uses the words object, parent and reference. All of these have fairly typical meanings in computer terminology -- and all of those meanings are pretty much independent of the way they're used in TESCS.: --Wrye 22:42, 10 September 2007 (EDT)

• Point 2: By the sentence are all pretty much completely independent of the programming meaning of those words, I guess that you meant different meanings than their usage within the CS, but... I do not agree. On my part, talking about a reference, is much more understandable and straightforward then using the term record when talking about the instantiation of a base object within the game World, from a mod designer's perspective. Personally I don't know exactly how Bethesda has organized its data structure for storage on some file system; as such, maybe that as a tool builder you're left with being obliged to deal with tables records and sub-records or some non-OOP structural approach, but myself I do not want to do the same and play directly on their data files (unless it is for providing meshes/textures/ modify headers etc) - I'd try to limit myself to the CS as much as possible - I don't wanna be a tool builder, but a mod builder, and as such I'd actually prefer to use some other tool or Wrye Bash for that matter! ;-) However, I'm still not aware of OBSE : do you need to reference record structures instead of using an OOP approach? Because if that record structure is used for simulating the OOP approach (as it would be more convenient in terms of mod design), then the terminology should stay consequent to the OOP paradigms IMHO, the CS's interface itself being much more comprehensible when approached with the perception of some OOP model... At least for the beginning: if I didn't use an OOP mindset for determining similarities and thus be proficient in very little time, I'd still be left in the Oblivion Plane scratching my head --HawkFest 01:51, 11 September 2007 (EDT)

Point 3: I'm one of the (non-Bethsoft) people most familiar with the CS and the internal structure of files (both for Oblivion and Morrowind), and it took me a couple of days of writing, researching and organizing to come up with this relatively simple explanation. But hey, if you can come up with a simpler explanation (that actually explains everything in fairly simple way with no holes, and avoiding common misunderstandings), please take a shot.

--Wrye 22:42, 10 September 2007 (EDT)

• I'd take that challenge only if I've already had provided at least one mod to the community (as a matter of credibility, which is not the case - yet)!... But I'll still give you my first hand perception about this from the time I dived into the CS, as a follow-up to Point 2:

The Object Oriented approach and similarities when considering mod design and understanding (in regards to the CS environment and design in general) : ABSTRACTION.....to be continued, It's late for me now - 2:24 am. Best regards --HawkFest 02:10, 11 September 2007 (EDT)

Again, if you're new to modding, this is not the place to start. A better place is the CS Wiki. This site tends to focus more on file formats, plus some other miscellaneous topics (e.g., this one).

The paper here is designed to bring some clarity to higher level concepts. These concepts won't be very useful until you're already fairly aware of TESCS and it's inherent terminology and how you use the various objects in it.

The paper is geared primarily for modders (of which I am one, while I'm best known for Mash and Bash, I've also got a fair number of mods out for both Morrowind and Oblivion). For tool builders it's also useful, but primarily for guidance on how to talk about the interface of their code towards modders. (The paper arose specifically in regards to how to describe the outputs of OBSE scripting functions to modders on the CS wiki.)

Finally, a word of warning: As a programmer, you're likely to find TESCS (and especially the scripting part of it) very frustrating. There are many annoying limitations (e.g., no loop control statements), plus tons of undocumented or marginally documented and understood bugs. Advanced scripters actually end up leveraging bugs or undocumented behavior in order to get their scripts to work. (E.g., the message for preventing message spam -- send two blank messages in a row is undocumented and unused in original Oblivion -- it works because of some freakiness in the engine. But it's a pretty common technique because message spam is such a problem.) Working with TESCS is worse than programming in basic -- it's programming basic on a very flawed implementation, coded by someone who knows almost nothing about compiler design (e.g., scripts can fail if the type of white space surrounding an if expression doesn't match. Space on both sides? Ok. Tabs on both side? Ok. Tab on one side, space on the other? Not okay. No compiler warning. It just CTDs in game. Welcome to programmer hell.)

Anyway, head on over to CS Wiki. That's the best bet for a new modder.

PS: Minor correction, Rpeh. I've only done about 15% of work on Tes4Mod. DaveH, Rick, Ghostwheel, Resetgun and a few others did most of the file decoding work. I've tend to focus on analyses and organization. --Wrye 04:32, 11 September 2007 (EDT)

• Ok, I was confused by the title of this article. After having read Rpeh's links, I now completely understand the scope of your valued efforts. This correspondence between both terminologies needs to be cleared out if a modder wishes to go forward into more advanced moddding and the type of manipulation it addresses. Allow me to offer this little suggestion: change the title for, let's say, "Advanced Modding Terminology for File Access", something like that... Although a "Modding Terminology" page should still be available for new and intermediate modders (everybody begins somewhere, and a majority will not have the will to go beyond an intermediate level up to OBSE in regards to Oblivion modding - hence the importance of still having a terminology that stays within the GUI, most importantly its design scope and paradigms), IMHO you are perfectly right in filling that gap, that bridge did not seem to exist before your intervention, and for this, hats up dear Sir.

« Wrye: Finally, a word of warning: As a programmer, you're likely to find TESCS (and especially the scripting part of it) very frustrating.

Already done. Frustrating indeed...;-) --HawkFest 05:08, 11 September 2007 (EDT)

I didn't know about the "script line encapsulation" between tabs or spaces that will CTD when a mix of booth is used (which can easily happen by inadvertence), thanks for the tip, I guess it'll save many head scratching when it will eventually happen to me. I now fully understand what you mean, after "fumbling" on the CS's page Function (OBSE). So, we can set/return a script on any object during game time (and much much more)? "kewll"! Usually I'd try to stick with functionalities that would not oblige the player to install/use another "guyzmo" - it's not every gamer who's a computer savvy, or have the will to modify anything from the version that was bought apart from official patches. I know many non-programmers who are like that (and many others that are not), but... Heck it's so much more opened to creativity than without OBSE, that I think I'll make a move sooner that I thought... Many thanks for this eye-opener! --HawkFest 08:53, 13 September 2007 (EDT)