Talk:OBSE Wish List

Disputed Changes

If you think something should have stayed on the list or if you think a change in one of the items misinterpreted what was meant, please let us know.

Dejaside's Binary Examples

these Is______ functions suggested by Dejaside (unless noted otherwise)

• IsEmpty - checks if container is empty. - Available - If GetNumItems returns 0.
• IsBook - checks if item is a book - DONE
• IsSkillBook - checks if book teaches a skill
• IsWeapon - checks if item is a weapon - DONE
  • IsMelee - checks if weapon is melee. - Available - combination of IsWeapon and GetObjectValue 103 (weapon type). All types but 4 (Bow) are Melee.
  • IsRanged - checks if weapon is ranged - Avalilable - combination of IsWeapon and GetObjectValue 103 (weapon type). If type is 4 it is ranged.
  • IsStaff - checks if weapon is a staff - Available - combination of IsWeapon and GetObjectValue 103 (weapon type). If type is 5 it is a staff.
• IsAmmo - checks if weapon is ammo - DONE
• IsEdible - checks if item is edible (note: the ai uses 'restore fatigue' to determine edibility) - Available - GetObjectValue 210 (food) returns true if the ingredient is edible.
• IsIngredient - checks if item can be used in a potion - DONE
• IsActivator - checks if object is an activator - DONE
• IsDoor - checks if object is a door - DONE
• IsLoadDoor - checks if door loads a new cell
• IsContainer - checks if object is a container - DONE
• IsAnimated - checks whether object has an animation (?)
• IsApparel - checks if item can be worn Available - combination of IsClothing and IsArmor.
• IsArmor - checks if item has armor rating - DONE
• IsRing - checks if item is a ring - Available - If GetObjectValue 3 (equipment slot) returns 6 or 7 it is a ring.
• IsAmulet - checks if item is an amulet - Available - If GetObjectValue 3 (equipment slot) returns 8 it is an amulet.
• IsKey - checks if item is a key - DONE
• IsApparatus - checks if item can be used to make potions - DONE
• IsMisc - checks if item has no value beyond its value in gold

Just wondered if consolidating some suggested functions might make things easier to read. i.e., for the various isMisc, isClothing functions, wouldn't they be better served by a single getObjectType function? Don't want the list to become overwhelming, that's all. Scruggs 22:26, 1 August 2006 (EDT)

Dragoon Wraith TALK 09:35, 2 August 2006 (EDT): Yes, as mentioned in the thread, I'm going to in charge of keeping this clean. That project comes as soon as I finally finish Danger Sense for Addiktive (tonight, probably). It'll be cleaned up by the weekend.

Dragoon Wraith TALK 12:07, 2 August 2006 (EDT): See, it's cleaned up now! And it's only Wednesday!

Anyway, Dejaside's idea was that these functions would be very easy to create for the OBSE developers, and combinations of them could be more useful than a simple GetObjectType function - for example, an ingredient with Restore Health is both edible and an ingredient - GetObjectType would only return one of these pieces of information, while having these binary tests would allow you to determine both.

CellScan

This is to discuss the different approaches taken by former Script Extenders to realise a "Cell Scan". MWSE did it that way: it used three different functions to chose from three different items lists (I suppose these were pre-defined by the game):

• FirstNPC - to select the NPC/Creature list
• FirstStatic - to select the Statics list
• FirstItem - to select the list containing other items in a cell

All these returned the first ref on the list. Then, there was NextRef which took a reference (like the ones returned by the commands above or this very command) as a parameter and returned the next ref after the one specified. Refs could be encoded in long type variables and used in a similar manner as in Oblivion (imho better, one could actualy access variables on the refs).

Afaik MWE could only search for NPCs/Creatures which it calls "Livings" so the command was named NextLiving. MWE remembered the last encountered ref automatically. It returned a "-1" value (to a remote variable) if the scan is through. ClearLiving was used to reset the search to the first item on the list.
[there was also a third command needed to succeed, but this is of no interest here]

Now, I think the question whether such a function is necessary is redundant. Mandatory though is the question how this should work. Personally, I like the MWSE approach a bit more, but it showed to be slower (though cdcooley said this was because it wasn't optimized; I can't tell).

Then, there is the concept used in the OBSE for Inventory Scan. Iterate using a number instead of a reference.

Grey's proposal

I was about to propose a mix of MWSE and MWE approaches. One command to actually select a list (or item type) to scan and one command to actually iterate through the list:

CellScan [short_integer]

Takes a mandatory integer as a parameter. Returns the current state set in the parameter, and "-1" if none.

0 should be "all" ?
1 should be NPCs/Creatures
2-... should be additional lists / types of items

NextRef [optional: ref]

This returns the next reference after the currently selected (or the first on the list if none). Returns "-1" if there is no "next" reference.

The optional parameter is to shorten the time needed to do the scan if we know two references are near each other. "-1" as a parameter resets to the beginning of the list.

====example:==== (simple, runs only once)

scn ExampleQuestScript

ref tempref ; takes the output of NextRef to work with the object

short damage ; only needed for this very example, in which we do a dnd-like "fortitude save"

CellScan 1 ; search for NPCs/Creatures

while done == 0
      set tempref to NextRef
      if tempref == -1
         set done to -1 ; we only want to loop once
      else
         if tempref.getav health <= 5 && tempref.GetDead != 1
            set damage to ( GetRandomPercent - tempref.getav endurance ) / 10
            if damage > 0
               tempref.modav health damage
            endif
         endif
      endif
endwhile

StopQuest ExampleQuest

I'll try to find a better example that uses all of the possibilities, but this should work for now. --Grey 15:50, 3 August 2006 (EDT)

Dragoon Wraith TALK 16:19, 3 August 2006 (EDT): Why can't we just use the tried-and-true method of casting a large-radius, LOS-ignoring scripted spell for getting nearby references? Is there a particular reason you need to be able to iterate through the cell rather than simply scripting everyone in the cell?

Grey 16:44, 3 August 2006 (EDT): Well, performance and speed, I suppose. Plus, do spells affect all items in a cell, not just NPCs/Creatures? And I think it is more reliable than the method mentioned. But you are right to question this request. "While" is needed to really work with it and the binary functions listed at the top first make this really useful.

To wait for a spell to be cast through the whole cell and wait for the responses of the scripts started on each NPC in range ... sometimes just isn't the right thing to do I believe. My game is quite slow already; I notice some delays in Quests of the original game and even though I know of prioritising I can't trust the methods to be reliable enough. Plus, with this method, we can also split the scan in parts specified by us, not by the game. In Morrowind scripts were a problem, because they ran every frame and often modders weren't responsible. Now we have the opposite: not many lags because of that, but delays. Hope you understand.

Dragoon Wraith TALK 19:03, 3 August 2006 (EDT): Well, spells can hit items, though this is limited because they will only run for one frame. That's long enough to get reference variables to them, though.

Of course, the spell only hits items actually placed in the game world - but we can get items in inventories.

I haven't seen any slowdown due to spells, but then my computer has a good processor and a lot of RAM, it's the video card that's bad. If this is more efficient, then that is a good thing. MWSE's version of this wasn't very efficient as I remember it, though.

Well, I noted that above. cdcooley said opposing to MWE's, this function was "not optimized". I assumed that the mandatory ref as a parameter was one reason. That's why I made it optional; only use it if you need it. Grey 12:19, 4 August 2006 (EDT)

Iterating through local references would be very nice. AoE spells will get you references to actors and nothing else - activators, furniture, containers, and doors will only run spell scripts if directly hit by them, and carriable items, statics, flora, etc can't run spell scripts at all.

I have no idea how OB stores information about references in the current cell, but my ideal (within the realm of possibility) implementation would be similar to the new inventory functions: one function returns the number of references of the specified type in the current cell, and another returns a reference to one of those. i.e.:

set numDoors to getNumLocalReferences 10 ; assuming 10 is the code for doors
set door1 to getLocalReference 10 1 ; return the first door found
set door5 to getLocalReference 10 5 ; return the 5th

Basically similar to MWSE's implementation, except allowing you to jump to any reference in the list without iterating. Scruggs 20:53, 3 August 2006 (EDT)

The problem I saw with this is that I personally don't know how much "lists" exist. It might just be too much work to sort all items by type. Then again ... if this sorting get's done in idle time (i.e. all the time, so that each time only a small portion needs to be re-sorted), this could have a significant good impact on performance. It could also mean though that general performance decreases when running obse. But now that I think of it again ... it is certainly better if the executable did this sorting in native code rather than us doing it in pseudo-code. Grey 12:19, 4 August 2006 (EDT)