Reply
 
Thread Tools Display Modes
Old 07-21-12, 06:41 AM   #121
Haleth
This Space For Rent
 
Haleth's Avatar
WoWInterface Super Mod
Featured
Join Date: Sep 2008
Posts: 1,151
Originally Posted by Vladinator View Post
Hehe, I'll try clear up any confusion or misunderstanding to my earlier post. :P

What I meant is, since there are signs of lua code running (pet battles) that isn't exported as an addon, meaning we can't see the sources, meaning it makes things just more complicated and busywork to figure out how that particular addons works, what events it uses, API, e.g.

One may say that's a good thing to "bake" all addons into the binary and get rid of all the Blizzard_* addons, but on the other hand if that happens, how can we explore the sources of their LOD addons and learn from them? I think it's an important aspect of both learning how to code for the game, and getting an idea how things work around here.

It's early to say though, they might make the baked addons exportable too, it may be that they just haven't made the export feature export this new type of lua code, so it's no biggie if they fix this for retail release.

I only dislike the idea having the sources completely unavailable and having us guess on API changes and how their addons work. I didn't mean to sound like "they are doing it right now", just saying if they are...

Just a side note, I personally don't see how baking all the Blizzard_* addons would make it any better. Please DO enlighten me though on what you thought!
Could you give an example of this? There has always been lua code running out of the Blizzard_* addons, namely in the FrameXML (and on the login screen, GlueXML etc) - but I take it that's not what you mean.

Personally though I simply don't like the mess of all the Blizzard_* folders in my addons, just makes it longer to scroll through and there's nothing you can do with them anyway. Better to just export it all when you need it.

@ Strife[CUK]; Tried this, still crashes from the GetRegions() function and slash commands.

Last edited by Haleth : 07-21-12 at 06:44 AM.
Haleth is offline   Reply With Quote
Old 07-21-12, 07:23 AM   #122
Ketho
A Molten Giant
 
Ketho's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2010
Posts: 539
Originally Posted by Haleth View Post
Personally though I simply don't like the mess of all the Blizzard_* folders in my addons, just makes it longer to scroll through and there's nothing you can do with them anyway. Better to just export it all when you need it.
I personally think a few of the pros are the LoadOnDemand/Dependencies functionality, and the possibility to disable them through DisableAddOn (e.g. Blizzard_CompactRaidFrames)
Ketho is offline   Reply With Quote
Old 07-21-12, 07:30 AM   #123
Vlad
A Molten Giant
 
Vlad's Avatar
AddOn Author - Click to view addons
Join Date: Dec 2005
Posts: 741
Originally Posted by Haleth View Post
Could you give an example of this? There has always been lua code running out of the Blizzard_* addons, namely in the FrameXML (and on the login screen, GlueXML etc) - but I take it that's not what you mean.
No, this is new. The problem is I only saw behind the scenes when pet battles fired lua errors, these were not a part of the default interface, like FrameXML, GlueXML and so forth. There was no source file, only variables (and they were nowhere to be found in the current interface folder either). Now they seem to be fixed, and I have no screenshots, and I can't find any notes containing these specific errors. So all I can say is that it's something new they are doing. I was hoping someone else also played beta and saw these errors during pet battles, am I alone here noticing this?

Originally Posted by Haleth View Post
Personally though I simply don't like the mess of all the Blizzard_* folders in my addons, just makes it longer to scroll through and there's nothing you can do with them anyway. Better to just export it all when you need it.
I agree, but imagine a WoW where all the lua code is baked and you don't have access to anything, except what you can piece together yourself. We would survive, but it would make keeping API documentation a bit harder and more time consuming than it is now, since now we have access to examples on how the API is used (Blizzards code).

A concrete example of code we can't access is nameplates, I noticed a lot of the "<small-letter-prefix>Nameplates" addons use the same framework basically, because someone did the work to figure out how to alter how they look, and now most just use their addon as base and modify it a little. I guess it would be more unique coded addons if just we'd have access to the lua sources instead. Nameplates are probably not in clean lua, probably C or something, so I understand, but I hope they don't make more of their addons into this format since it doesn't help us (modders) at all. :P

Last edited by Vlad : 07-21-12 at 07:47 AM.
Vlad is offline   Reply With Quote
Old 07-21-12, 07:41 AM   #124
Meorawr
A Chromatic Dragonspawn
AddOn Author - Click to view addons
Join Date: Nov 2010
Posts: 193
My guess would be that the pet battle code and anything else they're handling via lua is done in an entirely seperate lua state with a much lower-level set of API functions at hand to them, so really exporting those files would be quite pointless. We'd be able to see what they're doing to a point, and learn how it works internally, but we wouldn't be able to really replicate it in our own addons simply because we don't have the full power that they do.

In addition it's all probably compiled into bytecode and embedded somewhere, so they'd either need to not do that or to decompile it during extraction, both of which I'm sure they're not interested in doing (time/effort for the eventual reward aren't worth it).

As for nameplates, I'm sure they're entirely in C. Call it a hunch

Last edited by Meorawr : 07-21-12 at 07:45 AM.
Meorawr is offline   Reply With Quote
Old 07-21-12, 08:04 AM   #125
Phanx
A Pyroguard Emberseer
 
Phanx's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2006
Posts: 3,675
Originally Posted by Lombra View Post
The old/current IsSpellKnown had a lot of "problems" with not recognising known spells. Namely a lot of spell IDs extracted from a combat log event were different than the ID of the same spell in your spell book, the latter of which worked with IsSpellKnown, while the combat log event did not. I've had to make a lot of special cases because of this. As far as I understand this function is now replaced with IsPlayerSpell.. has anyone noticed if this one is at all improved in this regard?
Currently, IsPlayerSpell is only used in ShardBar.lua to do stuff like "only show the shard bar if you're Affliction spec AND you know Soulburn". According to the Wowpedia docs its intended use is to check "does the player know this OR a spell that replaces this?", and should be used with the ID of the base spell, not the spell that replaces it.

So, for a shaman you should query the ID for Cleanse Spirit, not Purify Spirit (PS replaces CS for resto), and for a monk you should query Roll, not Chi Torpedo.

I'm not sure what the recommended API for determining whether the player has a particular upgrade is (eg. has the monk replaced Roll with Chi Torpedo?) or figuring out the associations. Probably you'll just have to keep doing it by hand if you need to know the specifics.
__________________
Author/maintainer of Grid, PhanxChat, ShieldsUp, and many more.
Troubleshoot an addonTurn any code into an addonMore addon resources
Need help with your code? Post all of your actual code! Attach or paste your files.
Please don’t PM me about addon bugs or code questions. Post a comment or forum thread instead!
Phanx is offline   Reply With Quote
Old 07-21-12, 08:40 AM   #126
p3lim
Mmmrrrggglll
 
p3lim's Avatar
AddOn Author - Click to view addons
Join Date: Feb 2007
Posts: 1,143
If anyone is still working their actionbar addons to work with the new possess changes,
the only difference is that you have to use [vehicleui] instead of [bonusbar:5], and the
buttons are ranged from id 133 and beyond instead of id 121 and beyond.
p3lim is offline   Reply With Quote
Old 07-21-12, 09:01 AM   #127
Maul
Ion Engines, Engage!
 
Maul's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2005
Posts: 401
To clarify a bit, there are few override bar situations that are not triggered by [vehicleui]

One example is the quest Mental Training: Speaking the Truth to Power

These override bars are not considered vehicles. They used to be triggered by [bonusbar:5], but now they are not. Also, these bars use the action ID's 157-162, not the new 133-138 range.

I have a character with that quest active just for testing purposes. Right now, on live, [bonusbar:5] works fine for it. On the beta, I have found no macro conditional that will fire when this specific type of override bar is shown.
__________________

Twitter: @IonMaul | Windows Live: trinityui@live.com | Google Talk: trinityui@gmail.com

Last edited by Maul : 07-21-12 at 10:01 AM.
Maul is offline   Reply With Quote
Old 07-21-12, 09:21 AM   #128
Haleth
This Space For Rent
 
Haleth's Avatar
WoWInterface Super Mod
Featured
Join Date: Sep 2008
Posts: 1,151
As far as I'm aware - correct me if I'm wrong - the bar used here is the possess bar. As for the macro condition for it, there is none. It was requested (as posted on the previous page), along with the pet battle UI one. They responded saying they will add one for pet battles, but they made no mention of a possess bar condition.

Edit: Just noticed you posted there, derp. Link of the topic is a bit unnecessary then.

Last edited by Haleth : 07-21-12 at 09:24 AM.
Haleth is offline   Reply With Quote
Old 07-21-12, 09:54 AM   #129
p3lim
Mmmrrrggglll
 
p3lim's Avatar
AddOn Author - Click to view addons
Join Date: Feb 2007
Posts: 1,143
Originally Posted by Maul View Post
One example is the quest Mental Training: Speaking the Truth to Power

These override bars are not considered vehicles. They used to be triggered by [bonusbar:5], but now they are not. Also, these bars use the action ID's 157-162, not the new 133-138 range.

I have a character with that quest active just for testing purposed. Right now, on live, [bonusbar:5] works fine for it. On the beta, I have found no macro conditional that will fire when this specific type of override bar is shown.
For testing purposes, since you are on the quest, test every possibility of bar:1-6 and stance:1-N, just to see if any of those would work.
Also do bonusbar:N, you never know.

As for the thread linked, I'd post there if I had access.

Last edited by p3lim : 07-21-12 at 09:58 AM.
p3lim is offline   Reply With Quote
Old 07-21-12, 10:03 AM   #130
Maul
Ion Engines, Engage!
 
Maul's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2005
Posts: 401
Originally Posted by p3lim View Post
For testing purposes, since you are on the quest, test every possibility of bar:1-6 and stance:1-N, just to see if any of those would work.
Also do bonusbar:N, you never know.
I have done that, and even more
__________________

Twitter: @IonMaul | Windows Live: trinityui@live.com | Google Talk: trinityui@gmail.com
Maul is offline   Reply With Quote
Old 07-21-12, 10:32 AM   #131
p3lim
Mmmrrrggglll
 
p3lim's Avatar
AddOn Author - Click to view addons
Join Date: Feb 2007
Posts: 1,143
Meh, worth a shot
p3lim is offline   Reply With Quote
Old 07-21-12, 10:34 AM   #132
TSquared
Big Daddy!
Join Date: May 2008
Posts: 504
Originally Posted by Vladinator View Post
No, this is new. The problem is I only saw behind the scenes when pet battles fired lua errors, these were not a part of the default interface, like FrameXML, GlueXML and so forth. There was no source file, only variables (and they were nowhere to be found in the current interface folder either). Now they seem to be fixed, and I have no screenshots, and I can't find any notes containing these specific errors. So all I can say is that it's something new they are doing. I was hoping someone else also played beta and saw these errors during pet battles, am I alone here noticing this?
OK, I think I know the confusion. The errors you saw were in the pat battle spell scripts as Meorawr mentioned. Not the pet battle UI. WoW uses lua for all scripting, not just UI. In fact lua was used for the UI after it was decided to use it for spell scripts. Pet battles is different in that the spell scripts are on the client and not the server, but it's not UI code and certainly shouldn't be exposed to outside "playing".

It's true that some UI is on the c side. But those are rare cases. Usually from the early days when WoW was trying to hide data from players (item/spell tooltips), or do to not want to expose too much position information to help fight bots (namplates, floating combat text).

On a slightly separate note: the blizzard addons in the addon UI in the glue screens is just a development issue. New features always show up there during PTR or Beta testing. It will be fixed before launch.
TSquared is offline   Reply With Quote
Old 07-21-12, 10:50 AM   #133
Haleth
This Space For Rent
 
Haleth's Avatar
WoWInterface Super Mod
Featured
Join Date: Sep 2008
Posts: 1,151
Pet battle spell scripts are client side? Is that not very insecure? The reason those global cooldown hacks were possible back in the days is because the global cooldown was client-imposed, until they changed it as a response to the hacks.
Haleth is offline   Reply With Quote
Old 07-21-12, 10:54 AM   #134
Meorawr
A Chromatic Dragonspawn
AddOn Author - Click to view addons
Join Date: Nov 2010
Posts: 193
I think the way it works is the scripts are client side just to facilitate the playing-out of a battle, the server still (hopefully) validates everything, and communicates only the bare-bones of "what just happened" to each client which then use the scripts to process the visual-side of things on the client (such as weather mechanics, etc).

I think a similar comparison would be with SC2 replays, which I think are just re-enacted out on the client. Might be wrong though.

Technically this could cause two clients to become out of sync if one was using modified scripts, so for instance one end might display a pet as having 200 more health than it should, but as long as the server doesn't trust the clients in any way then all's good. I hope.

Meanwhile, at Blizzard...

Last edited by Meorawr : 07-21-12 at 11:10 AM.
Meorawr is offline   Reply With Quote
Old 07-21-12, 12:38 PM   #135
SDPhantom
A Molten Giant
 
SDPhantom's Avatar
AddOn Author - Click to view addons
Join Date: Jul 2006
Posts: 933
Originally Posted by Meorawr View Post
A badly Photoshop'd image? I don't get it.
__________________
"All I want is a pretty girl, a decent meal, and the right to shoot lightning at fools."
-Anders (Dragon Age: Origins - Awakening)
SDPhantom is offline   Reply With Quote
Old 07-21-12, 12:47 PM   #136
Vlad
A Molten Giant
 
Vlad's Avatar
AddOn Author - Click to view addons
Join Date: Dec 2005
Posts: 741
I agree with you TSquared and Meorawr.

About the battles themselves, this is how I see it; the server receives the action you wish to take and returns the client the outcome, as soon as you have sent your action an event fires to tell the client the result. This is why you can win a pet and get the quest completion screen at the start of the round and not have to wait for the end, because the game already was told what happened.

So it's safe, just client side visuals and such are handled by the client. In reality you can have a "skip animations" option to turn off all visuals for pet battles and just tell you the results as soon as they are received from the server, seconds after you have chosen your action.

Last edited by Vlad : 07-21-12 at 12:56 PM.
Vlad is offline   Reply With Quote
Old 07-21-12, 11:05 PM   #137
p3lim
Mmmrrrggglll
 
p3lim's Avatar
AddOn Author - Click to view addons
Join Date: Feb 2007
Posts: 1,143
Maul, using Mind Control/Dominate Mind and the alike also counts as possess.

According to those tests, the buttons on the actual actionbar were still 133+, though the two buttons that replaces the stancebar are the actual buttons that is counted as the possess buttons by the blizzard ui.

So, question in my head was this: Why have two elements for 1 bar?
Easy enough, the StanceBar handles anything "default", anything that is considered part of a class, like druid forms, warrior stances, shadowform etc, while the possessbar handles anything else (mostly exit buttons from a possessive state).

So what we need [possess] or something alike it for is just to know when to swap the buttons replaced on the main menu bar securely. Anything non-secure can be detected with UPDATE_POSSESS_BAR and IsPossessBarVisible().

You can quote me on that for the post on the US forums, as I can't post there myself.
p3lim is offline   Reply With Quote
Old 07-22-12, 06:30 AM   #138
zork
A Pyroguard Emberseer
 
zork's Avatar
AddOn Author - Click to view addons
Join Date: Jul 2008
Posts: 1,289
I think p3lim is right on the actionbar front. I cannot say this for sure because I'm not creating actionbar buttons on my own, I use the default buttons. But I think so.

The possessbar itself is just a two button frame replacing the stancebar. Showing two buttons (current possess spell and leave button). It has nothing to do with the actionbar buttons. The leave button triggers VehicleExit() onClick.

Two answer p3lims question. I think they added it because the posses buttons may not have an actionbutton spell to exit the possess state and the possess may not trigger the override bar (vehicle ui) thus no exit button will spawn.

You can check the bar index by using the new index functions.

Code:
return GetVehicleBarIndex()
return GetOverrideBarIndex()
return GetTempShapeshiftBarIndex()
return GetBonusBarIndex()
return GetActionBarPage()
If GetBonusBarIndex() is returning any value between 7 and 11 ... that would be a problem though.

Vehiclebar = 12
TempShapeshift = 13
OverrideBar = 14
ActionBarPages = 1-6

See: http://www.wowinterface.com/forums/s...83&postcount=6

p.s. Good to know that the petbattle ui state is in. I can now finish my macro conditions for the state driver.
__________________
| Simple is beautiful.
| Blog | Roth UI | Roth UI FAQ | GoogleCode | Zork | Guild | zorker.de

"I wonder what the non-pathetic people are doing tonight?" - Rajesh Koothrappali (The Big Bang Theory)

Last edited by zork : 07-22-12 at 06:38 AM.
zork is offline   Reply With Quote
Old 07-22-12, 09:06 AM   #139
Maul
Ion Engines, Engage!
 
Maul's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2005
Posts: 401
Originally Posted by p3lim View Post
Maul, using Mind Control/Dominate Mind and the alike also counts as possess.

According to those tests, the buttons on the actual actionbar were still 133+, though the two buttons that replaces the stancebar are the actual buttons that is counted as the possess buttons by the blizzard ui.
I am not too concerned about Dominate Mind type of actions, as they seem to now be considered [pet] and the pet action ID's 1-10 properly reflect abilities using Dominate Mind. I can live with that as a solution.

My primary concern is the "non-vehicle" vehicle bars (I used to call them "possess" states because that is how they seem to behave, that a character would "possess" an NPC or object rather than mount a vehicle). This bar would be better called the "Alt Player Action Bar" based on the fact that their textures are in the "PLAYERACTIONBARALT" art folder. Which reminds me, this state is the same used by the darkmoon faire. Since [bonusbar:5] no longer seems valid, the darkmoon alt action bars most likely also do not have any macro conditional that an addon can react to. I will have to remember to test that the next time the DMF is up.

So the new macro conditional I am seeking would probably be better called [actionbaralt] or something along those lines, though I think [possess] or [possessui] works just as well, as the character is possessing something for the time being (like a DMF tonk)

And, from my tests, these alternate action bars on the beta so far use the higher action ID range I indicated previously (157-162).

Originally Posted by p3lim View Post
So what we need [possess] or something alike it for is just to know when to swap the buttons replaced on the main menu bar securely. Anything non-secure can be detected with UPDATE_POSSESS_BAR and IsPossessBarVisible().
Exactly, and for my addon, I need to be able to securely assign the proper action ID range based on what is happening. So far, I can do that for everything save for these "possess"/"alt action bar" states and the extra action button (but that has a work-a-round, though I would prefer a direct macro conditional for knowing when the extra button is active or not)
__________________

Twitter: @IonMaul | Windows Live: trinityui@live.com | Google Talk: trinityui@gmail.com

Last edited by Maul : 07-22-12 at 09:09 AM.
Maul is offline   Reply With Quote
Old 07-22-12, 01:16 PM   #140
zork
A Pyroguard Emberseer
 
zork's Avatar
AddOn Author - Click to view addons
Join Date: Jul 2008
Posts: 1,289
Enabling the taintlog crashes the game client. At least for me.
__________________
| Simple is beautiful.
| Blog | Roth UI | Roth UI FAQ | GoogleCode | Zork | Guild | zorker.de

"I wonder what the non-pathetic people are doing tonight?" - Rajesh Koothrappali (The Big Bang Theory)
zork is offline   Reply With Quote
Reply

Go BackWoWInterface » MoP Beta » MoP Beta API and Graphics Changes » Beta API discussion

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off