Windower 4 - Discussion and Support

[Arcon]

An IPC fix was pushed, Send should work again once you re-run the launcher.

[Obsidian]

Oh, Timers doesn't track buffs other people cast on you?

[Mafai]

Oh, Timers doesn't track buffs other people cast on you?

StatusTimer does?

[Obsidian]

StatusTimer does?

StatusTimer doesn't restart itself whenever a buff gets reapplied though. It also sits on top of the game UI of the overlay so I don't always keep it loaded.

[grevenilvec75]

How about just add a button to disable automatic updating?

Or at least let people opt in for untested updates before the general public gets them.

[Kohan]

This is a very late response to what is now an old topic, but I had missed the response originally.

The auto update is there to prevent from using the old versions because they had an issue / lacked features. Majority of our past issues were because of outdated plugins / hook and this has completely stopped that (besides this last update). This was an issue with our repo (we had a couple branches which caused some confusion). The issue was actually from 2 updates ago and it never made it out to you guys, then the latest set made it out with 2 new sets of changes (one being bad). If something major would have broken, we likely wouldve rolled the update back until we fixed the latest version. We knew that fix was going to be fast so we left that hook as release while it was being worked on. Sorry it took so long.

I don't believe the length of time was too terrible of a factor, even though some people were obviously upset. (I personally hadn't logged on at all while the bad hook was out there, so I never had it.) I understand the importance of updating, so I don't mean to discourage that; rather, I suggested a local backup in case a bad update was pushed that, say, completely broke Windower's functionality.

Obviously, that should not happen, as on your end, you're likely executing various test cases to ensure that you're going to have a solid release. In the case of Windower, you're also obviously not updating the core binary by having another program work as the update middleman (I presume—I've never really paid in-depth mind to the process), but just the hook, add-ons, and plug-ins, so the actual component that facilitates delivery of the new hook will never be compromised. Basically, even if the hook is broken, this will never harm the updating mechanism, because the hook has nothing to do with the updating process itself.

It's not an overly important concern of mine, but just a suggestion related to keeping players playing, even in the case of a broken hook scenario (while avoiding their seeking out alternate/older hooks from unapproved sources). Whether you are interested or not in such a fail-safe is entirely up to you.

EDIT: I've noticed since submitting this that the topic has gone on in various ways, so I'll read all of that now.

[Ophannus]

Not sure if this is a windower issue but every since a few days ago this rule no longer works in my SC:

<elseif spell="Spirit Jump">
<castdelay delay="0.03" />
<if PetISValid="TRUE">
<equip when="precast" set="%Spell" />
</if>
<else>
<changespell spell="Jump" />
<equip when="precast" set="Jump" />
</else>
</elseif>


Normally it makes me use Spirit Jump when I activate Spirit Jump with a Wyvern out. If the Wyvern is dead, it overrides my Spirit Jump command and choose vanilla "Jump" instead. For some reason now, it's overriding Spirit Jump and making me use regular Jump instead whether my Wyvern is out or not.

[Obsidian]

Pretty sure PetIsValid is broken currently.

[Foldypaws]

Not sure if this is a windower issue but every since a few days ago this rule no longer works in my SC:

<elseif spell="Spirit Jump">
<castdelay delay="0.03" />
<if PetISValid="TRUE">
<equip when="precast" set="%Spell" />
</if>
<else>
<changespell spell="Jump" />
<equip when="precast" set="Jump" />
</else>
</elseif>


Normally it makes me use Spirit Jump when I activate Spirit Jump with a Wyvern out. If the Wyvern is dead, it overrides my Spirit Jump command and choose vanilla "Jump" instead. For some reason now, it's overriding Spirit Jump and making me use regular Jump instead whether my Wyvern is out or not.

My lua script

player = get_player()

local targetid = player['index']

local mob = get_mob_by_index(targetid)

if mob['pet_index'] ~= 0
then
send_command("exec DRGSpJump.txt")
else
send_command("exec DRGJump.txt")
end

is also broken.

[Arcon]

The mob struct changed with this update, so all addons and plugins that use pet-related information will be off until that is identified and fixed.

[chichicha]

What was the update of PetTP on 8th May?
It was working fine for me before 8th May.

Was there any error? Sorry that I didn't keep myself up- to- date in this thread.

Is there anywhere to get the pre-8th May version back?

[Kohan]

What was the update of PetTP on 8th May?
It was working fine for me before 8th May.

Was there any error? Sorry that I didn't keep myself up- to- date in this thread.

The post directly above yours (Arcon's) explains why PetTP is not working. It won't be until a new version is released. Using an older version in the interim will not fix the problem for you, unfortunately.

[ikariiiii]

Will an advanced settings GUI ever be implemented like the older versions of windower? Having to manually change registry settings every time I launch is pretty frustrating. Apologies ahead of time if this was already addressed.

[Sechs]

The annoying part is that several times I forget to update my registry manually and I remember only once I'm already in-game! ><
So I have to logout and restart from square one haha :D

[Arcon]

By the way, PetTP, SpellCast and LuaCore have been updated to use the new mob struct a while ago, so all pet-related code should work fine again. However, I do have a sneaking suspicion that SE wants to address that again in the upcoming emergency maintenance. If they do, it will be easy to identify and a subsequent update should be ready soon after that.

Also, what registry settings do people still want/need?

[Darkmagi]

Background resolution, environmental animations, etc. Quite a few things appear to be missing from the old windower gui, my computer is pretty ass so I can't even use windower4 without adjusting the registry settings each time I log in.

[Sechs]

Mainly it was a matter of registry keys number #18 and #19.
#18 doesn't get reset anymore and hasn't been for a while (used to get set to 1), but #19 still gets set to 0.
Also value number #4.
#3 and #4 are used for the background render resolution (supersampling/oversampling).
Number #3 gets correctly set to double the horizontal resolution, while #4 gets set to double the vertical resolution.
This is an error.
The way FFXI works, supersampling has to be a "square", not a rectangle like the window resolution.

If your game resolution is 1920x1080 oversampling (values #3 and #4) should be set to 3840 for both, while instead Windower4 sets them at 3840 for registry key #3, and 2160 for registry key #4. This is an error and will provide some minor changes to the position of on-screen text that majority of people probably wouldn't even notice anyway.
I would apreciate if you could change it, altough of course my main concern is Registry key #19

[ikariiiii]

Also, the game just looks like ass when I turn off super sampling. I get incredibly grainy looking textures instead of the old pixelated look, does anyone know what causes this? I can feel my gfx card crying "stahp" regardless of super sampling on/off

[Gwynplaine]

Also, the game just looks like ass when I turn off super sampling. I get incredibly grainy looking textures instead of the old pixelated look, does anyone know what causes this? I can feel my gfx card crying "stahp" regardless of super sampling on/off

What resolution and what setting are you using for Mip Mapping?

[ikariiiii]

Mip mapping is set to 0 (off?), resolution is 1024x768, bg res is the same when sampling is off