[LE] If Conditional Operand

[maxarturo]

I again forgot to add that:

Now the issue that i'm having is that i don't want to use in the same script the "Store Value" and "Game.GetPlayer()", which this weird issue is forcing me to do.

Well i do have the option to replace all the "Store Values" with "Game.GetPlayer()" which again i want to avoid doing in those 3 specific scripts that i'm having the issue, since they call multiple times for the Player in a short time (milliseconds).

[Cheyron]

I would think this would be easier to do (see code below) as in easier to just write it this way... akActionRef is also local so the cpu has access to this data when it pops it off the stack... it doesn't have to calculate where this data is to reference it... that event when called has to push it's arguments onto a "stack" of data that the cpu can grab data from to execute with that event function. Im no expert so obviously to get better detail you should google how cpu code works and how to write efficient code that creates better assembly code... look into like asm x86 (just a disclaimer since I don't claim to be an expert and don't want to give wrong info)

 

 

If ( akActionRef == Game.GetPlayer() )

Actor a = akActionRef as Actor

a.DamageActorValue("Health", a.GetActorValue("Health") * 0.50)

a.DamageActorValue("Magicka", a.GetActorValue("Magicka") * 0.50)

a.DamageActorValue("Stamina", a.GetActorValue("Stamina") * 0.50)

 

I think that would be better but maybe I am wrong, when you cast an object you aren't really doing anything other than telling the compiler what the data looks like at so and so address. using ObjectReference wont compile because the function wants an actor which is a derived class... for it to work, ActioRef would need to be an actor and then if the function wanted an objectreference that would be possible because an actor IS an objectreference but an objectreference IS NOT an actor. You don't need to cast children to the parent but you do cast parent to the children if the parent object points to an instance of the child object

 

Yeah so casting is not really arithmetic for the cpu but using . to go into a class is arithmetic. Probably you can cast the same thing multiple times and it is fine. If it was me I would just declare it since that is my habit.

[Grospolina]

No need to cast at all. Read this: GetPlayer. It says that instead of calling GetPlayer() more than once, use the PlayerRef property. This should be quicker:

Actor Property PlayerRef Auto

Event OnActivate(ObjectReference akActionRef)
    If (akActionRef == PlayerRef)
        PlayerRef.DamageActorValue("Health", PlayerRef.GetActorValue("Health") * 0.50)
        PlayerRef.DamageActorValue("Magicka", PlayerRef.GetActorValue("Magicka") * 0.50)
        PlayerRef.DamageActorValue("Stamina", PlayerRef.GetActorValue("Stamina") * 0.50)
        ...
    EndIf
EndEvent

[maxarturo]

 

No need to cast at all. Read this: GetPlayer. It says that instead of calling GetPlayer() more than once, use the PlayerRef property. This should be quicker:

Actor Property PlayerRef Auto

Event OnActivate(ObjectReference akActionRef)
    If (akActionRef == PlayerRef)
        PlayerRef.DamageActorValue("Health", PlayerRef.GetActorValue("Health") * 0.50)
        PlayerRef.DamageActorValue("Magicka", PlayerRef.GetActorValue("Magicka") * 0.50)
        PlayerRef.DamageActorValue("Stamina", PlayerRef.GetActorValue("Stamina") * 0.50)
        ...
    EndIf
EndEvent

 

Thanks, but i do know about this...

I posted this because i never just make a script and i'm done with it, but i will always experiment and put some stress to it to see how the game engine will responed, plus this is the only way to discover things like the issue i mentioned.

I'll spend 15 minutes creating my script and 8 hours experimenting (more or less).

* The issue with "Player Ref" / filling the Player in a Property is that make the reference persistent.

Edited December 11, 2019 by maxarturo

[IsharaMeradin]

Yes, a property filled with a reference can make that reference persistent. But when that reference is the player, that argument is moot. The player will always be persistent anyway.

[maxarturo]

Yes, a property filled with a reference can make that reference persistent. But when that reference is the player, that argument is moot. The player will always be persistent anyway.

 

Can you please define/explain "moot", i don't know this word and the translation i get makes NO SENSE !!!... unless you are referring to an animal...

[IsharaMeradin]

 

Yes, a property filled with a reference can make that reference persistent. But when that reference is the player, that argument is moot. The player will always be persistent anyway.

 

Can you please define/explain "moot", i don't know this word and the translation i get makes NO SENSE !!!... unless you are referring to an animal...

 

moot -- adjective

1. subject to debate, dispute, or uncertainty.

2. having little or no practical relevance, typically because the subject is too uncertain to allow a decision.

 

In other words, it is pointless to argue that one should avoid using a property to reference the player because it will make the player persistent. The player is already persistent.

 

There are other reasons that one can use to argue against using a property to reference the player. Chief among them would be: how much memory will it cost; how long will it stick around without actually being used.

[maxarturo]

 

 

Yes, a property filled with a reference can make that reference persistent. But when that reference is the player, that argument is moot. The player will always be persistent anyway.

 

Can you please define/explain "moot", i don't know this word and the translation i get makes NO SENSE !!!... unless you are referring to an animal...

 

moot -- adjective

1. subject to debate, dispute, or uncertainty.

2. having little or no practical relevance, typically because the subject is too uncertain to allow a decision.

 

In other words, it is pointless to argue that one should avoid using a property to reference the player because it will make the player persistent. The player is already persistent.

 

There are other reasons that one can use to argue against using a property to reference the player. Chief among them would be: how much memory will it cost; how long will it stick around without actually being used.

 

 

Thanks for the explanation.

"how much memory will it cost; how long will it stick around without actually being used."

This actually helped me a lot in deciding on how to move with those 3 particular scripts, two of them will stick around from the minute you enter the cell until they get activated (at the end of the cell), and the other is running from the minute you enter the cell until you actually defeat the final Boss.

Thanks a lot !.

[PeterMartyr]

Why do people call pointers to a memory allocation memory?

 

Then get get confused by pointers in the game save that create pointers in the memory that point to an instance of a memory allocation?

 

If it persistent in the game save it will be there always! nuff said.

 

Don' worry about what is really happening, cos the above is the most accurate watered down explanations ever.

 

Also I am also confident Skyrim passes the buck to Windows to clean the Memory. In regard to how long it there.

 

Confused? :D

 

Edit btw

 

Persistent is just fancy way of saying "The pointer is a Game Save or Esp" and can be retrieved. For multiple repeated use.