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.
- How About a "WillRespawn()" function... Save me from duplicating a great many scriptsDejunai 10:25, 1 September 2006 (EDT)
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.
- 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)
- 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)
Regarding this particular wish...
Set/ModObjectValue [value] [number] - ability to manipulate the stats of objects, such as changing the damage done by a weapon. (finding and changing the current enchantment [i.e. recharge a weapon over time] was specifically requested) I think it's very good that this particular feature is listed as 'number one'. I'd really like to hear if it's possible to mod it... and it's not just about damage - damage is fine... the weapon speed is what really needs to be fixed! I mean dynamically adjusting your attack speed (like in Daggerfall) based on your strength, agility and skill with weapons would be simply GREAT - huge realism and gameplay boost. I swear to myself that once something like that will be possible, I'll be off making a mod that does exactly that. ... Btw, is it even theoretically possible? I'd very much to hear that before I'll get all hopeful. --Balor 14:29, 7 September 2006 (EDT)
- Dragoon Wraith TALK 15:20, 7 September 2006 (EDT): They're working on it. As noted, it's their top priority, and they're getting there. Unsure how close they actually are (they don't like talking about development because they don't want to disappoint, but since they develop so rapidly no one minds), but it will happen. Weapon speed, in fact all the values found here will be adjustable, most likely.
Semi-Fulfilled Wishes?
Several of the requests on the wish list haven't been given their own specific functions but can be partially or completely solved using existing OBSE functions. I haven't deleted them from the wishlist, but maybe they should be moved down in priority? Scruggs 20:57, 17 October 2006 (EDT)
- isBowDrawn - A boolean function to return if player has nocked an arrow. It should be usefull to give the possibility to "unnock", but even an unnock function all by itself should be very usefull. It'd be best to be able to know also if the arrow has been fully nocked or not. I'm thinking about greater powers to be used only once a day on a single thrown arrow, without having to create a new one to simulate this effect (so without giving any possibility to stock them every day).
- You can do this by checking for the length of time the attack button has been held down while a bow and arrow are equipped.
- DisablePlayerControls2 - Disables ALL controls including mouse movements for the player, but still make the TapKey, HammerKey etc. functions work as usual. --Mandrill 06:38, 14 August 2006 (EDT) - This could be done by using DisableKey on all the keys on the keyboard, as TapKey and IsKeyPressed should still work (needs testing) - An easier way to do this is to call disableplayercontrols, disable mouse, and disablekey on the console. - Dragoon Wraith TALK: IsKeyPressed does work, I haven't tried TapKey.
- OnJump - trigger the script when the object jumps
- Considering that only the player is actually capable of jumping, this can be done by detecting when the Jump key is pressed.
- GetStandingActor - returns ref variable for the last actor to step onto the object. Would be hugely useful for traps.
- This can be done with trigger zones placed either separately from the object or incorporated into the .nif.
- GetCellChanged request: I dont believe changing of cells actually goes on over what OB considers a single frame. Additionally what is meant by cell changes is different if you are in/crossing an interior or exterior cells. All this aside, this method is NOT necesary. A simple quest script that tracks the player position using an Xmarker can detect this easiliy with player.GetInSameCell MyXmarker and MyXmarker.MoveTo player, coupled with player.IsInInterior commands.
- Dragoon Wraith TALK: See the example at GetParentCell for a script that should emulate CellChanged from Morrowind... JOG also said that it was no good, but I didn't understand why. Perhaps you could explain it? Of course, you could do it without OBSE using an Activator and GetInSameCell/MoveTo (why do you need GetInInterior?), that also works (but is less convenient, methinks).
- I dont think GetParentCell gives you what you would expect [in this script]. IsInInterior is very important if you consider that you are changing cells all the time when outside and typically it isn't your intention to detect these types of cell changes.
- I think JOG's gripe with GetParentCell is that, in Morrowind, CellChanged returned true when the player entered the cell containing the scripted object. It was closer to something like an OnPlayerEntry function. While that was often more annoying than useful, I can see his point (if that is in fact his point ;)), although GetParentCell along with GetInSameCell are enough for a (somewhat clunky) workaround. :shrug: Scruggs 23:24, 25 October 2006 (EDT)
- I dont think GetParentCell gives you what you would expect [in this script]. IsInInterior is very important if you consider that you are changing cells all the time when outside and typically it isn't your intention to detect these types of cell changes.
- Dragoon Wraith TALK: See the example at GetParentCell for a script that should emulate CellChanged from Morrowind... JOG also said that it was no good, but I didn't understand why. Perhaps you could explain it? Of course, you could do it without OBSE using an Activator and GetInSameCell/MoveTo (why do you need GetInInterior?), that also works (but is less convenient, methinks).
- Actually you can scrub my comment on GetParentCell. Without the CS in front of me I confused this with something else and didn't realize it was an OBSE command. My method does work perfectly as a non-OBSE solution. In LTC I actually track last inside and outside locations so I can have Chaotic Intervention to teleport you to the front door of a dungeon.) GuidoBot 00:08, 26 October 2006 (EDT)
I'm not too pleased with they way this list was 'cleaned-up'. In particular that some of my suggestions were removed while lesser ones (usefulness-wise, IMHO) have been left in. I would point you to those I mean and can explain exactly why they would be very useful in a general way, but now they are gone! I do not accept that they were removed due to duplication or impracticality. GuidoBot 18:46, 29 November 2006 (EST) :(
- The article definitely needed housekeeping. The list was disorganized, several requests were repetitive or already implemented, and there was a lot of discussion cluttering up the list. I took care to preserve the requests while keeping things concise. I consolidated your request for an isFalling function into the more general GetCurrentAnim function because you suggested it should return a value based on whether the player is playing a Jump animation. If there are other omissions or whatnot, by all means resubmit them or discuss them here. You can always check the History page for previous versions of the article.
- Sorry to annoy. Scruggs 19:10, 29 November 2006 (EST)
- I dont mind the reorganisation and agree this was needed. However, I dont think such heavy prunning was necessary. GetCurrentAnim is may not be a reliable alternative to IsFalling. As an additional function this could take care of exceptional cases. My SetCamera (?) method incorporated 2 or 3 earlier suggestions and its complete funtionality is now gone. SetHostile is another function that I would consider essential to many MODs that do anything with illegal activities. On the other hand you could argue things like '%N' are not worthy, in this case because you can remotely access a scroll to give all the formatting you'll ever need for a message box. Additionally my request re blocking message spam was much more general than the request remaining. (I'm not going to argue these cases specifically as any extra functionality is still useful - both OBSE and OB commands have a lot of functional overlap - but my point is that, unless there is pure duplication, it is presumptuous to prune.) GuidoBot 19:27, 29 November 2006 (EST)
- 'kay. Remember, it's a wiki - anyone, including you, is free to edit the page. Presumptuous or not, I didn't randomly prune anything. From a practical perspective, eliminating message spam by having spam-less versions of functions like AddItem seems much more straightforward and doable than setting a flag that turns off messages from all functions, and it wouldn't step on the toes of existing functions. Likewise, by your own description, IsFalling would have checked for a jumping animation; if you want a function to check the state of the fall damage timer, then that's a separate request. %N would be trivial to implement as suggested by the OP. :shrug: As it says in the article intro, "Contributions may be editted for a large variety of reasons, from consistency to aesthetics. Please do not take this personally." I certainly won't take it personally if you or anyone else continues to edit the list. The point was to bring some order to it so that future requests would be placed in their respective categories. Scruggs 19:52, 29 November 2006 (EST)
- Fair enough. IsFalling was meant to be the actual function - checking the animation state was only a suggested clue for going about this because I do not know how intemately these functions are associated - especially if they could be deliberately dissociated through scripting. I thought SetCamera would be a great way to encapsulate the current requests while also open OB for easy to create cut-sceens, etc., that required more complicated camera work. But I would not remove other's similar suggestions on this reasoning. SetHostile is very different from the setHitBy (actor) (damage) function, since I did not presume there was one kind of hostile state and obviously adding damage directly is not the point here. Message spam is also far more of a general issue than for particular commands (AddItem being one of the few that you can easily avoid). I don't take this personal but I would not have put up these suggestions if I didn't think they would be useful (relative to what was there already). I do not expect anything from the OBSE team with regards to using these suggestions but I did not expect them to be judiciously removed/reinterpretted either. Anyway, enough said. I appreciate the page and your maintainance of it so no worries, mate. ;) GuidoBot 21:48, 29 November 2006 (EST)
- 'kay. Remember, it's a wiki - anyone, including you, is free to edit the page. Presumptuous or not, I didn't randomly prune anything. From a practical perspective, eliminating message spam by having spam-less versions of functions like AddItem seems much more straightforward and doable than setting a flag that turns off messages from all functions, and it wouldn't step on the toes of existing functions. Likewise, by your own description, IsFalling would have checked for a jumping animation; if you want a function to check the state of the fall damage timer, then that's a separate request. %N would be trivial to implement as suggested by the OP. :shrug: As it says in the article intro, "Contributions may be editted for a large variety of reasons, from consistency to aesthetics. Please do not take this personally." I certainly won't take it personally if you or anyone else continues to edit the list. The point was to bring some order to it so that future requests would be placed in their respective categories. Scruggs 19:52, 29 November 2006 (EST)