Windower: The Future of Spellcast (3.0 Discussion)

[Spekkio]

I have never used spellcast either. (The funny thing is that I have a decent knowledge of XML, I am just afraid that I am the guy who will get banned for using it.) if it will make the system faster, more efficient, and more responsive, it would be silly to do anything other than 3. FFXI is an old game, but the code is far from optimized; anything that will help efficiency would be a welcome change. And if you simplify how people code their gear, most everyone would be happy. (Of course some people would complain, but the always do.)

And I doubt that you need it, but if you guys need anything from me (mainly game data-wise) feel free to ask.

with sept on spellcast, but i'd be lying if i said i hadn't read and learned about it.

i honestly see #2 as a very practical way to do this, primarily because spellcast files are comprised of 2 different logical elements in my opinion, specifically sets and decisions.

XML is a very simple, approachable language for manipulation and maintenance of data, especially one that binds to a loose hierarchy which 16 slots sure do. a drop dead simple interface could be constructed for programatically generating XML sets in a GUI based application making spellcast set generation less tedious and more approachable.

XML is less suitable, i think, for the issue of decisions. XML is not turing complete, making certain constructs and expressions difficult or impossible to make. For example, if i were using a minstrel's ring and wanted to express the idea of finding a set of +HP gear to equip for my current HP% such that the ring would activate, that would be already a challenging expression to construct in a programming language (knapsack problem and all!) but it's doable for sure. meanwhile, expressing such a construct in XML is nearly impossible to do efficiently, making a scripting language a better choice for control decisions.

[bungiefan]

#3 sounds like it could be the best for having a GUI to manage equipment sets. XML was always very tedious to try to read and decipher logic, so I never wanted to use it with as little time as I had to even be playing the game. It would take me more time that I could be playing to learn to use it.

[dannyl]

#2 sounds cool, I like the customization of it since a lot of this game is becoming more and more situational.

However, #3 sounds ideal if we're entertaining the idea of Change.

But like others have said, some user friendly guide will be needed. A basic template, rules and the do's and don'ts and I'll be set to code.

Looking forward ~

[Ikonic]

I'm in favor of #3, but would it also be possible to have it so that old XMLs could still be ran by those who don't or aren't willing to upgrade to the new system? Also, if XMLs are kept could includes be changed to follow XML guidelines instead of spellcast ones so that data validators would work?

[SephYuyX]

The best thing about new stuff is that you get rid of legacy stuff.
XML is a horrible language and shouldnt be a factor in creating a new structure as it will just interfere.

[arus2001]

I'm in the same boat, still using windower macros bound to my keyboard. I'd definitely take the effort to set up spellcast if it was easier to use/maintain/understand.

I'm still largely similar, hence my initial post. While I don't want to call myself code stupid, I don't know XML, and thus any intricacies of the system. Pair that with a general lack of consolidated info on what to do or even XI-specific conditions that can be accounted for like time, weather, (in)active JAs, mob(s) you're fighting, and so on... it's just stupidly daunting for people not in the know. Ultimately, I feel my macros are as close to spellcast without using it, but there's stuff I simply can't do with it on the fly like wearing WAR gloves with Restraint up or something without actively toggling alias systems I do have in place. And I guess as a perk, I don't have to worry about the game crashing on me post-patches until things are updated. If that's an issue that can be avoided in a new version, even better.

[Yugl]

http://wiki.windower.net/plugins/spellcast

All I used for making spellcast XMLs.

[Xaetica]

From what I can read, most people want option 3. At least take into account the benefit of option 2. Option 2 opens up for easier interoperability with other plugins (like the gear changing one) and other creative things devs like to dream up.

Interoperability always was the goal of XML, not readability, so my vote is for 2.

[Motenten]

I'd be inclined towards 2 due to the flexibility it offers. It should be pretty easy to set up a GUI program to manipulate gear sets (in fact I think someone started on one a while back, but memory is a bit fuzzy) that could be stored as xml files, and then import those files into the "rules" code. And as mentioned, it allows better interoperability with other plugins.

The downside is having to keep two files stored for every job -- the gear sets and the rules. Of course ideally the GUI that lets you manipulate gear sets could also provide a window pane for editing the rules file, and the user doesn't really have to be aware of how many files are being used or where they're stored.

And even if you keep a split of sets vs rules, you still have to have the ability to manipulate gear choices within the rules anyway. If you went with choice 2 it's pretty much just choice 3 with the option to import an xml file in order to pre-populate gear set vars. It would seem that choice 3 could be implemented as a complete superset of choice 2.

[noodles355]

with sept on spellcast, but i'd be lying if i said i hadn't read and learned about it.

i honestly see #2 as a very practical way to do this, primarily because spellcast files are comprised of 2 different logical elements in my opinion, specifically sets and decisions.

XML is a very simple, approachable language for manipulation and maintenance of data, especially one that binds to a loose hierarchy which 16 slots sure do. a drop dead simple interface could be constructed for programatically generating XML sets in a GUI based application making spellcast set generation less tedious and more approachable.

XML is less suitable, i think, for the issue of decisions. XML is not turing complete, making certain constructs and expressions difficult or impossible to make. For example, if i were using a minstrel's ring and wanted to express the idea of finding a set of +HP gear to equip for my current HP% such that the ring would activate, that would be already a challenging expression to construct in a programming language (knapsack problem and all!) but it's doable for sure. meanwhile, expressing such a construct in XML is nearly impossible to do efficiently, making a scripting language a better choice for control decisions.

How is minstrel's ring difficult to work into spellcast? Maybe during leveling where your HP changes each level, but at 99 when your max HP in idle gear is always the same (using vars for different SJs) I don't see how this is an issue. You can make a few different HP down sets depending on subjob, have all Singing skill spells equip that set during precast (using variables to determine which one, based on subjob), and then add a castdelay and standard whatever set during midcast.

Unless I have misunderstood your comment, in which case, apologies.

[VZX01]

My current problem is to generate an elegant solution to ranged weapon locking (between chakram and tathlum) without giving any birth to new gearset. Something like (if I had Aliyat Chakram equipped, then don't swap ammo between Mantis Eye and Mavi Tathlum. If there's something in ammo, then ranged slot swapping shouldn't be allowed). It's hard to make a solution that isn't convoluted in current spellcast XML paradigm.

[Septimus]

How is minstrel's ring difficult to work into spellcast? Maybe during leveling where your HP changes each level, but at 99 when your max HP in idle gear is always the same (using vars for different SJs) I don't see how this is an issue. You can make a few different HP down sets depending on subjob, have all Singing skill spells equip that set during precast (using variables to determine which one, based on subjob), and then add a castdelay and standard whatever set during midcast.

Unless I have misunderstood your comment, in which case, apologies.

The process of setting up different conditions for different sub jobs doesn't exactly sound simple and easy to use.

[drwaffles]

#3 sounds good. I never really got into Spellcast outside of things like day\weather or night\day conditions because I'm the kind of person that would spend more time faffing around with XML's than actually playing the game, and the cumbersomeness of XML compounds that problem hugely. A much more easy-to-use system would be brilliant as I'd love to finally make a complete transition from Windower macros to something more sophisticated, even though they've served me well for many years.

[Nightfyre]

The process of setting up different conditions for different sub jobs doesn't exactly sound simple and easy to use.

I'm not sure if you're joking or simply have some kind of mental block over anything that looks like code (in which case you're evidently far from alone around here), but it would take more time to figure out the HP levels for each subjob than it would to actually write the code. It would literally be one rule and some sets that are largely copy-pasted.

[grevenilvec75]

Ultimately, I feel my macros are as close to spellcast without using it, but there's stuff I simply can't do with it on the fly like wearing WAR gloves with Restraint up or something without actively toggling alias systems I do have in place.

You could probably do that with autoexec.

My current problem is to generate an elegant solution to ranged weapon locking (between chakram and tathlum) without giving any birth to new gearset. Something like (if I had Aliyat Chakram equipped, then don't swap ammo between Mantis Eye and Mavi Tathlum. If there's something in ammo, then ranged slot swapping shouldn't be allowed). It's hard to make a solution that isn't convoluted in current spellcast XML paradigm.

Can't you just check if chakram is equipped, and if it is just lock the range and ammo slots?

[Spekkio]

the minstrel's ring example was just something i grabbed quickly to exemplify something that doesn't fit well into a declarative programming methodology as XML is generally used for.

changes in subjobs and buffs affect max HP in various ways and current HP is not fixed, either. if i have already received damage, i need to swap out less equips to reach the activation level which may enable me to not remove gear that would cull my max MP below my current MP, for example. Under these circumstances there are many gear configurations that are indeed functional, but likely fewer that are optimal.

expressing the set of swaps needed to ALWAYS make it work is a simple task for the most part. figure out your max HP on various subjobs and you're basically there. something that can make dynamic decisions to make the best choice about which pieces in this case i need to put on is significantly more difficult under the current construct. this difference between sufficient and optimal was what i was trying to express previously, though obviously failed miserably to convey.

was this the best example? probably not. i'm sure i could have come up with something that would be easier to understand while at the same time much better exemplifying how adding procedural programming capability to our options for expression would increase the ability and ease of designing more interesting and complex decision making processes. it was merely the first case that hit my mind as a career brd that demonstrated a clear challenge to express under the current language constructs.

ultimately, i'm just musing about my thoughts on the matter. given that i neither develop, nor even use spellcast, i'm not exactly in a position to speak authoritatively on it. my only goal is to share the experiences i've had helping to answer other's questions and what i've bumped my head against. if i'm wrong, so be it, it just seems to me that a much simpler construct for an XML layout would be very easy to understand. gearsets are nothing more than a database row with at least 17 columns (identifier and 16 gear slots) and allows null. given that access performance takes a backseat to ease of user manipulation, XML seems like a practical choice.

[Esvedium]

Can't you just check if chakram is equipped, and if it is just lock the range and ammo slots?

Yes.

[Masamune]

Option 3.

[Uubu]

option 3, would be assume to have all the include files of the people know how to program, then be able to call functions as needed in a simpler method. I just came back to ff after a year or so and have had to give an overhaul to my sc files..

some of which are not working as they should even they are exact replicas of other sc files with gearsets modified.. (ie my war spellcast 100% working, copied to BST doesnt work with the only difference in gear but if/rules are the same)

[NynJa]

My current problem is to generate an elegant solution to ranged weapon locking (between chakram and tathlum) without giving any birth to new gearset. Something like (if I had Aliyat Chakram equipped, then don't swap ammo between Mantis Eye and Mavi Tathlum. If there's something in ammo, then ranged slot swapping shouldn't be allowed). It's hard to make a solution that isn't convoluted in current spellcast XML paradigm.

<if EquipRange="Ungur Boomerang|Raider's Bmrng.|Snakeeye">
<action type="equip" when="engaged|idle|precast|aftercast|midcast">
<range lock="yes"></range>
<ammo lock="yes" />
</action>
</if>


Doesnt seem that difficult.