NVSE

[prideslayer]

Oh.. I would say that all three projects would benefit from being rolled into a single solution so they can share some code where appropriate. I have my hands way too full to attempt this, though.

[jaam]

OBSE, FOSE and NVSE are pretty much the same thing originally, but the problem is two fold:

 

-  The three engines are 80% identical, but the 20% are  sprinkled all over the code. Any atempt at doing a shared source project would be nothing than a giant #ifdef #elseif #elseif...#endif

  Totally unreadable and unmaintanable

 

- Oblivion and Fallout3 were compiled with most optimisation, while FalloutNV has the minimum so most of the "code hijacking" cannot be reused from FalloutNV to Fallout3.

 

And lastly what is known of the inside is a matter of opportunity. When someone wanted to write a function, he had to decode the classes involved. That's still ongoing with Obivion that has a lot of years of advance. When FalloutNV showed, there was'nt anybody left to work on FOSE, and honestly, I don't think anyone ever requested it

 

Now if anybody wants to pick it up, most required code offsets from Fallout3 are commented into NVSE

 

[prideslayer]

I didn't mean a single project for all of them, but a single VS solution. This way all the per-game specific stuff could remain as it is, but the 'guts' of things like the extended vars and what not could be a single shared file between all of them.

 

For example, it would be easy right now to take all the NX functionality and put it in NVSE. In fact, Ian asked me if he could have the source to do just that when I first started the project, but I think he's been too busy to follow up. Anyway, if that was done, but all the NX stuff was put in it's own files, then OBSE, FOSE, and NVSE could all share those files since most of the stuff NX uses (TESForm, etc) is the same -- interface wise -- between the different extenders.

 

The savegame hook stuff is the same. Once you've got the hooks (different for each game), they can call the same functions to load/create/delete the cosave files.

[jaam]

new NVSE 4.2 Beta 3 available on Beth forum: http://forums.bethsoft.com/topic/1482519-beta-new-vegas-script-extender-nvse-v4/

 

Mostly fixes issues with v4.2 Beta 2 and some new goodies.

[prideslayer]

Saw the git checkin, cool deal. Jax said the underscore trick to use the NVSE compiler fixed one of his issues, but he found another (I haven't verified). GetUserTime() is returning an empty array, or nothing. I looked at the code in NVSE and it looks simple enough, so not sure how it could be going wrong.

 

Array_var time

let time := GetUserTime

Ar_Dump time

That's his test code, ar_dump works ok on the result of other array functions. It's not working here, and time[minutes] and such don't have anything either he said.

[DoctaSax]

The issue's not with ar_dump, it's the 'let' line that fails to evaluate to a valid result, so the function's not returning properly, I'd say.

[jaam]

Looks like I forgot to tell GetUserTime it was returning an array. That will startup v4.2 Beta 4

 

Until then, you may try:

int anID

let anID := GetUserTime
arDump_ID anID

I think it should work(around)

[Guest luthienanarion]

On a scale of 1 to 10, how likely is it that we can get functions to Get/Set the "playable" flag on items? Slotmasks?

[jaam]

Get/SetActorBaseFlagsLow already exists . Playable is bit 0.

 

No guaranties Set will have any effect!

 

 

[jaam]

New version : v4.2 Beta 4 http://nvse.silverlock.org/download/nvse_4_2_beta4.7z

[jaam]

And again, new beta : NVSE 4.5 Beta 5 : http://forums.bethsoft.com/topic/1482519-beta-new-vegas-script-extender-nvse-v4/page-5?do=findComment&comment=23688992

[jaam]

New beta NVSE v4.5 Beta 6: http://forums.bethsoft.com/topic/1482519-beta-new-vegas-script-extender-nvse-v4/page-5?do=findComment&comment=23709445

4.5 beta 06
	
	Fixes:
		Definition of Hairs and Eyes in TESRace.

		InventoryRef functions should be fully functional now, including for the player inventory.

		Plugin manager: 
			RegisterCommand will properly record the plugin opcodeBase.
			RegisterTypeCommand will only provide an eval version when appropiate.
			GetParentPlugin reports the correct answer for opcode 0.

		GetModLocalData and GetAllModLocalData return types corrected.

	Changes:
		During reference variable evaluation, Player is replaced by PlayerRef when appropriate.

	Added:
		
		EquipItem2:
			equips and runs onEquip block
			[ActorRefID].EquipItemZ ObjectID:ref NoUnequipFlag:int{0, 1} HideEquipMessage:int{0, 1}

		EquipMe:
			equips the calling object on its owner
			ref.EquipMe

		UnequipMe:
			unequips the calling object on its owner
			ref.UnequipMe

		IsEquipped:
			returns 1 if the calling object is currently being worn
			ref.IsEquipped

		GetInvRefsForItem:
			returns an array of temp refs to objects of the specified type in the calling container
			(refs:Array) GetInvRefsForItem baseObject:ref
		
		All 5 ported from OBSE.

		SetHotkeyItem:
			sets the item associated with a hotkey
				(nothing) SetHotkeyItem whichHotkey:short item:ref

		ClearHotkey:
			clears the item associated with the specified hotkey.
				(nothing) ClearHotkeyItem whichHotkey:short
			
		Both ported from OBSE by Luthien Anarion.
	
		PrintDebug or PrintD:
			Version of Print that only display something if the script is in debug mode.

		SetVariable:
			Sets a numeric variable on a ref or a quest:
				ref.SetVariable variableName variableValue
				SetVariable variableName variableValue Quest

		SetRefVariable:
			Sets a form variable on a ref or a quest:
				ref.SetRefVariable variableName anyForm
				SetRefVariable variableName anyForm Quest

		Get/SetStringIniSettings:
			string_var GetStringIniSetting "settingGroup:settingName"
				the : seems to be expected by the engine.
				example: let s := GetStringIniSetting "sDPad:LANGUAGE"

			SetStringIniSetting "settingGroup|settingName"
				the | is coherent with the SetNumIniSettingsEx

	Imported from Console:
		con_ShowVars	(requires SetConsoleEcho 1 to be visible)

[Odessa]

 

On Mod Local Data

 

Implying (to my limited understanding of NVSE) that:

- GetAllModLocalData is broken

- ModLocalDataExists and RemoveModLocalData work correctly

- SetModLocalData and GetModLocalData sort of work, except the reference I stored appears to have been converted to a number

 

Try again with the new beta 6.

 

By the way thanks for testing and documenting it all.

 

 

Thanks for adding it.

 

I'll post here, since it probably doesn't belong in the scripting 101 thread, I repeated my script with a minor addition using the new version:

array_var aData
ref rItem
....
    Print "Mod Local Data"
    SetModLocalData "sunny", SunnyREF
    Print "Mod data exists: " + $(ModLocalDataExists "sunny") + " " + $(ModLocalDataExists "garbageasfefsda")
    Print "Local data sunny: " + $(GetModLocalData "sunny")
    let rItem := GetModLocalData "sunny"
    Print "Local data sunny, via ref var: " + $rItem
    let aData := GetAllModLocalData
    Ar_Dump aData
    RemoveModLocalData "sunny"
    Print "Mod data exists: " + $(ModLocalDataExists "sunny") + " " + $(ModLocalDataExists "garbageasfefsda")
    Print " * End mod local data"

and this time I get:

 

Mod Local Data

Mod data exists: 1 0

Local data sunny: 5.27997e-318

Local data sunny, via ref var: Sunny Smiles

** Dumping Array #317 **

Refs: 1 Owner 1C: SexoutSoliciting.esm

[ SUNNY ] : Sunny Smiles (00104E85)

Mod data exists: 0 0

 * End mod local data

 

- GetAllModLocalData appears to work now

- If I directly print the return of ModLocalDataExists, I still get a number rather than the reference name, but if I store it in a ref var first, or dump the all data array_var, it looks correct.

[Guest tomm434]

Nice update! more FUNctions, more FUN!!

 

So, jaam.
 

 

SetHotkeyItem:
            sets the item associated with a hotkey
                (nothing) SetHotkeyItem whichHotkey:short item:ref

 

 

How exactly does it work?

 

 

 

 

        SetVariable:
            Sets a numeric variable on a ref or a quest:
                ref.SetVariable variableName variableValue
                SetVariable variableName variableValue Quest

        SetRefVariable:
            Sets a form variable on a ref or a quest:
                ref.SetRefVariable variableName anyForm
                SetRefVariable variableName anyForm Quest

 

Same question

 

 

 

During reference variable evaluation, Player is replaced by PlayerRef when appropriate.

 

So no difference at all now? Going to fix my tut.

 

Thanks!

 

[jaam]

- If I directly print the return of ModLocalDataExists, I still get a number rather than the reference name, but if I store it in a ref var first, or dump the all data array_var, it looks correct.

 

 

Yes NVSE checks what type of variable you are assigning to, and adapt the result in consequence.

[jaam]

object version: 
		let rContainer := VeronicaRef
		rContainer.SetVariable Waiting 1


quest version:
		SetRefVariable myRef Veronica TestScriptQuest

for SetHotkeyItem:

  set myPrefferedGun to AGunForm

  SetHotkeyItem 3 MyPrefferedGun

 

 

 

 

[jaam]

For player/playerRef.

 

if you type

 

   let x := player.SomeVar

then nvse will interpret it as

  let x := playerRef.SomeVar

 

because player as a form cannot be used in dot notation.

 

but

  let myRef := player

will still point to the player form.

 

when it is ambiguous, it defaults to player.

[Guest tomm434]

So I guess hotkey means what it means - # from 1 to 9 on the keypad, right?  Thanks for clarification about player\playerRef - I didn't even think about that difference before, need to be more careful with that.

 

 

 

But what about new numercic variable function. In what situation is it useful? I googled "obse numeric variable" but it didn't help much.

[nyaalich]

I would think that hotkey would still mean 1-9 on the regular keyboard.  jaam?

[jaam]

Vanilla hotkey values from 1 to 8. Key 2 is still reserved and skipped over logically.

 

SetVariable is useful, because the GECK will not let you change a variable through a ref variable, only toward an explicit reference:

 

so you could do:

  let VeronicaRef.Waiting := 1

but not

  let myRef := VeronicaRef

  myRef.Waiting := 1

 

Now imagine you want to scan for all active followers close to the PC and have them wait whether they are vanilla or custom. As long as the modder correctly name the variable a simple loop and you are done.

 

[Guest tomm434]

so it creates a custom variable like Lutana's pluing? (the one which has duck in the shop as poster image)

[jaam]

No. It modifies existing variable in the reference script.

 

[Guest tomm434]

So for example if I have Willow this bitch as companion, build ref and do a code

  let myRef := BuildRef 43243242
  myRef.Waiting := 1

Then if there a "waiting" variable, it will be changed to 1. And if not, game will CTD. Am I thinking in the right direction?

[jaam]

if not, nothing will happen. the code look up the variable at runtime; If it doesn't exists, nothing happen.

 

[Guest tomm434]

That's perfect. We don't need Lutana pluign anymore.(at least I don't see the point now). It's really good! No we can control any custom companion just by looking into his object script! because i think it's a rare case when modder change vital variables when mod is done