Woah, that looks cool. Have you hidden the native party list or are you running 4k res(are they hidden behind the xivparty)?
XivParty - Party List Addon For Windower 4 |
||
XivParty - Party List Addon for Windower 4
Offline
Posts: 32
Bahamut.Brixy said: » Works perfect! I'm still adjusting colors and such but hopefully I'll have a public version soon for those that want it. Woah, that looks cool. Have you hidden the native party list or are you running 4k res(are they hidden behind the xivparty)? Sockfoot said: » Using a sleep or schedule? Never been a big fan of prerender for that reason, though it does still live in a few of mine from before. Offline
Posts: 142
KujahFoxfire said: » Ragnarok.Tylas said: » Sockfoot said: » Using a sleep or schedule? Never been a big fan of prerender for that reason, though it does still live in a few of mine from before. Is it maybe an option to just not update while player status is 4 (event)?. Im not sure there is a need for it to be updating while locked with an npc/interation but I might be wrong. Not tested but something like below? Code windower.register_event('prerender', function() local player = windower.ffix.get_player() if isZoning or not isInitialized or player.status == 4 then return end Settings:update() model:updatePlayers() view:visible(isSetupEnabled or not Settings.hideSolo or not isSolo(), const.visSolo) view:update() end) A low-hanging fruit could be to simply switch from the prerender event to the incoming packet event.
Sockfoot said: » That might be a potential solution but I think generally running things off framerate in a game where people use different frame rates isn't the best practice. Again, no slight intended as we have all done it! os.clock() has ms timing, you could try setting a constant minimum delay like 0.03 sec whenever you update, and skip render if that delay hasn't elapsed since last update
it wouldn't be fully immune to jitter, but at higher framerates the polling interval should keep it pretty smooth if you're using windower's font objects, still have to consider whether windower is cacheing them or rendering every frame though.. you probably aren't changing most actual elements every frame because packets are only coming in every 400ms(250 w/ packetflow) so performance issues might be unavoidable if the cost is coming from windower's rendering that many objects rather than your updating itself That sounds like the most reasonable approach.
I'm not making any calls to Windower primitives unless something actually changed. Performance shouldn't be an issue, I developed this on an 8 year old i5 and never saw any noticeable performance hit at 30 or 60 fps. This whole ordeal only came up because of the insane frame rates FastCS is causing. I noticed from using the config plugin that if you can't fully reach the target frame rate, animations seem to slow down. It is possible that the same is happening with FastCS, otherwise I wouldn't expect stuttering at the 270 fps I observed. Edit: After some digging I found that os.clock returns wall-time on Windows but cpu-time on Linux. This might cause issues for people trying to run the game on Linux or Steam Deck. :/ that's a shame, there are a lot of ways to do it with ffi, but doesn't seem that windower has that in v4
Offline
Posts: 142
local gettime = require('socket').gettime
then now = gettime() and check against that. Ragnarok.Tylas said: » Sockfoot said: » That might be a potential solution but I think generally running things off framerate in a game where people use different frame rates isn't the best practice. Again, no slight intended as we have all done it! Ragnarok.Tylas said: » I'm not making any calls to Windower primitives unless something actually changed. If this is the case, then I would assume the overhead is coming from windower's primitives themselves rather than anything you're doing. Checking every frame is certainly unnecessary, but monitoring a few lua end variables should not be enough to cause framerate drops unless you're doing something terribly wrong. socket.gettime seems to do the trick, msec precision and no noticeable jitter in the animations. Seems to work fine with FastCS as well now. I'll wrap this up in a new release with a few other minor fixes soon.
Shiva.Thorny said: » If this is the case, then I would assume the overhead is coming from windower's primitives themselves rather than anything you're doing. Checking every frame is certainly unnecessary, but monitoring a few lua end variables should not be enough to cause framerate drops unless you're doing something terribly wrong. Either way, the issue is solved. Thanks all for your help. Offline
Posts: 25
Morning, i like the new update.
HAve couple question: 1 - there is a way to add more than 16 buff icon ? 2 - there is a way you can add party distance thx Jhoo said: » HAve couple question: 1 - there is a way to add more than 16 buff icon ? 2 - there is a way you can add party distance 2 - There are party distance options like the dimming of the bars or the "//xp range" command. If you want a numerical display, that would need to be a new feature although fairly easy to add. I'm not sure if I can fit yet another number in the layouts, but I can add a customization option. Offline
Posts: 25
1 - 32 buff are enough :) - need to BL some I don’t really need to have.
2 - would be awesome to have party distance! even if I have to sacrifice job icon that is nice to see but don’t really need. But awesome work so far. Offline
Posts: 25
Stupid questions probably, but:
My buffs populate from right to left, and newer ls going to the very end to the left. There is a way to let them populate from the right, and still populating from right to left ? Offline
Posts: 123
Amazing job! loved it! thanks for making the UI size/position adjustable real time.
Question, is it possible to make ffxi2 layout have the buffs come at the right side instead of left? The way I have it is that the party list is slightly towards the middle (so I don't watch the bottom right of the screen all the time as a whm). duos said: » Question, is it possible to make ffxi2 layout have the buffs come at the right side instead of left? In general when you edit layouts, I recommend to use the setup mode to test your changes. After you save the xml, just reload the layout instead of the whole addon. Jhoo said: » My buffs populate from right to left, and newer ls going to the very end to the left. There is a way to let them populate from the right, and still populating from right to left ? Offline
Posts: 25
Tylas what happen if i comment buffs i dont neeed.
they keep showing. Jhoo said: » Tylas what happen if i comment buffs i dont neeed. they keep showing. Version 2.1.0 has been released.
Frame rate independent updating should fix issues with FastCS and make animations have the same speed regardless of 30 or 60 fps. The update interval can be changed in the settings file if you so desire. I've added numeric party member distances as an alternative to the range indicators. Activate using "//xp range num", available in all layouts except ffxi2 by default. Of course you can add it to that one as well if you copy the whole <range> node from another layout and customize it a bit. Next up are two new commands that should help a bit covering the original game UI with the ffxi2 layout. "ShowEmptyRows" will make party lists always be fully expanded when there is at least one party member. "SwapSingleAlliance" will show members of alliance1 in the UI of alliance2 as long as there is only one alliance party. This helps prevent a gap where the original UI would be visible. Try a combination of these commands plus "alignBottom" to best fit your needs. Protip: both "showEmptyRows" and "alignBottom" can be set for each party separately if you add 0,1 or 2 to the command. 0 being main party, the other two are for the alliances. Lastly I've added a layout customization option for changing the HP/TP bar colors the same way as the numbers change. I did not add this to any default layouts though. Offline
Posts: 25
Ragnarok.Tylas said: » Lastly I've added a layout customization option for changing the HP/TP bar colors the same way as the numbers change. I did not add this to any default layouts though. i have added to layout: <hporangebarcolor>#f8631d</hporangebarcolor> <hpredbarcolor>#FF0500</hpredbarcolor> <hpyellowbarcolor>#F3F37CFF</hpyellowbarcolor> but once the hp drop it change color but not get back to green. am i doing something wrong ? Jhoo said: » but once the hp drop it change color but not get back to green. I've released a fix in version 2.1.1. Offline
Posts: 25
Ragnarok.Tylas said: » Jhoo said: » but once the hp drop it change color but not get back to green. I've released a fix in version 2.1.1. I'll test 2.1.1 !!. Actually I solved this way on from line 106 to 117 from uistatusbar.lua if self.barType == const.barTypeHp then if val >= 0 then if valPercent < 25 then color = self.hpRedColor barColor = self.hpRedBarColor elseif valPercent < 75 then color = self.hpOrangeColor barColor = self.hpOrangeBarColor elseif valPercent > 75 then color = self.hpYellowColor barColor = self.hpYellowBarColor end Thanks for your work!! I agree! It's so nice to be able to just click on other players in other alliance parties instead off having to click through or tab through everyone!
|
||
All FFXI content and images © 2002-2024 SQUARE ENIX CO., LTD. FINAL
FANTASY is a registered trademark of Square Enix Co., Ltd.
|