Introducing Radsources! Updates to your resources XML~

[Yugl]

Radec (Yes, BG Radec) has created new resource XMLs for plugins. These resources fix the blue magic information and include contributions from Motenten (Additional trigger spells) and myself. He also made various fixes such as setting WS to 100 TP cost such that %TPCost will reflect (100) instead of (-1) for WS.

https://github.com/radectheblm/Radsources

A .rar and individual files are available. There is a Readme file included and, if wanted, I can include pictures for installation.

Enjoy~

[Subadai]

Does this work for all plugins? Recast was the one that seemed to get out-of-date the most often for me. Thanks for putting this together, will try it out later today.

[Yugl]

He has the individual and a total resources XML in there, so whichever one recast uses should be covered.

[Radec]

Yes, this will work for recast - it uses the resources.xml file rather than the spells.xml, abils.xml, items_*.xml files which windower auto-updates.

Edit: Quick question for people using statustimer: Which, if any, of these timers do you find useful:

Visitant
Atma
Abyssea-Stat Boost (Which are different from gain-*, boost-*, absorb-* boosts)
Copy Image
Level Restriction (Think formerly in Pso'xja)
SJ Restriction (Royal Decree, CoP Dynamis)
Sublimation: Complete
Dedication
Signet/Sanction/Sigil
Battlefield (BCNM)
Besieged
Salvage Restrictions
Allied Tags
Level Sync
Confrontation (Dynamis Boss status)
Light/Dark Arts, Addendum Black/White
Finishing Move1-5
Solace/Misery
Composure
<Avatar's> Favor - the effect, not the buff on the smn themself
Prowess

Personally I use at some point or another, all but
Copy Image
Finishing Move
Atma
Abyssea-Stat buff

I'm asking to get an idea - are these timers used? Or should they be, by default, set not to appear.

[Innuendo]

Edit: Quick question for people using statustimer: Which, if any, of these timers do you find useful:


I'm asking to get an idea - are these timers used? Or should they be, by default, set not to appear.

These ones:
Visitant
Level Restriction (Think formerly in Pso'xja)
Dedication
Battlefield (BCNM)
Besieged
Salvage Restrictions
Allied Tags
Confrontation (Dynamis Boss status)

[cdgreg]

As usual, Radec is the man.

[Radec]

Visitant
Level Restriction (Think formerly in Pso'xja)
Dedication
Battlefield (BCNM)
Besieged
Salvage Restrictions
Allied Tags
Confrontation (Dynamis Boss status)

Small update, all to status durations. Left in timers for these, removed everything else on the first list.

Added StatusData.txt example files if you want to modify your timers further.

Link is the same, in sig or OP.

[Khamsin]

What about assigning the appropriate element to elemental WSs (for using obis like korin for cataclysm, checking against day for certain equips, etc.)?

[Radec]

I can read what the element of the WS is to a certain extent, the dats show the icon to be used with it (Vorpal and Shining Blade are List-Icon-ID 46, Flat Blade 44, RLB 40), but that doesn't always correspond with it being elemental (Shoulder Tackle, Smash Axe show as thunder(44) but are physical).

As much as possible I'm trying to stay within the bounds of either existing information in the dats(Cost, Recast, Casttime), or existing functionality (durations had to be set up on a per status basis).

Even if I was going to put in the effort to type out every ws element and chain property (hint: not unless very bored) I don't believe spellcast has the functionality to handle both - I can't just add a new field to the resources and have spellcast pick it up (Yugl and I have tried this for durations on buffs, in a different way than statustimer works. if spell = refresh wait %duration echo recast refresh, for example) to differentiate between element and SC element. Also, I'm unsure if all fields would accept multiple values like validtargets does - Element="Light, Wind, Fire, Thunder" - might only register when it matches completely vs matching only one of the elements.

If you think of a way I'd be happy to hear it, that's definitely useful - the rest of the project is written in C#, so rather than typing out all the changes to the abils.xml, I'd prefer a function like..

private string WSElement (string abilName, int listIconID)
{
do things
return element;
}

These are the things I "know" from the dats for any given weaponskill:

Name
Index
Type (they're all "weaponskill")
List-Icon-ID - a number that matches the color/type of the icon in the weaponskill menu
MP-Cost (Always 0)
Valid Targets
shared-timer-id (always 900)
tp-cost (all -1, but changed to 100, presumably for a if tp < tpcost cancelspell rule)
catergory-id (0 unless a header for a section, "quick draw" "blood pact rage" etc)

Edit: Ok, if I'm very very bored and the comma-seperated list works for element, I can see a way to do it.

if wsname is magicalWS //long manual list, no fun
	change type from weaponskill to weaponskill-element //determined by list-icon-id
element = getSkillChainElements(wsname) //another long manual list

I'll check for commas working in element tomorrow.

[Khamsin]

I dont mean gorget alignment, just the element of the WS. There are too many options for gorgets/belts, and each user may use any of several gorgets/belts with it.

However, WS element would help for any element-specific gear, like obis in matching day/weather or stuff like mekira-oto, which enhances elemental WSs if their element matches the day. Probably wouldn't have to actually distinguish between elemental/physical WSs, since the user can bother with that on their end. But just knowing Cataclysm is Dark would be a big help, even if it tells me Shoulder Tackle is Thunder, too.

In spellcast, I'd just say "if spell='Cataclysm|Aeolian Edge|Red Lotus Blade'..." then let rules for obis and such take over. I simply wouldn't make a gear set for things like Shoulder Tackle, or wouldn't involve checks against SpellElement if I did.

[Radec]

element="Wind, Fire"

Didn't register for either of

		<if element="Wind">
			<command>echo Element=Wind</command>
		</if>
		<if element="Fire">
			<command>echo Element=Fire</command>
		</if>

So the easy way is out.

However, spellcast supports at least some regex:

		<if advanced='(bool)regex("%SpellElement", ".*Wind.*")'>
			<command>echo regex Element=Wind</command>
		</if>
		<if advanced='(bool)regex("%SpellElement", ".*Fire.*")'>
			<command>echo regex Element=Fire</command>
		</if>

Both registered matches - Given that the element field is never used otherwise, it'd be possible to cram it all, wselement for obis and skillchain properties for mekira oto/athos gloves in there - downside writing the rule for it isn't something I'd expect just anyone to be able to do.

There really isn't as many weaponskills to add to the magical list as I had thought, I'll make an update with simple element="Dark" for cataclysm/etc.

Also possible to enter the skillchain information in say.. recast, but would need to be as a number. Definitely could be done (0 = none, 1 = fire, 2=wind, 3=(fire and wind), etc) but would end up being fairly arcane.

[Radec]

Ok, so, regex is a valuable tool that I'm too quick to jump too.

<if element="*Wind*"> worked.

Much easier to write.

[Byrthnoth]

I started trying to play around with AutoExec and StatusData.txt to see if we could ghetto-rig something to compensate for composure, but I ran into kind of a strange problem. StatusData.txt seems really unreliable to me. For some reason changes in StatusData.txt on my computer aren't reflected by in-game timers unless there's a minute or two between the change to the file (and save) and using //statustimer reloaddata. ...or sometimes I just can't get it to work at all. Either way, it is unsuitable for what I was trying to use it for.

Theory was this:
* Autoexec detects Composure and uses Run to activate some minor program overwrites statusdata.txt with a different version designed for Composure.
* Autoexec waits a second or two and runs //statustimer reloaddata.

It would be easier if someone could get ahold of the statustimer source and make a multiplication factor or two and, maybe integrate the buff target /make statusdata.txt actually work.

[Khamsin]

I started trying to play around with AutoExec and StatusData.txt to see if we could ghetto-rig something to compensate for composure, but I ran into kind of a strange problem. StatusData.txt seems really unreliable to me. For some reason changes in StatusData.txt on my computer aren't reflected by in-game timers unless there's a minute or two between the change to the file (and save) and using //statustimer reloaddata. ...or sometimes I just can't get it to work at all. Either way, it is unsuitable for what I was trying to use it for.

Theory was this:
* Autoexec detects Composure and uses Run to activate some minor program overwrites statusdata.txt with a different version designed for Composure.
* Autoexec waits a second or two and runs //statustimer reloaddata.

It would be easier if someone could get ahold of the statustimer source and make a multiplication factor or two and, maybe integrate the buff target /make statusdata.txt actually work.

If you already have some buffs up before using Composure, will existing buff timers remain unaffected while only new buffs that appear during composure use the new data?

[Byrthnoth]

No, they would all be affected. The timers don't reset, though.

[Khamsin]

Then it seems like it'll be an inaccurate mess either way, best not to bother doing it that way. The best course of action would be to make a statustimer v2.0 that can assign more accurate buff durations based on parameters you can set (like, amount of +duration you have on your gear, whether it be bard songs or RDM buffs) as well as knowing that buffs cast on yourself during composure are 3x duration.

Or, if someone is feeling adventurous, a learning statustimer that remembers how long your last buff of that type lasted, and next time you get it, it'll put it for that duration. e.g. as a melee, you get a buff from a RDM who has an unknown amount of +duration, and it's unknown whether they're using the composure bonus from AF3, all you know is your haste lasted 234 seconds last time they cast it on you, so it should be reasonable to assume the next haste they cast on you will also last that long.

Of course, even that has flaws since there's no telling whether you're talking to NPCs or zoning or cancelled the buff early or had it dispelled, unless there's a way for a plugin to tell from the chat log how it wore. But that's adding an extra complicated step to an otherwise simple program.

[Alolbont]

Will this fix yarnball as well? Thanks for all your work.

[Radec]

Yarnball has it's own internal timers, so sadly this won't do anything for it.

[Khamsin]

Are remaining durations server side? That is, after it wears the server tells your client, and your client drops the buff icon? Or is there something in memory on the client side that tracks the remaining duration on a particular buff, and when the timer runs out, it drops the icon and notifies server?

[Wenslydale]

Considering that I've had to reinstall FFXI after a complete HD format a couple times, and that one of my mules still has its xp bonus from an anniversary ring that I used to level it to 5 for the first Mog Bonanza. I would imagine they're server side.

Unless it's redundant, but that's a stretch for SE.