Reloading UI Mid-Combat, In Raid

Kenshone · 03-16-11, 10:56 AM

Does anyone know what causes issues with certain addons if you reload mid-combat, in a raid?

Iirc, using Vuhdo back when it first came out in WotlK, if you were d/ced in the middle of a boss fight and reloaded, the raid frames would all come out wrong for some strange reason.

I am having this same issue with my personal addon...so is there something I need to know about game events, or combat log events, when reloading in the middle of combat? Thanks in advance!

SDPhantom · 03-16-11, 11:29 AM

The first thing that comes to mind is if you're reloading in combat, secure frames are unable to be changed or even set up due to the game being in combat lockdown. The only thing I can think of to correct this is have your addon try to detect if you're already in combat. If so, wait until you exit combat before attempting to set up your frames. If you're waiting for a specific event before loading your frames, you might try moving it to the base of your code so it runs before ADDON_LOADED fires. There might be a time restriction on how long after a reload the game client will allow you to set up your frames.

Kenshone · 03-16-11, 11:56 AM

Hm yeah, I'll definitely work on checking if I'm already in combat when I reload.

Vuhdo fixed the said problem in their recent versions it seems. You can reload mid-combat in raid, and all the frames will be generated with accurate data.

If anyone knows exactly how they fixed it, please do share!

Nobgul · 03-16-11, 12:22 PM

The same as healbot. They save strings of data to a macro, which is some code dump. Macro's are written on the fly and stored via the server. This is how they save the data.

Kenshone · 03-16-11, 01:04 PM

So they basically store every bit of data in a savedvariable and load those savedvariables if they reconnect in combat.

Crissa · 03-16-11, 01:07 PM

I do know that such a thing is usually death, even in plain Blizzard frames.

-Crissa

Nobgul · 03-16-11, 02:25 PM

You can only write to saved vars on reload or on quit. If your client disconnects or crashes it will not write to the saved vars. This is why they write to the macros. As i said before macros are stored server side and when written are saved.

Kenshone · 03-16-11, 02:37 PM

Are we talking about conventional macros like the menu that opens up when you type "/macro?" or are there "hidden macros" that we can save to the server?

Nobgul · 03-16-11, 02:38 PM

Yes reg macro's Character specific gets written to the server at run time. Meaning if you use code to create the macro then alt-f4 out of the game. when you come back in then the macro will still be there.

Kenshone · 03-16-11, 03:15 PM

It just doesn't seem you can store sufficient data in character-specific macros, especially if you're occupying all slots already.

Nobgul · 03-16-11, 05:47 PM

If you are occupying all slots then you cannot. If you download healbot and look at the last tab there is a option. They call it Crash Protection or something similar. It says that you have to have 2 macro slots open in order for it to work. If you enable the option and you do not have sufficient macro space it will warn you. Technically you could store a large amount of data in the macro's if you are willing to code the system to encode / decode the data. I am almost sure that each macro can hold 255 letters/numbers. That give a lot of room to store things.
ie: a data string of HgyfRDFtHgFtg5643t^%fG may look unformatted but if you create a system then each character could represent something. It really comes down to how much time you want to spend to write the code / decode system.
But that is a whole other story. For what we are talking about here, yes there is enough room to store the data. I have crashed in full 40 man raids with healbot and came back in and kept healing.

**Seerah** · 03-16-11, 07:22 PM

That shouldn't be necessary if the addon is coded correctly.

Nobgul · 03-16-11, 08:20 PM

But for secure frames it is, as they cannot be redrawn while in combat. They are in "Lock Down"

**Seerah** · 03-16-11, 08:24 PM

Yes, but iirc (and as I believe was mentioned above), there is a window during which you can create your frames before the client gets the info from the server that you are in combat.

Morsker · 03-17-11, 07:44 AM

The macro storage is for real game crashes where savedvars won't be written. It's not quite the same issue as initializing in combat, and the macros actually can't be updated in combat, but it could be used to help with with the issue.

The issue is that some part of the raid roster isn't available immediately on a login, so even though the UI has has the option to create secure frames immediately on login before it goes into combat, it doesn't have the information it needs at that point, and can't do it. The client holds onto the raid roster information between /reloads though, so if you /reload in combat the information will be available the second time, and the frames will setup correctly. I don't know exactly what some mods do to workaround this limitation (to recover correctly on a login in-combat, without needing you to /reload after the login), but storing some aspect of the raid roster in saved vars or a macro is probably it.

Grimsin · 03-18-11, 01:16 PM

I think im having a similar problem as far as data not available about the party when you reload in a party/raid . My post here though is to point out that secure code can be used to move frames when you reload in combat and unless a frame you are moving is a blizzard frame tied into the blizzard frame management system, combat should have no effect on its sizing or positioning.

My problem with my own interface which i think has to do with party data not available right off the bat after a reload
http://www.wowinterface.com/forums/s...234#post232234