[RELz] Oblivion Script Extender (OBSE) 0019b : IV - Oblivion

» Wed Sep 01, 2010 11:18 am

So adaptation is the way to go. Oh man, I really don't want to do that. But at least it gives me something I can work on myself, as opposed to hoping that someone out there could do it for me. Without that suggestion, I really would have been dependent on Scruggs or MentalElf or Timeslip...

The game has a class named 'Archive' that looks like it handles BSA functionality. It should be relatively straightforward to decode - depending on what you need to do with it.

» Wed Sep 01, 2010 7:10 pm

I need to extract a file from the archive (i.e. get a stream of it). I've tried IDA before, but I really can't make heads or tails of it...

» Wed Sep 01, 2010 10:11 pm

I need to extract a file from the archive (i.e. get a stream of it). I've tried IDA before, but I really can't make heads or tails of it...

The decoding I've done in that area is mostly higher level stuff that makes use of the stream classes to e.g. load a model for a particular reference. That stuff generally happens in a background thread, and it'd probably be best if your/our code did the same.
I can take a look into the lower level code once finals are over, can't promise anything of course.
What do you need to do with the file once extracted?

Does it have to be a hook on form load, per se? Perhaps a one-time cycle through forms in the data handler, some time during the first pre-loadgame event? Since mod-added base forms are loaded only once, it should amount to the same thing. Created base forms stored in savegames would still need to be processed after every savegame load, but there are far fewer of those.

I'd love to have this myself, because it allows a script to do things traditionally reserved to WryeBash (e.g. reweigh potions, rename spells, rebalance armor, etc.). But I don't know how long it actually takes to run a function script a few thousand times; perhaps this just isn't a task the scripting engine can handle.

I did some optimizing for 0019b to reduce the overhead associated with repeated invocations of function scripts. But I don't really see a reason to do a function call per object when the same thing could be accomplished by iterating over the game's form lists. That kind of functionality was requested and discussed at some length waaaay back around v0013 or v0014. From what I recall, Ian had some concerns about performance issues (these are reeaally long lists), which could potentially be mitigated. The broader concern - I think haama was particular vocal about this, and I tend to agree - is that some mods don't want other mods messing with their objects, and in some cases would break if it were allowed.

» Wed Sep 01, 2010 5:45 pm

Niflib expects a file name or file stream (the file version of the function just calls open on it and feeds that into the stream version) from which it reads the NIF data. I imagine that Oblivion does processing on its own that is similar to what Niflib itself does when it loads a file - and I doubt the two are particularly similar...

Anyway, I certainly can be patient, heh! MentalElf actually got back to me, so I might have a working version of my own soon...

» Wed Sep 01, 2010 11:36 am

I did some optimizing for 0019b to reduce the overhead associated with repeated invocations of function scripts. But I don't really see a reason to do a function call per object when the same thing could be accomplished by iterating over the game's form lists. That kind of functionality was requested and discussed at some length waaaay back around v0013 or v0014. From what I recall, Ian had some concerns about performance issues (these are reeaally long lists), which could potentially be mitigated. The broader concern - I think haama was particular vocal about this, and I tend to agree - is that some mods don't want other mods messing with their objects, and in some cases would break if it were allowed.

A function callback for each form is clearly raising some red flags, so I'll trust your judgment.

You did mention iterating over game lists. Would it be possible to add something like GetFirst(Next)BaseForm and GetFirst(Next)CreatedObject, a la GetFirst(Next)Ref? I suppose this might be exactly what was discussed in v0013/14, but I don't see how it offers more access to the data handler than other, more roundabout methods (e.g. a game-mode script that examines the inventories of all loaded actors).

haama, if you reading this, don't sic the hounds on me

» Wed Sep 01, 2010 5:46 pm

Easy answer is that it would provide access to base forms that are never instantiated. Some mods (especially those written before OBSE arrays and string vars) create items to store information on and never actually place these items in the game world. Think of them as a ghetto struct. The scripts rely on the base forms being essentially unchangeable by other mods.

Wrye Bash tries to work around this issue by avoiding forms if they match a variety of criteria (one red flag being if it has "Token" in its name or editorID).

» Thu Sep 02, 2010 1:20 am

I'm experiencing a crash with OBSE 19b.

OBSE.log:

Spoiler

OBSE: initialize (version = 19.6 010201A0)oblivion root = E:\Program Files (x86)\Bethesda Softworks\Oblivion\plugin directory = E:\Program Files (x86)\Bethesda Softworks\Oblivion\Data\OBSE\Plugins\checking plugin E:\Program Files (x86)\Bethesda Softworks\Oblivion\Data\OBSE\Plugins\\ConScribe.dllSetOpcodeBase 000025A0RegisterCommand Scribe (25A0)RegisterCommand RegisterLog (25A1)RegisterCommand UnregisterLog (25A2)RegisterCommand GetRegisteredLogName (25A3)plugin E:\Program Files (x86)\Bethesda Softworks\Oblivion\Data\OBSE\Plugins\\ConScribe.dll (00000001 ConScribe 00000006) loaded correctlychecking plugin E:\Program Files (x86)\Bethesda Softworks\Oblivion\Data\OBSE\Plugins\\OBSE_Elys_Pluggy.dllSetOpcodeBase 00002330RegisterCommand GetEsp (2330)RegisterCommand CreateArray (2331)RegisterCommand DestroyArray (2332)RegisterCommand ArraySize (2333)RegisterCommand ArrayCount (2334)RegisterCommand SetInArray (2335)RegisterCommand SetFloatInArray (2336)RegisterCommand GetInArray (2337)RegisterCommand GetTypeInArray (2338)RegisterCommand RemInArray (2339)RegisterCommand FindInArray (233A)RegisterCommand FindFloatInArray (233B)RegisterCommand SetRefInArray (233C)RegisterCommand FindRefInArray (233D)RegisterCommand CopyArray (233E)RegisterCommand ArrayEsp (233F)RegisterCommand ArrayProtect (2340)RegisterCommand FirstInArray (2341)RegisterCommand DestroyAllArrays (2342)RegisterCommand PackArray (2343)RegisterCommand CreateString (2344)RegisterCommand DestroyString (2345)RegisterCommand SetString (2346)RegisterCommand StringEsp (2347)RegisterCommand StringProtect (2348)RegisterCommand StringLen (2349)RegisterCommand DestroyAllStrings (234A)RegisterCommand StringSetName (234B)RegisterCommand StringGetName (234C)RegisterCommand StringMsg (234D)RegisterCommand StringCat (234E)RegisterCommand UserFileExists (234F)SetOpcodeBase 00002378RegisterCommand RenFile (2378)RegisterCommand DelFile (2379)RegisterCommand StringToTxtFile (237A)RegisterCommand CopyString (237B)RegisterCommand IntToString (237C)RegisterCommand FloatToString (237D)RegisterCommand RefToString (237E)RegisterCommand IniReadInt (237F)RegisterCommand IniReadFloat (2380)RegisterCommand IniReadRef (2381)RegisterCommand IniWriteInt (2382)RegisterCommand IniWriteFloat (2383)RegisterCommand IniWriteRef (2384)RegisterCommand IniKeyExists (2385)RegisterCommand IniDelKey (2386)RegisterCommand EspToString (2387)RegisterCommand IniReadString (2388)RegisterCommand IniWriteString (2389)RegisterCommand ModRefEsp (238A)RegisterCommand GetRefEsp (238B)RegisterCommand StringToRef (238C)RegisterCommand StringCmp (238D)RegisterCommand FileToString (238E)RegisterCommand StringPos (238F)RegisterCommand StringToInt (2390)RegisterCommand StringToFloat (2391)RegisterCommand ArrayCmp (2392)RegisterCommand StringMsgBox (2393)RegisterCommand StringIns (2394)RegisterCommand StringRep (2395)RegisterCommand IntToHex (2396)RegisterCommand LC (2397)SetOpcodeBase 000023B0RegisterCommand FromTSFC (23B0)RegisterCommand ToTSFC (23B1)RegisterCommand StrLC (23B2)RegisterCommand CreateEspBook (23B3)RegisterCommand FmtString (23B4)RegisterCommand FixName (23B5)RegisterCommand ResetName (23B6)RegisterCommand HasFixedName (23B7)RegisterCommand csc (23B8)RegisterCommand StringSetNameEx (23B9)RegisterCommand StringGetNameEx (23BA)RegisterCommand FixNameEx (23BB)RegisterCommand IniGetNthSection (23BC)RegisterCommand IniSectionsCount (23BD)RegisterCommand RunBatString (23BE)RegisterCommand Halt (23BF)RegisterCommand RefToLong (23C0)RegisterCommand LongToRef (23C1)RegisterCommand FindFirstFile (23C2)RegisterCommand FindNextFile (23C3)RegisterCommand GetFileSize (23C4)RegisterCommand NewHudS (23C5)RegisterCommand DelHudS (23C6)RegisterCommand ScreenInfo (23C7)RegisterCommand HudS_X (23C8)RegisterCommand HudS_SclX (23C9)RegisterCommand HudS_Show (23CA)RegisterCommand HudS_Opac (23CB)RegisterCommand HudS_Align (23CC)RegisterCommand AutoSclHudS (23CD)RegisterCommand HudS_Y (23CE)RegisterCommand HudSEsp (23CF)RegisterCommand HudSProtect (23D0)RegisterCommand HudsInfo (23D1)RegisterCommand DelAllHudSs (23D2)RegisterCommand HudS_L (23D3)RegisterCommand rcsc (23D4)RegisterCommand HudS_SclY (23D5)RegisterCommand NewHudT (23D6)RegisterCommand DelHudT (23D7)RegisterCommand HudT_X (23D8)RegisterCommand HudT_SclX (23D9)RegisterCommand HudT_Show (23DA)RegisterCommand HudT_Opac (23DB)RegisterCommand HudT_Align (23DC)RegisterCommand AutoSclHudT (23DD)RegisterCommand HudT_Y (23DE)RegisterCommand HudTEsp (23DF)RegisterCommand HudTProtect (23E0)RegisterCommand HudTInfo (23E1)RegisterCommand DelAllHudTs (23E2)RegisterCommand HudT_L (23E3)RegisterCommand HudT_SclY (23E4)RegisterCommand PauseBox (23E5)RegisterCommand KillMenu (23E6)RegisterCommand SetHudT (23E7)RegisterCommand HudT_Text (23E8)RegisterCommand HudS_Tex (23E9)RegisterCommand SanString (23EA)RegisterCommand IsHUDEnabled (23EB)RegisterCommand IsPluggyDataReset (23EC)RegisterCommand FromOBSEString (23ED)RegisterCommand ToOBSEString (23EE)RegisterCommand HudT_Font (23EF)SetOpcodeBase 000023FFRegisterCommand PlgySpcl (23FF)plugin E:\Program Files (x86)\Bethesda Softworks\Oblivion\Data\OBSE\Plugins\\OBSE_Elys_Pluggy.dll (00000001 OBSE_Elys_Pluggy 00000084) loaded correctlypatchedloading from C:\Users\Fox\Documents\My Games\Oblivion\Saves\Save 9 - Testguy - Waterfront, Level 1, Playing Time 00.09.00.obseReading mod list from co-saveLoading stringsLoading array variablesplugin has data in save file but no handlerDoLoadGameHook: C:\Users\Fox\Documents\My Games\Oblivion\Saves\Save 9 - Testguy - Waterfront, Level 1, Playing Time 00.09.00.essloading from C:\Users\Fox\Documents\My Games\Oblivion\Saves\Save 9 - Testguy - Waterfront, Level 1, Playing Time 00.09.00.obseOBSE: deinitialize

Windows Error:

Spoiler

Problem signature:  Problem Event Name:	APPCRASH  Application Name:	Oblivion.exe  Application Version:	1.2.0.416  Application Timestamp:	462392c7  Fault Module Name:	obse_1_2_416.dll  Fault Module Version:	0.0.19.6  Fault Module Timestamp:	4ce69d45  Exception Code:	c0000005  Exception Offset:	0004fc45  OS Version:	6.1.7600.2.0.0.256.1  Locale ID:	1033  Additional Information 1:	27c8  Additional Information 2:	27c8ce5af7a07bedf550bd9c573901b3  Additional Information 3:	e56e  Additional Information 4:	e56e9cfaf3cd1084b6b4c016d12ce64c

OBSE Function Script code:

Spoiler

ScriptName renscanollnaturalref arg1array_var arg2short arg3ref objectrefref doorparentcellref teleportdoorrefstring_var nifpathstring_var objectnameshort arraysizefloat returnvalueBegin Function{arg1, arg2, arg3}	; arg1 = current cell	; arg2 = previous cell(s)	; arg3 = scan next cell		if (arg2 == 0)		let arg2 := ar_Construct Array	endif	if eval (ar_Find arg1 arg2) == -99999.0		let arraysize := ar_Size arg2		set arraysize to (arraysize+1)		ar_Resize arg2	arraysize		ar_Insert arg2 arraysize arg1	endif	Print "Entered renscanollnatural function..."	Print "Values: " + $arg1 + ", " + $arg2 + ", " + $arg3	set returnvalue to 0	SetFunctionValue returnvalue	set objectref to Apple	set objectref to GetFirstRefInCell arg1	Label 1	if (objectref != 0)		if (objectref.IsInInterior == 0)			; bad.			set returnvalue to 0			SetFunctionValue returnvalue						set objectref to 0			GoTo 1		endif		let objectname := objectref.GetName		if (sv_Find "thisinteriorhaswindows" objectname > -1)			; override			set returnvalue to 1			SetFunctionValue returnvalue			set objectref to 0			Print "Found override item..."			GoTo 1					endif		if (objectref.GetObjectType == 28)			; static			let nifpath := objectref.GetModelPath			if (sv_Find "allnatural\" nifpath > -1 || sv_Find "niw\" nifpath > -1)				; all natural NIF!				set returnvalue to 1				SetFunctionValue returnvalue				set objectref to 0				Print "Found All Natural mesh..."				GoTo 1			endif		endif		set objectref to Apple		set objectref to GetNextRef		GoTo 1	endif	set objectref to Apple	set objectref to GetFirstRefInCell arg1			Label 2	if (objectref != 0)		if (objectref.GetObjectType == 24 && arg3 == 1)			; door			if (objectref.IsLoadDoor == 1)				Print "Found a load door..."				set teleportdoorref to objectref.GetLinkedDoor				if (teleportdoorref != 0)					set doorparentcell to teleportdoorref.GetParentCell					if eval (teleportdoorref.IsInInterior == 1 && (ar_Find doorparentcell arg2) == -99999.0)						Print "Scanning next cell: " + $doorparentcell										let arraysize := ar_Size arg2						set arraysize to (arraysize+1)						ar_Resize arg2	arraysize						ar_Insert arg2 arraysize doorparentcell						let returnvalue := Call renscanollnatural doorparentcell arg2 arg3						SetFunctionValue returnvalue					endif				endif			endif		endif		set objectref to Apple		set objectref to GetNextRef		GoTo 2	endif	sv_Destruct nifpath	sv_Destruct objectname	let arg2 := ar_Null	Print "Renscanollnatural returning value: " + $returnvalueEnd

ConScribe:

Spoiler

Game Instance : 1 | Time : 12-09-2010 10-49-03 PM==================================================All Natural Tamriel: InitialisedRenIntStaticsNodeQuestScript: Player pressed activate key.RenIntStaticsNodeQuestScript: Starting - player is not in interior...Entered renscanollnatural function...Values: Vilverin, Array ID 134, 1Found a load door...Found a load door...Scanning next cell: Vilverin CanoselEntered renscanollnatural function...Values: Vilverin Canosel, Array ID 134, 1Found a load door...Found a load door...Scanning next cell: Vilverin WendeselEntered renscanollnatural function...Values: Vilverin Wendesel, Array ID 134, 1Found a load door...Found a load door...Scanning next cell: Vilverin Sel SancremathiEntered renscanollnatural function...Values: Vilverin Sel Sancremathi, Array ID 134, 1Found a load door...Found a load door...Renscanollnatural returning value: 0

As can be seen, the crash occurs immediately after the line "Renscanollnatural returning value: 0" - nothing runs after that, Oblivion just crashes with the error code.

» Wed Sep 01, 2010 3:03 pm

I'm experiencing a crash with OBSE 19b.

It's due to you having multiple loops using GetFirst/NextRef simultaneously. The ref-walking cmds are designed for efficiency; the price for that is that they retain state in between calls, which means that calling GetFirstRef resets the internal data structures from which GetNextRef pulls its return values.
This actually came up in the previous thread as a hypothetical question; my response was that if somebody actually needed to write code with multiple simultaneous uses of GetFirst/NextRef the commands could be updated to support that.
Skimming through your code, it seems to me that instead of immediately scanning the cells associated with load doors you find inside your loop, you could store the load doors in an array and then process each of their cells in turn after your main loop has finished. This would prevent the problem you're having.
If that's not an option I can look at updating the cmds for 0020.

Easy answer is that it would provide access to base forms that are never instantiated. Some mods (especially those written before OBSE arrays and string vars) create items to store information on and never actually place these items in the game world. Think of them as a ghetto struct. The scripts rely on the base forms being essentially unchangeable by other mods.

Yeah, that is one example.
I realize that there are ways to get at other mod's objects indirectly e.g. through inventory-walking cmds. Those aren't immune to conflict either, and we're never going to eliminate all potential for conflict between mods. But providing commands to directly access stuff belonging to other mods just seems like it would encourage conflicts.
Of course the data handler's form lists are already exposed to obse plugins so there's no reason commands to access them can't be provided without including them in OBSE proper...

» Thu Sep 02, 2010 1:56 am

Bug report:

GetClimateMoonPhaseLength has a climate parameter in the docs, and that makes sense, since phases are specified by climates. However, the function will only accept the editorID of a weather, and trying to save a script calling it with a climate parameter results in an error:

Invalid weather 'DefaultClimate' for parameter weather. Compiled script not saved!

It's not a pressing issue, since I don't think anyone's modified the phase lengths in any mod I've ever heard of, so I can just use the default values for now. Still, it should be fixed.

» Wed Sep 01, 2010 10:05 pm

Bug report:

GetClimateMoonPhaseLength has a climate parameter in the docs, and that makes sense, since phases are specified by climates. However, the function will only accept the editorID of a weather, and trying to save a script calling it with a climate parameter results in an error:

Invalid weather 'DefaultClimate' for parameter weather. Compiled script not saved!

It's not a pressing issue, since I don't think anyone's modified the phase lengths in any mod I've ever heard of, so I can just use the default values for now. Still, it should be fixed.

The game doesn't have a "climate" parameter type. Try sticking your climate in a ref variable and passing the variable as the param instead. You should find that while passing a weather will compile, it won't do anything at run-time because the cmd expects a climate.

» Thu Sep 02, 2010 1:53 am

The game doesn't have a "climate" parameter type. Try sticking your climate in a ref variable and passing the variable as the param instead. You should find that while passing a weather will compile, it won't do anything at run-time because the cmd expects a climate.

OK, passing a ref variable worked in the editor. Yet to test it out in game, but I imagine it will work.

» Wed Sep 01, 2010 6:04 pm

So I decided to try the 4GB deal with Oblivion, and am not seeing a whole lot of difference--right around 45% RAM use, the game is bound to crash. Figuring Win7x64 eats about a gig of that, and I have 6G, it seems that it's still limited to 2G for the game. A bit confused, I started poking around in the logs and so on, and found this in obse_loader.log:

clearing large-address-aware flag (flags offset = 0000011E checksum offset = 00000160)
crc = 7934C86C
dll = G:\Games\Oblivion\obse_1_2_416.dll
hookBase = 001D0000
loadLibraryAAddr = 74F74BC6
hook thread complete
launching oblivion

Is OBSE turning off the 4GB flag? I did not apply the flag change to the launcher, as from what I understand, once it launches the game it's done. If this is the case, why? Can this be changed?

» Wed Sep 01, 2010 9:01 pm

Is OBSE turning off the 4GB flag? I did not apply the flag change to the launcher, as from what I understand, once it launches the game it's done. If this is the case, why? Can this be changed?

OBSE clears the flag temporarily so that it can compute the CRC to identify the executable version. It doesn't interfere with the effects of using a 4GB enabler; the opposite, really, as otherwise OBSE would fail to recognize 4GB-enabled executables.
Whether or not the LAA flag has any real benefit has been a topic of debate in some other threads.

» Wed Sep 01, 2010 3:28 pm

OBSE clears the flag temporarily so that it can compute the CRC to identify the executable version. It doesn't interfere with the effects of using a 4GB enabler; the opposite, really, as otherwise OBSE would fail to recognize 4GB-enabled executables.
Whether or not the LAA flag has any real benefit has been a topic of debate in some other threads.

Ahh, ok. Yeah it doesn't seem to make any difference, once the game eats 2G, kaput.

» Wed Sep 01, 2010 11:50 pm

The game doesn't have a "climate" parameter type. Try sticking your climate in a ref variable and passing the variable as the param instead. You should find that while passing a weather will compile, it won't do anything at run-time because the cmd expects a climate.

Would it be possible to add new parameter types with just modifications to the default command parser ? Or is there more to it ?

» Wed Sep 01, 2010 10:09 am

Would it be possible to add new parameter types with just modifications to the default command parser ? Or is there more to it ?

There's more to it. Among other things param types are used to index into fixed-size tables in several places.

» Wed Sep 01, 2010 1:29 pm

just want to say thanks to the OBSE team.

with their Inventory References functions,

there's no need to to trigger RemoveAllItems in Inventory is a backpack is now 100x better
there's no need to move items of dead guards into an owned container then back again in Looting dead guards is stealing

cheers! :foodndrink:

» Wed Sep 01, 2010 2:35 pm

Whether or not the LAA flag has any real benefit has been a topic of debate in some other threads.

Ahh, ok. Yeah it doesn't seem to make any difference, once the game eats 2G, kaput.

Not sure why there's any debate because it's working fine for most of us who use it. There's a few odd one-off cases where it doesn't seem to work for whatever reason, but when I can see in task manager that the game is using more than 2GB of memory, that ends any debate as to whether it's working or not.

It might be one of those things where running with OSR in a certain configuration enables it to work properly though. I wasn't able to get the expected results until reconfiguring OSR's heap mode and memory size.

» Wed Sep 01, 2010 7:10 pm

I'm asking because I couldn't get around reading the whole topic and I don't see this mentioned in the documentation. Is there a way to get a reference of an actor that hits target object? I know there's a way to get a reference of the actor that shot the object (either with arrow or spell), I'm asking about a melee version of it

» Thu Sep 02, 2010 12:37 am

Easy answer is that it would provide access to base forms that are never instantiated. Some mods (especially those written before OBSE arrays and string vars) create items to store information on and never actually place these items in the game world. Think of them as a ghetto struct. The scripts rely on the base forms being essentially unchangeable by other mods.

Wrye Bash tries to work around this issue by avoiding forms if they match a variety of criteria (one red flag being if it has "Token" in its name or editorID).

I realize that there are ways to get at other mod's objects indirectly e.g. through inventory-walking cmds. Those aren't immune to conflict either, and we're never going to eliminate all potential for conflict between mods. But providing commands to directly access stuff belonging to other mods just seems like it would encourage conflicts.
Of course the data handler's form lists are already exposed to obse plugins so there's no reason commands to access them can't be provided without including them in OBSE proper...

I have the feeling that I should let this lie - and I will. But humor me a closing argument

The problem with a GetForm command, I understand, is that otherwise 'hidden' objects would become visible to scripts. Since this violates an assumption made by many mod authors, it might lead to a new wave of subtle and hard to reproduce incompatibilities. I don't contest this, but I don't understand why it elicits such a strong reaction. Just because the functions could cause problems doesn't mean that they will.

Allow me to offer an example from my own experience - the commands to Add/Remove Effect Items. They allow low level access to magic items, and many mods would not be possible without them. But if used unwisely - changing a spell that is currently active on a target somewhere - they cause memory access violations, and often a CTD. This isn't seen in practice only because script authors are generally aware of the problem and work around it. I'm not arguing that script authors always know best - I was one

. But I think that careful design and good practices go a long way to overcoming such pitfalls.

For instance, there can be no harm in a script that looks through the data handler but doesn't change anything - so you could use these functions to gather statistics, or balance your own mods items against what's already in the game. And as Waruddar pointed out, an object's current properties are sometimes enough to indicate whether it is safe to change - so if you were retexturing potions, for example, you might check if they use the vanilla potion texture first. The potential for conflict is still there, but it can be avoided with care.

Simply put, I think that there are enough situations where a script could make intelligent use of the data handler to justify the additional complications. I know I personally would be very grateful for it, and I think others could as well. Having said that, I'll step off the soapbox and move on.

» Wed Sep 01, 2010 8:01 pm

At this point, I think the best option would be an OBSE plugin that provides the functions. If they prove popular and mostly safe they can always be integrated into OBSE proper at a later point.

» Wed Sep 01, 2010 7:26 pm

Will the next OBSE release be 19c or 20 beta? Do you already have an ETA for it? I am really looking forward to 20!

» Wed Sep 01, 2010 11:54 am

I'm asking because I couldn't get around reading the whole topic and I don't see this mentioned in the documentation. Is there a way to get a reference of an actor that hits target object? I know there's a way to get a reference of the actor that shot the object (either with arrow or spell), I'm asking about a melee version of it

I'm going to assume by 'object' you mean 'non-actor' (otherwise you'd just use OnHit, right?)
I'm not sure there's a foolproof way to do it at present, though I haven't kept up with developments among the talented pool of scripters here. There are some rough ways to do it if you want to know when the player hits an object, but they don't apply more generally.
Might be best to make a thread over in the CS forum about it.

Will the next OBSE release be 19c or 20 beta? Do you already have an ETA for it? I am really looking forward to 20!

It will be 0020 and I'm working on it as I type. No ETA other than "soonish", in part because shademe is apparently waiting on a new release so he can grace you all with his CSE plugin, and in part because I don't want to make it a bulky release.

» Wed Sep 01, 2010 11:30 am

It will be 0020 and I'm working on it as I type. No ETA other than "soonish", in part because shademe is apparently waiting on a new release so he can grace you all with his CSE plugin, and in part because I don't want to make it a bulky release.

And I think it's taken ShadeMe about as long to release the CSE as it took Beth to announce TES V

We're all anxiously awaiting v 20

» Wed Sep 01, 2010 11:57 pm

It will be 0020 and I'm working on it as I type. No ETA other than "soonish", in part because shademe is apparently waiting on a new release so he can grace you all with his CSE plugin, and in part because I don't want to make it a bulky release.

Oh, please take your time - I'm sure I can hang on to CSE for another month or so