Author Topic: Client crashing testing  (Read 4713 times)

0 Members and 1 Guest are viewing this topic.

Offline OMGBurgersTopic starter

  • Hero Member
  • *
  • Posts: 800
  • Activity:
    0%
  • Reputation Power: 7
  • OMGBurgers has no influence.
  • Respect: +44
  • Referrals: 0
    • View Profile
Client crashing testing
« on: May 16, 2021, 01:53:10 PM »
0
Ok, so I've been complaining about client crashing since I started playing again, as you can see from the thread below haha.

Eventually I found an issue with lines in the script not being executed, which led me to figure out my crashing problems for the most part.

I'm unsure if it's something on EasyUO's end, or with the client itself.  But this is an issue I haven't encountered when I played previously.  I sold all my account back in 2012-2013.  I have not started experiencing these problems until we got the auto updating EUO.

So in the first video, you can see I use a script that just opens the corpse, loots the gold.  When opening the corpse it will output the ID above the character.  I added that because I was unsure what was going on with it not doing the "event macro 17", but then found it would skip the event exmsg even.
Video:


After finding that, I clamped the rate of the "event macro 27 0" usage on my combat script.  This fixed an issue with quite a few things I did, but I was still crashing on other scripts.  The one I would crash on often was the Shadowguard helper which helps with Orchard room.  So I have no "Event macro 27 0" command going here.  I originally thought it was from more than one script sending an event macro, or exevent command to the client at the same time.  But I was crashing with a single script.  So that would mean I was crashing because of a combination of events being sent, or the speed in which they've been sent.  I can force a crash using many combinations of events, so I'm not sure it's a specific one.  I have noticed that event exmsg displays weird at times though, and when it does I can prepare for a crash.  But even without event exmsg, I will still crash.

Here's a video showing the crashing with multiple event commands, and with a few different methods of running euo/client.
Video:


I know everyone has their own way they swear on to load everything, but believe me, I have tried for weeks to resolve this and I cannot find a better way which works.  Starting a client with uoxl cli new button in easyuo is not an option, as I use either steam/razor/razor-enhanced and they have to start the client.  But it also doesn't help if I do.  So this isn't about that.
« Last Edit: May 16, 2021, 02:02:20 PM by OMGBurgers »

Offline OMGBurgersTopic starter

  • Hero Member
  • *
  • Posts: 800
  • Activity:
    0%
  • Reputation Power: 7
  • OMGBurgers has no influence.
  • Respect: +44
  • Referrals: 0
    • View Profile
Re: Client crashing testing
« Reply #1 on: May 16, 2021, 01:59:50 PM »
0
Also if it matters, I am using the latest EasyUO, and a fully patch UO client, Windows 7 64.

If anyone has time, if they could test and see if they encounter the same things as me that would be greatly appreciated.  I have the (one) scripts I used in the videos here below. (I removed the others, as it seemed to cause confusion)

Script to force crashing:
Code: [Select]
set #lpc 1000
set %count 0
set %p 1

loop:
   if %p = 1
      {
      if #random > 500
         set %y #charposy + 1
      else
         set %y #charposy - 1
      event pathfind #charposx %y
      }
   event macro 3 0 crash
   event exmsg #charid 0 90 crash , #spc , %count
   event sysmessage crash , #spc , %count
   event macro 8 2
   exevent popup #charid

   set %count %count + 1
   wait 2s
goto loop
« Last Edit: May 16, 2021, 08:22:22 PM by OMGBurgers »

Offline Scotch_Tape

  • Jr. Member
  • **
  • Posts: 55
  • Activity:
    0%
  • Reputation Power: 1
  • Scotch_Tape has no influence.
  • Respect: 0
  • Referrals: 0
    • View Profile
Re: Client crashing testing
« Reply #2 on: May 16, 2021, 02:03:32 PM »
0
Using euox new client can you not just point it to razor or whatever else you use? Would that be the same as just opening another client manually? I did try it the other day and it didn't instantly crash so I assumed it was a fix but hadn't tested it much maybe I was wrong.

Offline OMGBurgersTopic starter

  • Hero Member
  • *
  • Posts: 800
  • Activity:
    0%
  • Reputation Power: 7
  • OMGBurgers has no influence.
  • Respect: +44
  • Referrals: 0
    • View Profile
Re: Client crashing testing
« Reply #3 on: May 16, 2021, 02:18:09 PM »
0
I have been trying different start methods for a few months now.  No different combination or order gave me better stability overall.

I have reduced my crashes to 0 yesterday since discovering what I shown in the videos.  I was running 3 clients, all razor enhanced with uncapped FPS, easyuo with 7 scripts and 4 of them doing uoxl swapping at speeds of < 100ms controlling all clients at once.

I'm really just interested if others experience the same oddities with easyuo as I shown in the video, along with the crashing with those events, or if it's an isolated with my stupid computer lol.

Offline Gaderian

  • Elite
  • *
  • *
  • Posts: 486
  • Activity:
    0%
  • Reputation Power: 10
  • Gaderian barely matters.Gaderian barely matters.
  • Respect: +50
  • Referrals: 3
    • View Profile
Re: Client crashing testing
« Reply #4 on: May 16, 2021, 05:30:56 PM »
0
You have a lot of parameters to testing this that are unspecified.
"Steam/razor/razor-enhanced" - am I supposed to try all of these?

Your script issues a "gosub action init", but your sub action has no "init" test to do anything. I think you intend for all your variables to be N/A instead so you try to set these up, but what does "if N/A < #systime - 3000" mean in the evaluation? Reading this and it seems it needs a clearer execution path.

How do you guarantee there are no actions happening in the other applications?

I tried writing a simple looter to pick up gold on the ground. I was running a few clients (razor/razor-enhanced) in the same way you describe. I would get a crash all the time when 2 clients would try to pick up the same item.

When it comes to client actions, it doesn't matter what the source - the client has to be able to process the actions and have appropriate wait times or it is guaranteed to crash. :) So how do you isolate that nothing is happening in the other software that interacts with the client?

Have you tried all this without the auto-update version of EUO?

"Go ahead ask me: 'Should I use hard waits or timers?'"
You say:"Should I"
Gaderian:"Timers!"
You Say:"use hard waits or timers?"

The serious side of timer use is illustrated here: http://www.scriptuo.com/index.php?topic=12094.msg101926#msg101926

However, every time I go back and look at this [AutoLooter] script, I realize I had wrote it in my zen state of EUO scripting - so it makes my brain hurt.

Offline Gaderian

  • Elite
  • *
  • *
  • Posts: 486
  • Activity:
    0%
  • Reputation Power: 10
  • Gaderian barely matters.Gaderian barely matters.
  • Respect: +50
  • Referrals: 3
    • View Profile
Re: Client crashing testing
« Reply #5 on: May 16, 2021, 05:31:57 PM »
0
So I tried the first script.
No crashes, but it does nothing, because %p = 0 and then it only moves when %p = 1.

How are you setting %p to 1 so it actually tries to move?

I hard coded it to 1, and let it run now. 100+ pathfinds later and no disconnect.

I stopped it once %count reached 200.

I went to try to use Razor Enhanced - it doesn't want to connect to OSI. I have only used it on freeshards.

So Razor Enhanced (started first!) and then Easyuo (Auto-update version) modified %p=1 script and more than 200 pathfind loops without a crash.
« Last Edit: May 16, 2021, 06:13:09 PM by Gaderian »
"Go ahead ask me: 'Should I use hard waits or timers?'"
You say:"Should I"
Gaderian:"Timers!"
You Say:"use hard waits or timers?"

The serious side of timer use is illustrated here: http://www.scriptuo.com/index.php?topic=12094.msg101926#msg101926

However, every time I go back and look at this [AutoLooter] script, I realize I had wrote it in my zen state of EUO scripting - so it makes my brain hurt.

Offline Scotch_Tape

  • Jr. Member
  • **
  • Posts: 55
  • Activity:
    0%
  • Reputation Power: 1
  • Scotch_Tape has no influence.
  • Respect: 0
  • Referrals: 0
    • View Profile
Re: Client crashing testing
« Reply #6 on: May 16, 2021, 05:55:28 PM »
0
Processor   Intel(R) Core(TM) i7-4510U CPU @ 2.00GHz   2.60 GHz
Installed RAM   12.0 GB (11.9 GB usable)
System type   64-bit operating system, x64-based processor
Edition   Windows 10 Pro
Version   20H2
Installed on   ‎4/‎21/‎2021
OS build   19042.985
Experience   Windows Feature Experience Pack 120.2212.2020.0


EasyUO 1.6.0.335
Ultima Online 7.0.90.16
*Edit Running through Classic Razor V1.0.14

Ran your snippets a while and didn't have any crashing.  I killed skeletons with the 2nd and 3rd script individually for about 30 minutes with no crashing.  I'm only crashing with opening easyuo and client a certain way or sometimes client swapping but what you're dealing with is way worse.  I dig up pipelines and fix them for a living so obviously I have no useful input, but maybe if a few others test this you'll be able to determine if it's a you problem or an everyone problem.  If you've got anything else you wanted to test I'll give it a shot for you.     


« Last Edit: May 16, 2021, 05:57:32 PM by Scotch_Tape »

Offline OMGBurgersTopic starter

  • Hero Member
  • *
  • Posts: 800
  • Activity:
    0%
  • Reputation Power: 7
  • OMGBurgers has no influence.
  • Respect: +44
  • Referrals: 0
    • View Profile
Re: Client crashing testing
« Reply #7 on: May 16, 2021, 08:07:56 PM »
0
You have a lot of parameters to testing this that are unspecified.
"Steam/razor/razor-enhanced" - am I supposed to try all of these?
I just noted about why I don't use the uoxl cli new button to start clients, those "assist tools" have no effect as far as I can tell.  Just any way you normally open a script & play it will work.

Your script issues a "gosub action init", but your sub action has no "init" test to do anything. I think you intend for all your variables to be N/A instead so you try to set these up, but what does "if N/A < #systime - 3000" mean in the evaluation? Reading this and it seems it needs a clearer execution path.
The gosub action init will do something, even though it specifically doesn't use the init part.  It will still hit the first 2 if statements, and bypass the 2nd two, thus initializing the namespace variables. You can put anything there as long as its not set/wait and it would do the same.  I could initialize the sub by just calling a gosub action wait, or gosub action set, but I do this way for searching purposes when im debugging.
I will remove these scripts, as they have nothing to do with the crashing, as I think it's causing confusion.  It was just there to test if when running "test script" and "test2 script" if the client/easyuo would skip the event macro 17 or the event exmsg occasionally.
Edit:  Those are removed.

How do you guarantee there are no actions happening in the other applications?

I tried writing a simple looter to pick up gold on the ground. I was running a few clients (razor/razor-enhanced) in the same way you describe. I would get a crash all the time when 2 clients would try to pick up the same item.

When it comes to client actions, it doesn't matter what the source - the client has to be able to process the actions and have appropriate wait times or it is guaranteed to crash. :) So how do you isolate that nothing is happening in the other software that interacts with the client?
I am running no other scripts, nor are any other applications doing anything.  I thought the video showed that.  The only actions done were the easyuo scripts shown in the video.



So I tried the first script.
No crashes, but it does nothing, because %p = 0 and then it only moves when %p = 1.

How are you setting %p to 1 so it actually tries to move?

I hard coded it to 1, and let it run now. 100+ pathfinds later and no disconnect.

I stopped it once %count reached 200.

I went to try to use Razor Enhanced - it doesn't want to connect to OSI. I have only used it on freeshards.

So Razor Enhanced (started first!) and then Easyuo (Auto-update version) modified %p=1 script and more than 200 pathfind loops without a crash.
Sorry, maybe that was an oversight on my part.  The script will do nothing unless you uncomment the event lines, and set %p to 1 to enable pathfinding.  I had it set in an idle state so people could enable things a set at a time, rather than all at once.  You absolutely should not get a crash if it only pathfinds.

I have edited the post to have %p 1, and all lines uncommented.  Next time I should just grab my mic and explain it better in the video.

Code: [Select]
set #lpc 1000
set %count 0
set %p 1

loop:
   if %p = 1
      {
      if #random > 500
         set %y #charposy + 1
      else
         set %y #charposy - 1
      event pathfind #charposx %y
      }
   event macro 3 0 crash
   event exmsg #charid 0 90 crash , #spc , %count
   event sysmessage crash , #spc , %count
   event macro 8 2
   exevent popup #charid

   set %count %count + 1
   wait 2s
goto loop

The one w/ the gold loot and auto attack isn't expecting any crash.  It shouldn't crash.  As per my video, I showed how it would skip either the event exmsg or the event macro 17 to open the corpse.  I was curious to see if others had the same problem with that one.
« Last Edit: May 16, 2021, 08:28:38 PM by OMGBurgers »

Offline OMGBurgersTopic starter

  • Hero Member
  • *
  • Posts: 800
  • Activity:
    0%
  • Reputation Power: 7
  • OMGBurgers has no influence.
  • Respect: +44
  • Referrals: 0
    • View Profile
Re: Client crashing testing
« Reply #8 on: May 16, 2021, 08:30:47 PM »
0
Ran your snippets a while and didn't have any crashing.  I killed skeletons with the 2nd and 3rd script individually for about 30 minutes with no crashing.  I'm only crashing with opening easyuo and client a certain way or sometimes client swapping but what you're dealing with is way worse.  I dig up pipelines and fix them for a living so obviously I have no useful input, but maybe if a few others test this you'll be able to determine if it's a you problem or an everyone problem.  If you've got anything else you wanted to test I'll give it a shot for you.   

Yeah the one I showed in the skeletons & shadow wisps shouldnt crash.  It was to check if it also skipped the event macro 17 corpse open and/or the event exmsg ocasionally if you ran them both at the same time, not seperate.  But I removed those.

The remaining one I edited to the condition that will force a crash for me in ~5 - 10 seconds every time.

Offline Gaderian

  • Elite
  • *
  • *
  • Posts: 486
  • Activity:
    0%
  • Reputation Power: 10
  • Gaderian barely matters.Gaderian barely matters.
  • Respect: +50
  • Referrals: 3
    • View Profile
Re: Client crashing testing
« Reply #9 on: May 16, 2021, 08:49:53 PM »
0
I have managed to now get Razor Enhanced to crash.
Some of the combinations of statements last longer when waits are given.

Did you try these in the non-auto-update version of easyuo? (did i miss your response?)

I added a wait between 2 of the statements and ran it successfully for 100 attempts. Without the wait it failed very soon after running.
« Last Edit: May 16, 2021, 08:52:27 PM by Gaderian »
"Go ahead ask me: 'Should I use hard waits or timers?'"
You say:"Should I"
Gaderian:"Timers!"
You Say:"use hard waits or timers?"

The serious side of timer use is illustrated here: http://www.scriptuo.com/index.php?topic=12094.msg101926#msg101926

However, every time I go back and look at this [AutoLooter] script, I realize I had wrote it in my zen state of EUO scripting - so it makes my brain hurt.

Offline OMGBurgersTopic starter

  • Hero Member
  • *
  • Posts: 800
  • Activity:
    0%
  • Reputation Power: 7
  • OMGBurgers has no influence.
  • Respect: +44
  • Referrals: 0
    • View Profile
Re: Client crashing testing
« Reply #10 on: May 16, 2021, 08:55:26 PM »
0
I have managed to now get Razor Enhanced to crash.
Some of the combinations of statements last longer when waits are given.

Did you try these in the non-auto-update version of easyuo? (did i miss your response?)
That's good it had you crash also.  I don't have waits in there just as a worst case scenario. I created a sub to globally handle events ro ensure delays are there, and stopped using event exmsg and I no longer crash.  I was just curious if it would crash others.

I tried to compile my own easyuo based on some instructions here but I messed up and was unsuccessful.  So my only option (that I'm aware of) is to use the auto updating one.

Offline Gaderian

  • Elite
  • *
  • *
  • Posts: 486
  • Activity:
    0%
  • Reputation Power: 10
  • Gaderian barely matters.Gaderian barely matters.
  • Respect: +50
  • Referrals: 3
    • View Profile
Re: Client crashing testing
« Reply #11 on: May 16, 2021, 09:12:19 PM »
0
So I inserted a wait 20 between each event/exevent and I am up to 197 cycles without crashing.

I am unconvinced that the pre-auto-update version of EUO would fare better.

The events try to activate actions using the clients settings. The client sends the network communication to the server and wait for it's response.

The exevents send a packet stream to the server - it by passes the client actions, but the server expects the client sent those. So it's response comes back and the client may not be able to handle a non-linear order. Including the waits allows for the response to be processed by the client - so that's a good thing.

So the crashes you have setup here are the same things seen when multiple script tools interact with the client and essentially stomp on each other. The client has no way to queue all those responses. Typical network communication is written to queue requests as a server process, but not as a client. So executing all those commands, nearly at once, means in a moment you will get several responses from the server and either those will be dropped or give a response that the client doesn't expect at this time.

So the waits allow the process to complete. Internal to the client, there are natural waits, but we peek and poke at the process memory to make it do things in our control.
"Go ahead ask me: 'Should I use hard waits or timers?'"
You say:"Should I"
Gaderian:"Timers!"
You Say:"use hard waits or timers?"

The serious side of timer use is illustrated here: http://www.scriptuo.com/index.php?topic=12094.msg101926#msg101926

However, every time I go back and look at this [AutoLooter] script, I realize I had wrote it in my zen state of EUO scripting - so it makes my brain hurt.

Offline OMGBurgersTopic starter

  • Hero Member
  • *
  • Posts: 800
  • Activity:
    0%
  • Reputation Power: 7
  • OMGBurgers has no influence.
  • Respect: +44
  • Referrals: 0
    • View Profile
Re: Client crashing testing
« Reply #12 on: May 16, 2021, 09:49:00 PM »
0
Yes I would assume a wait of that magnitude would reduce crashing, but would render something like an auto spawner unproductive.

There must have been a change at one point or another, somewhere,  be client side, server side, or easyuo.

I have unmodified scripts I used to run long ago that still work properly, but not reliable because of crashing. These are scripts I could run all day without issue. 

Offline Gaderian

  • Elite
  • *
  • *
  • Posts: 486
  • Activity:
    0%
  • Reputation Power: 10
  • Gaderian barely matters.Gaderian barely matters.
  • Respect: +50
  • Referrals: 3
    • View Profile
Re: Client crashing testing
« Reply #13 on: May 16, 2021, 10:10:44 PM »
0
I will try firing up the same test with a non-auto-update version, but it's too late tonight.

Many of use have suggested that the code is slower with the auto-update in place. No idea how it was really accomplished, but it would make sense to create a table lookup. The table probably has to be reprocessed each time a uoxl swap happens, because we don't know if it is the first time or a subsequent time and we have to initialize all the values to the new client offsets in memory.

Prior to the auto-update, those were all hard coded and set at compile time.

I will be really shocked if all those events can happen that fast together on the older EUO without crashing. EUO isn't crashing, it is the client.

That doesn't mean I don't believe what you said - just I think it isn't so much EUO as client.exe that contains the issue and terminates.
« Last Edit: May 16, 2021, 10:12:24 PM by Gaderian »
"Go ahead ask me: 'Should I use hard waits or timers?'"
You say:"Should I"
Gaderian:"Timers!"
You Say:"use hard waits or timers?"

The serious side of timer use is illustrated here: http://www.scriptuo.com/index.php?topic=12094.msg101926#msg101926

However, every time I go back and look at this [AutoLooter] script, I realize I had wrote it in my zen state of EUO scripting - so it makes my brain hurt.

Offline Gaderian

  • Elite
  • *
  • *
  • Posts: 486
  • Activity:
    0%
  • Reputation Power: 10
  • Gaderian barely matters.Gaderian barely matters.
  • Respect: +50
  • Referrals: 3
    • View Profile
Re: Client crashing testing
« Reply #14 on: May 16, 2021, 10:14:51 PM »
0
I left my test running and went to check on laundry. I fell down the basement steps! So I forgot it was running when I came back.

So I was doing other things for a while now... it is up to cycle 785 without crashing!
"Go ahead ask me: 'Should I use hard waits or timers?'"
You say:"Should I"
Gaderian:"Timers!"
You Say:"use hard waits or timers?"

The serious side of timer use is illustrated here: http://www.scriptuo.com/index.php?topic=12094.msg101926#msg101926

However, every time I go back and look at this [AutoLooter] script, I realize I had wrote it in my zen state of EUO scripting - so it makes my brain hurt.

Tags: