Jump to content

[LE] Script bug and optimization questions


Guest deleted12092523

Recommended Posts

Guest deleted12092523

As always, I am very happy that you took the time to help me out.

 

I know I tend to beat around the bush, I apologize. If you get to the last paragraph, I explain what the bug actually was. I was trying to include details just encase there is something I should know about those things that might have been the root cause. I got my answer for that one.

 

This is essentially what testiger2 was suggesting, except with an int instead of a bool. I would probably just use a bool if my value could only be 1 of 2 things.

 

I think I ultimately like the idea maxarturo had. Setting a state seems messy, but functionally faster. Instead of telling the script to do value assignments and to assess those values, I can just tell it to go to a state. It will automatically ignore anything not in the state, essentially disabling the OnActivate() event listener.

 

When I finally get back on the computer, I am gonna show off my finished version and you guys can critique it.

Edited by smashballsx88
Link to comment
Share on other sites

There is only a part your scripts. Maybe something like that, I used your approach with disable/enable.

 

AAAxWCxINVxPurchaseScript

  Reveal hidden contents

 

Link to comment
Share on other sites

Guest deleted12092523

Well ReDragon2013 gave me a new idea, funny enough it's actually related to a completely different issue with the script, the way you re-did my delete function with "myF_REM(Int i = 0)" got me thinking about it. I didn't remember I could only do 1 Linked Reference per keyword on an object, so I changed the system to dynamically erase every object in a linked chain.

 

"change button position to prevent ESC pressed error" I have never heard of this one before, when I go into the game I can't use ESC to exit, and when I turn my controller on it forces me to pick one of the options. Is this related to SkyUI? I have been testing this mod on the vanilla version, trying to keep it away from dependencies since the mod is just too simple.

 

Also, you really go out of your way to re-write the script in your own technique, that's pretty awesome. What I notice is you really like to use IF statements then manually force the script to stop with RETURN. Why is that? Do you just like to keep things on 1 level for read-ability?

 

maxarturo I decided to use your way because it makes me feel like my script has more stable security against multiple activations. Though I don't know if it actually does, or if using a bool/int does the job equally well.

 

testiger2 & NexusComa2 I am no programmer! So I don't understand concepts like "Fist time Flag" yet. I am scratching the surface on learning more advanced methods of scripting, so I appreciate the knowledge.

 

So, this is what I have come up with, it does 1 new operation but it does essentially the same thing.

 

The only thing that I am unsure of is using a while loop in "Function DeleteRef()". I heard this can bloat saves, but is it fine if its just fired for a brief amount of time? I feel like uninstalling the mod while its actively doing this in a save is a highly unlikely phenomenon.

 

 

  Reveal hidden contents

 

Edited by smashballsx88
Link to comment
Share on other sites

Don't need to explicitly declare the empty activation in the Disabled state. Undeclared events fall back to their defaults, which is an empty block anyway.

 

However, my suggestion would be to go to the Disabled state immediately on activation, regardless of whether or not the player has the gold, etc. Do all those checks there, and then either display the menu or go back to the Active state. This gives the smallest possible window for malformed input and should functionally guarantee that all the code finishes running, in either path, before a new trigger can start it again.

 

For clarity I'd probably rename them from Active -> Waiting and Disabled -> Active.

Link to comment
Share on other sites

Guest deleted12092523
  On 8/5/2020 at 4:43 PM, foamyesque said:

Don't need to explicitly declare the empty activation in the Disabled state. Undeclared events fall back to their defaults, which is an empty block anyway.

 

However, my suggestion would be to go to the Disabled state immediately on activation, regardless of whether or not the player has the gold, etc. Do all those checks there, and then either display the menu or go back to the Active state. This gives the smallest possible window for malformed input and should functionally guarantee that all the code finishes running, in either path, before a new trigger can start it again.

 

For clarity I'd probably rename them from Active -> Waiting and Disabled -> Active.

Noted. Thanks! I changed it up, I wasn't aware changing the state didn't end the current function abruptly.

 

  Reveal hidden contents

 

 

Which brings me to my next consistently recurring train of thought. What will force a script to drop what it's doing, besides "return"?

 

Would this work? Or will it only read the current running function before before having issues?

 

  Reveal hidden contents

 

 

I have a feeling this will fail to run "MyFunc()" inside the "Waiting" state, and will run the one inside the empty state instead. That would makes since to me, but let's make sure I am not going insane here.

Edited by xWilburCobbx
Link to comment
Share on other sites

  On 8/7/2020 at 5:18 AM, xWilburCobbx said:

 

  On 8/5/2020 at 4:43 PM, foamyesque said:

Don't need to explicitly declare the empty activation in the Disabled state. Undeclared events fall back to their defaults, which is an empty block anyway.

 

However, my suggestion would be to go to the Disabled state immediately on activation, regardless of whether or not the player has the gold, etc. Do all those checks there, and then either display the menu or go back to the Active state. This gives the smallest possible window for malformed input and should functionally guarantee that all the code finishes running, in either path, before a new trigger can start it again.

 

For clarity I'd probably rename them from Active -> Waiting and Disabled -> Active.

Noted. Thanks! I changed it up, I wasn't aware changing the state didn't end the current function abruptly.

 

  Reveal hidden contents

 

 

Which brings me to my next consistently recurring train of thought. What will force a script to drop what it's doing, besides "return"?

 

Would this work? Or will it only read the current running function before before having issues?

 

  Reveal hidden contents

 

 

I have a feeling this will fail to run "MyFunc()" inside the "Waiting" state, and will run the one inside the empty state instead. That would makes since to me, but let's make sure I am not going insane here.

 

 

What will happen there is, assuming it starts in the Waiting state and something triggers the OnActivate Event:

 

 

The OnActivate event declared in the Waiting state starts processing. The first thing it does is put the script into the empty state, so any further function calls or event triggers will use the versions declared in the empty state. Then it proceeds to call MyFunct(), which will use the empty state version, and therefore not call MyFunct2(), so the script doesn't get put back into the Waiting state.

Link to comment
Share on other sites

foamyesque and ReDragon2013 are more than capable to guide you through this.


I just want to add that, although 'States' are one of the most reliable and fastest functions, they need an extensive care, you need to be very careful with them.


One wrong 'State Call' or one simple 'Typo' can F**** UP EVERYTHING !!l.

Plus the most important : TYPOS on the 'State' won't trigger a "Compile Error", so you can have a fully functional without errors script that in-game is not working correctly and all this because your 'State' has a 'Typo'.


It happened to me with the mod i recently released.


A few days before publishing it, i made a minor addition to one simple script and didn't test it, there was no need for it since it's just a simple script, but in-game the script wasn't working correctly.


All of this from some stupid cookie crumbs on my keyboard !!, instead of writing "GoToState("WaitingPlayer")" i wrote "GoToState("WaitingPlayr")" without an "E".

Edited by maxarturo
Link to comment
Share on other sites

Guest deleted12092523
  On 8/7/2020 at 2:37 PM, maxarturo said:

 

foamyesque and ReDragon2013 are more than capable to guide you through this.
I just want to add that, although 'States' are one of the most reliable and fastest functions, they need an extensive care, you need to be very careful with them.
One wrong 'State Call' or one simple 'Typo' can F**** UP EVERYTHING !!l.
Plus the most important : TYPOS on the 'State' won't trigger a "Compile Error", so you can have a fully functional without errors script that in-game is not working correctly and all this because your 'State' has a 'Typo'.
It happened to me with the mod i recently released.
A few days before publishing it, i made a minor addition to one simple script and didn't test it, there was no need for it since it's just a simple script, but in-game the script wasn't working correctly.
All of this from some stupid cookie crumbs on my keyboard !!, instead of writing "GoToState("WaitingPlayer")" i wrote "GoToState("WaitingPlayr")" without an "E".

 

You aren't kidding! I typo'd "GotoState("Standby")" and wrote "Standb" I had a bit of a hard time understanding why my trigger wasn't usable after I clicked away the fail message. I opened the .psc back up and immediately spotted it, luckily my script is small!

Link to comment
Share on other sites

Guest deleted12092523
  On 8/7/2020 at 6:53 AM, foamyesque said:

What will happen there is, assuming it starts in the Waiting state and something triggers the OnActivate Event:

 

The OnActivate event declared in the Waiting state starts processing. The first thing it does is put the script into the empty state, so any further function calls or event triggers will use the versions declared in the empty state. Then it proceeds to call MyFunct(), which will use the empty state version, and therefore not call MyFunct2(), so the script doesn't get put back into the Waiting state.

Yeah, I figured as much, thanks for clarifying. Its super useful to know that once a function is ran, no matter what state the script changes to while running the function, it wont stop and it will only change for future runs.

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...