llde / xobse Goto Github PK

Are resetted every game load (newgames/savegame load/ game restart)

requested by forli

1. Getsummons return an array with the summons

2)ref.issummon return true if the ref is a summon

3)ref.Getsummoner return the ref of the summoner

From QQuix post:

Investigating a report from forli, I’ve found something weird with sv_replace related to replacing %’s:

let s := ">> 0%%<<"
sv_Replace " 0%%%%|OO" s
print s ; OK – prints “>>OO<<”
printc $s ; OK – prints “>>OO<<”

but
let s := ">> 0%%<<"
sv_Replace " 0%%|OO" s
print s ; prints “>>OO<<”
printc $s ; ERROR “Too few args for format specifier”

Since it complained about too few args, I tried adding a dummy arg and it did not throw the error
printc $s 99 ; prints “>>OO<<”

But the result shouldn’t be “>>OO%<<”? ( as the last pair of % should be joined in a single % and not replaced)

The same problem occurs with sv_construct and MessageBoxEX.

My feeling is that, in the second example, sv_replace leaves an unprintable something in the string which Print does not care about, but commands that uses format strings do not like.

Currently need some game's functions that are not currenty exposed in obse.

SetPosition

SetRotation

Considering this can be found out using currently-existing functions I guess it should be of really low priority, but it would be convenient. Specially because we can't make UDFs with optional parameters.

<bool> <reference>.IsInventoryObject <objectID:ref>

According to documentation:

GetFirstRef - returns the first reference in the current cell. (Snip) This function should be used only within a Label...Goto loop and GetNextRef.

I haven't had any trouble after testing this within While loops in repeated occasions. Is there any reason for this to be meant to be used exclusively within a Label-Goto loop, or is that part of the documentation simply outdated?

If ever possbile

or equivalent

necessary flag is already exposed. Need only to create and register the functon

Possible Solution: save them in the obse cosave?

Conversations, Topics and Response texts can only use dynamic strings when using GameSettings (and many mods like Enhanced Economy alter the GameSettings for this reason, but this may dangerous).
I wonder if OBSE could hook/patch the game code and make these texts support String_Var too.

This source is passed beetween many hands, everyone with his style of programming.

We have inconsistences beetween how things are done: most of the time functions use pointers, sometime (as in HasSpell) use references, or difference about getting Actors* from TESObjectREFR*
sometimes directly casted ((Actor_)thisObj for example) other times a TESObjectREFR is dynamic-casted to Actor_.

@shadeMe I suggest that when possible we should review the various difference and adopt one of them as standard.
What do you think?

@shadeMe I saw various dialogue (expecially hellos) making use of GetDisease.
I know that it was never implemented for scripts. But it was implemented for dialogue condition?

Scripting for it doesn't seem to run until player speaks to the NPC, even if they are in fact running a new script package

At least when formatted strings with some extended specifiers are passed as arguments to non-EX versions of functions such as MessageBox.

It would be convenient if the compiler were patched to disallow this but, if that is not worth the effort (because I am aware I'm talking about a consequence of misusing nearly fully deprecated functionality after all), adding a simple note in the docs would still help make people aware of this risk.

Don't know why nobody ever requested this: is the passed string a number?

Currently we have 2 "string to number" commands:

• sv_ToNumeric, which parse the string from left to right and stops as soon as it find an invalid char, then it returns the number read so far, and we don't know if the conversion succeed up to the end.
• ToNumber / #, which return the number read (if succeed) or 0 if there's an invalid char, but the string may actually be exactly "0", so when it returns 0 we can't be sure it's an error.

So, both commands don't give clues about the result of the conversion, so we have to use a check like this one:
If Eval (strVar == $(#strVar))
If "#" conversion succeed, $ will return the original string. Only exception: it doesn't work if original string is "00" (or more zeroes), which is still a valid number. Also, a double ToNumber/ToString is an unnecessary waste of time.

Or returns an empty array if the map was never showed

Also make HasSpell and related functions to search into livelled list???

From waht I was able to understand is a game bug not an obse one

I noticed the compiler doesn't complains when I type something like this:

scn someScript

Short someVar := 5
Float anotherVar := 4.25

The variables remain 0, so the assignments are ignored, but the compiler says nothing.
I even tried with other types, and it seems String_Var and/or Array_Var freeze the script at runtime.

You may make the complier recognize the error, but I have a better idea (if possible, of course): implements a working declaration+initialization as above. It could be useful for special variables like fQuestDelayTime.

Damn, it was already open... how do I delete this?

I've read very old posts where people said it worked differently for them, but for me it seems to include fortify abilities just like GetBaseAV.

I suspect normal precedence rules may not even apply to quotation marks in general, but parentheses appear to behave as though they didn't precede them under some circumstances during evaluation. This isn't the case during assignment. It is also not the case for brackets.

Specifics

This compiles just fine:

if eval svTest == "( )"
  Let svTest := " )"
endif

On the other hand, the compiler complains about mismatched parentheses when I try anything like this:

if eval svTest == " )"
endif

I tested and confirmed this behaviour in CS, CS + OBSE, GameMode & Function blocks, with/without compiler override, and with/without eval.

I apologise in advance for the title's technical inaccuracy if it just so happens this has nothing to do with actual precedence rules. I also apologise if I made any mistakes as the GitHub newbie that I am.

by a set/let command or by if eval

These compile but aren't documented anywhere. I noticed SetPlayerSkeletonPath is in the wiki though, along with some other ones that aren't in the html command doc that is bundled in the archive. I'm going to try to list them up here later.

GetCurrentFrameIndex
SetPlayerSkeletonPath (I tested it only once in-game, it just CTD)

Passing functions as ref vars to the Call command bypasses the compile-time type checking. While this is advantageous (makes UDFs first-class objects of a kind), it's a currently undocumented feature.

Would be nice to have an easy way to detect if an actor got into ragdoll state through PushActorAway. If GetKnockedState is incapable of detecting other situations where an actor is ragdolling, it might be a good idea to implement something more general, like an IsRagdoll function, to use it in conjunction with GetKnockedState when necessary.

Currently doesn't include summons or bound armor/weapons

Really sorry for the long title. It should be clear, though (I hope). When using this syntax to call a function...

ref.FunctionName <Expression(s)>

...any non-redirected function calls made as part of an OBSE expression and passed as arguments to that function are called on the same reference as the function in question (ref, in this case).

Example:

Let refVar := UrielSeptimRef
if GetSelf == PlayerRef
   refVar.Call SomeFunction (GetBaseObject)
   ;GetBaseObject in this context returns UrielSeptim, NOT Player.
endif

I guess for most people with an object-oriented programming background this is merely expected behaviour, but most modders don't have such a background. Redirecting function calls was already doable before OBSE, but it was the implementation of OBSE expressions that allowed modders to experience this behaviour, so I believe this is another bit of relevant info that is worth a mention in the docs. Perhaps in the existing section covering Considerations for using OBSE expressions.

As the title says, using GetFirstRef (and other cell scan commands) with a form type filter (other than 0/None) makes the command ignore references marked for deletion, but still not deleted.

Since altering this behaviour may alter the behaviour of existing scripts, I propose to add another optional parameter includeDeletedRefs:int, which allow the commands to include those references.

Make sv_ToNumeric accept array entries as parameter (like "let MyNumber := sv_ToNumeric MyArray[0]" ). Currently accepts only string vars ("Let MyNumber := sv_ToNumeric MyString).

Function is at address 0x4F0620
this is probably the calling worldspace.

Is there any known hook that could be used to fire the OnMurder event when the Kill function is called without passing the optional ActorID argument to it?

As it is now, I presume OnMurder is meant to fire only when a normal murder is triggered, and possibly also when an 'artificial' murder is caused by the vanilla Kill command. I was thinking It would be handy that the Kill command were a surefire way to fire the OnMurder event because, even then, passing 0 to the event's Killer argument would make it possible to differentiate a plain Kill call from an actual murder. This would bestow on modders the ability to determine if an actor was killed by the Kill command, specifically.

Normally this change would break older mods that register OnMurder handlers but, given the current circumstances, this particular event is not firing for any mod right now (see #3) so changing these mechanics in a next update shouldn't be a problem as long as the documentation is properly updated to reflect these changes.

Alternatively, and still assuming this entire idea is feasible, an additional OnKill event could be implemented for this only purpose.

EDIT: I guess passing a special value to OnDeath events for this particular case would be another option but, considering OnDeath does work, that would be way more likely to break something.

We have SetEventHandler and RemoveEventHandler... but not a single method to check whatever an event handler exists.
SetEventHandler doesn't overwrite existing event handlers, so calling it multiple times with the same parameters will effectively register the same handler multiple times (and so the event will call the function multiple times).
Since we can't check whatever an event handler has already been registered, we're forced to destroy any possible existing handler with RemoveEventHandler and then registering it (again, if it was removed).

<bool> EventHandlerExists <eventName::string> <function::ref> <filter1> <filter2>
where and are optional.

Doesnt' fire the first time a savegame is loaded in the session, generally fire after reload.
Maybe it happen also for PostLoadGame callbacks? They are strictly related

The current steam loader implementation doesn't work consistently. Update it to the implementation the other xSE projects (I'll need to consult with Ian first).

Many sv_* commands actually only work with String_var (and not strings), so if we have a string built with concatenation or as a result of a command/function, these commands force us to store the string in a String_var in order to use them, but it could be useful to use them on the fly.

Example:
Let pos := sv_Find "e", $actor ;search for character 'e' in actor's name