Windower 4 - Discussion and Support

[Elpy]

cancel_spell() in GearSwap no longer works with Shortcuts loaded.

	elseif spell.english == 'Light Arts' and buffactive['light arts'] then
		cancel_spell()
		send_command('input /jobability "Addendum: White" <me>')
	elseif spell.english == 'Dark Arts' and buffactive['dark arts'] then
		cancel_spell()
		send_command('input /jobability "Addendum: Black" <me>')

Tried with different ways of addendum black input, neither works. Without Shortcuts works fine.

Also had few actions lockdowns lately, but not sure when they happened, might have been after i got Terror'ed midcast, or after spell target died midcast.

[Sechs]

I was wondering if Windower developers ever thought or considered the chance to slightly change some things.

* It would be useful to know which addons are being specifically updated during the start-up. Putting names there ("downloading Battlegear data" instead of "Downloading addon data") wouldn't be the solution because they scroll too fast there. But maybe you could think about a popup once the process is completed with a list of updated addons/plugins, or maybe you could create a 4th tab called "Log" where a list of updated addons can be found. No need to put the details, if someone is interested he can go find them on the specific github pages.
* Ever thought about creating a flash, a different colour, a blinking name for recently added addons/plugins? Not talking about update, just NEW stuff. Once a new addon/plugin is added, keep this different name or whatever else visual aspect you can think of for like one month, and then people will be able to discriminate between new stuff and old stuff. Most of the times I don't even notice them because they're just in a list and it's hard to remember stuff that was already there and you judged to be unuseful for your personal needs, or new stuff which would be awesome but you didn't even know it existed.

[Nitrous24]

* It would be useful to know which addons are being specifically updated during the start-up. Putting names there ("downloading Battlegear data" instead of "Downloading addon data") wouldn't be the solution because they scroll too fast there. But maybe you could think about a popup once the process is completed with a list of updated addons/plugins, or maybe you could create a 4th tab called "Log" where a list of updated addons can be found. No need to put the details, if someone is interested he can go find them on the specific github pages.

The reason it just says "Downloading addon data" is because it downloads them all. It was taking up too many git requestss or something when downloading seperately, you must figure there's hundreds of files there, even only getting just the few people need occasionally is a lot of requests for files. However, the way they do it is to just download the entire git .zip file then only extract what's needed in the addon directory.

[Sechs]

Ah I see, doesn't make sense to write which ones have been updated then.
Altough you could still do with a "log" somewhere inside the addon. Shouldn't be too complicated to created something similar to what an RSS feed is for web pages, taking data from each github addon and condense it into a single file that can be viewed from a webpage or within the Windower addon, and shouldn't stress the servers too much.

[Trumpy]

Just curious but is there a reason to makin addon versions of plugins like timestamp or distance?

[Arcon]

Just curious but is there a reason to makin addon versions of plugins like timestamp or distance?

A few, the most obvious is that Lua is significantly easier to program for and to maintain. For example, Lua's version of Timestamp can resolve some indentation issues and has better support for customization, such as customized timestamp formats, colors, etc., while the Lua version of Distance can be dragged anywhere on the screen and it will automatically save the position and remember for the next time. Also, custom coloring based on distance will be added for it soon.

In additon, it might give people the option of fixing things in case they break (for example in an update), instead of having to wait for the Windower people to do it, since anyone can edit them and commit the changes. It also gives people the option of amending them directly if they can think of a cool feature instead of having to submit a feature request and wait for one of the lazy devs to get off their asses to implement it.

As for the changelog, an ingame display of a changelog is planned as well. As Nitrous said, the entire Lua repository is downloaded and addons extracted, because the GitHub API limits the requests per hour. Hopefully the ingame changelog display will alleviate some of these issues as well as satisfy the curiosity of people.

Edit:
I should mention that it's planned to convert as many plugins as possible to addons and eventually discontinue the respective plugin support. However, we plan to support as many plugins as possible until most people migrate to the addon versions, which might be a long time, so you shouldn't worry about it yet. However, I'd recommend switching over simply because the addon version is usually better than the plugin version.

[Trumpy]

I have the feeling i will have a really hard time switching from spellcast

[Sechs]

I'm really liking this.
Once again, kudos to all of you folks

[Arcon]

I have the feeling i will have a really hard time switching from spellcast

I should also mention that GearSwap is not only infinitely better than Spellcast and worth starting over for all on its own, but also that a Spellcast XML to GearSwap script converter is planned, so that old files can be converted with little to no effort. That is not yet implemented at this point (since even GS itself is not fully implemented/operational yet), but once it's done it should make the conversion process as painless as possible.

We are fully aware though, that we'll probably have to keep supporting Spellcast for quite some time, and like I said, this is distant future stuff. We won't drop support for a plugin as long as people are still using it. It simply makes sense to do the switch.

There is one drawback, however, and that's that when LuaCore crashes, all addons will be unloaded. That's why we appreciate every report of a LuaCore bug so we can make it as stable as possible. Usually that doesn't happen unless we just changed something in the API and forgot an edge case or two, but those get patched up very quickly. If it does happen to you, I suggest //exec autoload/autoload.txt, that will reload all addons that you selected in the launcher.

[Elpy]

GearSwap:

pet_midcast doesnt work with wyvern, tested with

function pet_midcast(spell,action)
	send_comand('input /echo ...')
end

among other things.

Edit: confirmed full lockdown when target of your spell dies before its finished. I suspect other unnatural spell interrupts behave the same way.

[Aureus]

Pity I can't make donations. I've no problem putting money toward something I know I'll appreciate.

This is an issue that frequently comes up and we realize there has been some confusion about this in the past, so it is probably worth addressing.

We have decided not to ask for or accept donations for Windower, or to run any advertisements on our site or applications. The reason for this is twofold:

1 - There are quite a few sites whose donation practices are questionable at best. Setting goals of thousands of dollars for a 3 or 6 month period. Fact is, websites simply aren't that expensive to host. I don't want people questioning if the money they donate to the project is ending up lining our pockets instead of paying for costs.

2 - When you pay for something (or, in this case, donate towards), there's an expectation of service. We're a volunteer crew, and I don't see any good coming out of that situation. We'll try our best to address everyone's concerns or issues equally.

Above all else, Windower is a hobby for us. Hobbies cost money. And we're okay with that.

[Byrthnoth]

Not ignoring your reports, Elpy, and some of them are fixed in my copy but I made some other changes and it's not ready to go live yet.

Here's where I am:
- The Pianissimo issues with Shortcuts have been fixed. - Pushed live, didn't bother to increment the shortcuts version number because it's a pretty minor change.

- Midcast/Aftercast for pets is back in. - Mistake on my part when trying to minimize memory requirements, not live yet.

- register_event is functional for users, but I need register_event to return an index and an unregister_event(id) function so that I can destroy the events when you change gearswap files. - Not live yet, needs a function to be added to LuaCore.



On the horizon:
- <st*> adjustments are going to be a pain in the ass, as I basically have to run precast twice (once sandboxed from both the main environment and the user environment on <st*> and then once again for real if they decide to go through with it). I have left these for tomorrow morning. We believe that SE essentially hacked all subtargeting into the game late in the development cycle, which is why it's so damned wonky, but it really is a pain to deal with. There is no pleasant way to deal with this, because target is undefined when using the initial <st*> command so doing switches based on non-raw targets will be meaningless. I need to remember to ask someone to look at Spellcast's source and figure out what its logic is at the moment.

- I've started working on adding the ability to specify gear based on augments, but I still can't decide quite how they should be defined. Like, right now we basically have:

equipment_table = {head="whatever", neck="whatever", ...}.

If I add augments, I either have to switch to either using tables for each item or having a separate augment table contained within the equipment table:

equipment_table = {head={name="whatever", augment_1="Magic Damage Taken", value_1="-5%", ...}, neck={name="whatever", augment_1="Refresh", value_1="1", ...}, ...}

equipment_table = {head="whatever", neck="whatever", ..., augment={head={augment_1="Magic Damage Taken", value_1="-5%", ...}, neck={augment_1="Refresh", value_1="1", ...}, ...} }

Anyway, both ways look crappy. A third option is to have GearSwap check to see whether any given value is a table or string and handle it differently based on that. So if it's a string, interpret it as I presently do. If it's a table, interpret it like example 1. That's the option that I favor, but it leads to an inconsistent syntax. The second option above wouldn't break anyone's current gearswaps, but it seems stupid to separate the name and augment values when they're both being used to specify the same piece of equipment.

- I have sort of a ghetto hack in right now to stop people from crashing on Reraise, but I need to think of some way to fix it in a more permanent way.

[Zirael]

Not ignoring your reports, Elpy, and some of them are fixed in my copy but I made some other changes and it's not ready to go live yet.

Here's where I am:
- The Pianissimo issues with Shortcuts have been fixed. - Pushed live, didn't bother to increment the shortcuts version number because it's a pretty minor change.

- Midcast/Aftercast for pets is back in. - Mistake on my part when trying to minimize memory requirements, not live yet.

- register_event is functional for users, but I need register_event to return an index and an unregister_event(id) function so that I can destroy the events when you change gearswap files. - Not live yet, needs a function to be added to LuaCore.



On the horizon:
- <st*> adjustments are going to be a pain in the ass, as I basically have to run precast twice (once sandboxed from both the main environment and the user environment on <st*> and then once again for real if they decide to go through with it). I have left these for tomorrow morning. We believe that SE essentially hacked all subtargeting into the game late in the development cycle, which is why it's so damned wonky, but it really is a pain to deal with. There is no pleasant way to deal with this, because target is undefined when using the initial <st*> command so doing switches based on non-raw targets will be meaningless. I need to remember to ask someone to look at Spellcast's source and figure out what its logic is at the moment.

- I've started working on adding the ability to specify gear based on augments, but I still can't decide quite how they should be defined. Like, right now we basically have:

equipment_table = {head="whatever", neck="whatever", ...}.

If I add augments, I either have to switch to either using tables for each item or having a separate augment table contained within the equipment table:

equipment_table = {head={name="whatever", augment_1="Magic Damage Taken", value_1="-5%", ...}, neck={name="whatever", augment_1="Refresh", value_1="1", ...}, ...}

equipment_table = {head="whatever", neck="whatever", ..., augment={head={augment_1="Magic Damage Taken", value_1="-5%", ...}, neck={augment_1="Refresh", value_1="1", ...}, ...} }

Anyway, both ways look crappy. A third option is to have GearSwap check to see whether any given value is a table or string and handle it differently based on that. So if it's a string, interpret it as I presently do. If it's a table, interpret it like example 1. That's the option that I favor, but it leads to an inconsistent syntax. The second option above wouldn't break anyone's current gearswaps, but it seems stupid to separate the name and augment values when they're both being used to specify the same piece of equipment.

- I have sort of a ghetto hack in right now to stop people from crashing on Reraise, but I need to think of some way to fix it in a more permanent way.

Maybe you could allow people to make aliases for augmented gear? Like, if I have 4 Dark rings (two PDT-6% and two MDT-6%), I could make an alias table and do:

Spoiler: show

PDTring1:augment={ring={augment_1="Physical Damage Taken", value_1="-6%"}
PDTring2:augment={ring={augment_3="Physical Damage Taken", value_1="-6%"}
MDTring1:augment={ring={augment_2="Magic Damage Taken", value_1="-5%"}
MDTring2:augment={ring={augment_1="Magic Damage Taken", value_1="-6%"}

Then, if I want to use PDT rings in gearswaps, I'd call their aliases instead the full blown gear+augment listing. Would make gear swap lists somewhat cleaner.
Not sure if this idea helps you in any wa solve your problem, but I thought I'd toss it in.

[Byrthnoth]

They can do that as it is, though it is easiest in the first or third case.

[Arcon]

The alias idea isn't too bad, you could assign a dedicated alias space to it. That way you could still use strings, wouldn't have to worry about variable name collision and the actual set syntax would look uniform across the board.

Also, personally I'd suggest simple key-value pairs instead of augment_1, value_1, looks like it would make the entire thing simpler to read and write.

aliases = {}
aliases['Dark Ring (MDT)'] = {name = 'Dark Ring', ['MDT'] = -5, 'BDT' = -2}
aliases['Dark Ring (PDT)'] = {name = 'Dark Ring', ['MDT'] = -2, 'BDT' = -1, ['PDT'] = -6}

The equipping function could simply check if the alias is defined, if yes, it looks up the augmented item, if not, it can assume it's a regular item name and function as it is now. And the set definitions could look the same to what they are now:

sets['lolNoDRing'] = {}
sets['lolNoDRing'].lring = 'Dark Ring (MDT)'
sets['lolNoDRing'].rring = 'Dark Ring (PDT)'

sets['DRing goes right and if you disagree you suck'] = {
    lring = 'Dark Ring (PDT)'
    rring = 'Defending Ring'
}

An additional benefit would be that comparing items would be easier, since you could just compare the alias strings instead of having to traverse the table or check if they resolve to the same actual item.

[Byrthnoth]

Do we know which plugin/addon is makin /target <stnpc> not work. I was trying to charged whisker burn last night and ill be damned if my

/target <stnpc>
/ja "chain affinity" <me> <wait 1>
/ma "charged whisker" <lastst>

didnt work. which means i have to make sure to have a target before i hit macro and just make it use the JA and then hope if have a target <t> still when spell goes off. With the way i had it before i could prep it with a sub target and it would all go off brilliantly.

I can't replicate this problem. I used this because I was in town and don't have BLU:

/target <stpc>
/ma "Cure" <me> <wait 5>
/ma "Cure II" <lastst>

[Trumpy]

pretty much when u try to use /target <stanything> it bypasses it all together and nothing happens. also when dead I used to be able to /target <st> and be able to target the nm we are fighting to see its hp but. So should be testable anywhere. I have like 30 mins to get to work but i can mess with it later to come up with more testable situations.

[Byrthnoth]

I pushed a lot of crap live a little earlier than expected due to some API changes that made it necessary. So far the main thing I've noticed is that one of the LuaCore functions is broken in Monstrosity.

Augment specification's back end is done. Now I just need to implement it into the gear discrimination function and test it. I'm still procrastinating dealing with <st*>s.

[Ophannus]

Is there a way to have the scoreboard add-on but have it not autoload? Whenever I 'turn it off' in the windower4 GUI before logging into FFXI it just unloads/deletes the folders. But I'd rather have those folders kept and I can just /lua load scoreboard when I need it.

[Raelia]

Is there a way to have the scoreboard add-on but have it not autoload? Whenever I 'turn it off' in the windower4 GUI before logging into FFXI it just unloads/deletes the folders. But I'd rather have those folders kept and I can just /lua load scoreboard when I need it.

'sb hide' in your init? 'sb show' when you want to use it?

Might want to alias sb show and sb reset together in that case actually. I don't know if it tracks while hidden...