<3
On the scholar note, does anyone have a current scholar .xml they wouldn't mind sharing?
Actually, I'd say thf and pld are two of the most complicated to get right using the templates. Or perhaps just most complicated period. I'm working on converting both of them in mine right now, and it's not easy.
Yugl, I took a 5 month break from the game and switched from a pc to a laptop so I need Xmls for all my jobs again (12 jobs 90+). Anyway I'm trying to use your drg, mnk, and blu xmls and the all have the same error message when I put them thru the notepad++ xml checker. Xml parsing error on the last line and premature end of data in tag spellcast line 2. I have your include file as well. What am I doing wrong? am I suppose to combine the include with the job xml or what? I use to have the hang of this but I'm a bit rusty.
Name the include file "Yugl-Include" without the quotes and it should be a separate XML (Same folder as all the other spellcast stuff though). If you're doing a "Run" check, the issue tends to be with the use of three dashes as opposed to two dashes. BLU and RDM need a regular include; by that, I just mean a file called "include" without the quotes. That's because I've been too lazy to change lines like
<xi:include href="include.xml" xpointer="//include[@name='CleanTransportation']/*" />
to
<xi:include href="Yugl-Include.xml" xpointer="//include[@name='CleanTransportation']/*" />
I should be getting to a point where I can work on XMLs a bit, so I'll try to convert the BLU and RDM XMLs then. If people give me an answer as to whether they want to add Restraint/Berserk/Aggressor/Blood Rage as separate sets (You'll end up having a HUGE number of sets; you can minimize this by not using some of these as variables) or if they want them as variables, I can proceed with a WAR or w/e XML. I would prefer a SCH XML for myself, but holyshit SCH is a logistics terror, so I'll need to reserve that for an even greater break. As a reminder:
- Set method: TP-GA-HASTE => TP-GA-HASTE-RES-BERSERK-BR
Pros: More customizable set since you can decide to use one setup if using TP-Haste with berserk up and a completely different set if using TP-PDT with Berserk up.
Cons: For each buff you add past "HASTE", you multiply the number of TP sets by 2.
- Variable method: TP-GA-HASTE => TP-GA-HASTE|$RES|$BERSERK|$BR
Pros: Very simple to construct since each buff would only add 1 set
Cons: The simplicity of the design is because it's universal. Since it's universal, there's no way to distinguish having TP-HASTE + BR from TP-PDT + BR, which means you'll use the same BR set for both. So lets say you use Restraint and that uses the AF3+2 hands, but you make up for the haste by adding Haste to the back (Hypothetical; remember that!). If you were to use TP-PDT and TP-PDT uses a PDT backpiece, BR's Haste piece would override that.
You can mix these sets as well; for example, TP-HASTE-Berserk|Blood Rage|Restraint. Whichever you choose, be specific as to which JAs should be considered a "set" and which JAs should be considered "variables."
I decided to get a sorc ring recently, using Aikar BLM.xml template.
This template simply uses a MinusHP set at precast to lower yur current HP to < 76%, before using FullDamage set @ Midcast.
But the MinusHP set has a problem as it is making me nuking still in MinusHP set instead of the expected FullDamage set.
I think this problem werenot occuring before Elemental Celerity got implemented: i think now Midcast occurs AFTER aftercast lol...
In other terms, spellcast calculates MidcastDelay based on non-reduced casting time.
The problem is that Elemental Celerity hasnot been very clearly tested so i don't know which % to reduce midcastdelay properly ?
Any idea to solve this issue please ?
That doesn't sound like an issue with Elemental Celerity. In instances where you have tremendous fast cast, you'll typically see precast => midcast => spell goes up prematurely => huge delay => aftercast. Elemental Celerity estimates have been done (Random Facts Thread, I think), but there haven't been any indication of EC's place within the equation (FC, Book, or separate term).
The issue you're likely experiencing (Cannot confirm unless I see the XML) is either due to 1) SC not picking up on the midcast change in time or 2) an issue where SC going from X > R > X rapidly makes SC think that you still have X equipped even when R is equipped such that SC never changes you from R to X.
You cannot reduce midcastdelay; you can only increase the delay. If the issue is (1) or (2), increasing midcast delay may actually help for spells with greater cast time.
Yes the issue were occuring when im on /rdm... i didnot test on /whm.
My xml is basically Aikar template unmodified lol (except gears ofc) which doesnot touch Micastdelay at all.
But considering at the time he wrote this, i think his xml template doesnot account for nowadays BOTH high FastCast + ElementalCelerity, which makes SC behaves like this:
Precast change gears (i see my Zenith crown instead of Goetia petasos) > casting animation starts > Spell goes off around 60-70% castingtime > double gearswaps (i think Midcast gears AND aftercast gears swapping at same time).
In other words, i'll just fix your sentence:
This when casting relatively long casting time spells like tier5 or AMs which gets their castintime drastically reduced.Originally Posted by Yugl
So i'm VERY surprised you suggesting to actually INCREASE Midcastdelay ?? I don't understand :s
EDIT: i found on windower wiki MidcastDelay description: it's a fixed delay=0.6 by default from starting casting spell. In comparison, aftercast is dynamic and is reduced properly with fastcast etc... Also i don't find any mention saying can't reduce MidCastDelay...
updated my war xml! nice thing there! now need to find out what r best sets for me!
btw add to your autoexec files these line for the war xml:
Spoiler: show
ops good now!
The command for delay is <midcastdelay delay="X" />, but X has to be a positive or neutral number that denotes the amount of seconds you want to add to the delay. The reason I mentioned increasing midcast delay is because you can change the 0.6s delay to a larger delay. The benefit of increasing the delay is that this gives SC enough time to recognize that you have not equipped X in the last part of the sequence X > R > X. Another alternative if cast delay so that you'll equip the precast gear, wait a fraction of a second, and then begin to cast.
Edit: Adding AutoExec lines, but be sure to change Restrait => Restraint.
Yugl, I changed the file to Yugl-Include.Xml, changed the include in rdm and blu to Yugl-Include, I checked the dashes they all have --- instead of --. Actually every Xml of yours I tried is getting the same exact error message. I'm using notepad ++ xml tools plugin and hitting the check Xml syntax option. Blu, rdm, mnk, yugl-include.xml, yugl-generaltemplate all have same error message. Premature end of data in tag spellcast line 2. The autoexec xml has premature end of data in tag autoexec line 1. What do I need to do exactly to fix these.
I'm about to log, so I'll check in tomorrow, but a few stuff to ask/check:
1. Is the issue just with the notepad++ plugin or is it not working in game?
2. You can do a replace and replace all <!--- with <!-- and all ---> with --> to see if that satisfies the plugin issue
3. Did you update resources?
4. Anyone else getting this error?
ok i'll give those things a shot. I have not tried in-game yet, i've just been running all these xmls thru the editor, pretty sure I updated resources earlier today as well.
Yes i know the midcast delay= command, and understood what you meant by allowing SC enough time to recognize properly R from X set... but this applies only if aftercast = castingtime (like for pld cure cheat adding midcastdelay+1.3 solves the issue, since usually not enough fastcast to reduce significantly aftercast to make this fix not work).
In the case of BLM/rdm on other hand aftercast is drastically reduced with long casting time spells. That ends up the defaulted midcast occuring at same time (or worse after) AfterCast.
So.. yea only fix i would say is like you suggested: add a CastDelay = reduced aftercast amount... which destroys the whole point of using FastCast + ElementalCelerity ...
Guess i'll just sell my Sorc Ring -.-