Item Search
     
BG-Wiki Search
+ Reply to Thread
Page 7 of 12 FirstFirst ... 5 6 7 8 9 ... LastLast
Results 121 to 140 of 233

Thread: Spellcast Shop Thread     submit to reddit submit to twitter

  1. #121
    Chram
    Join Date
    Sep 2007
    Posts
    2,526
    BG Level
    7
    FFXI Server
    Fenrir

    When I'm on sch (since I happen to be set up for that already), casting Cure III with <stal> causes a 1 second dip to 24.6 fps (almost always exactly that value), then it's back to 29.5. Casting Cure II with <stpc> causes a dip to 21.3-24.0 fps before reverting. Overall, a delay of about 150-250 milliseconds (ms).

    There are two areas that that delay can draw from: the rules, and equipping the gear. If I go in and comment out all the gear that could be equipped for curing, such that it only equips empty sets, fps after the above uses are 24.3 for Cure III and 22.8 for Cure II. So it's not the actual act of equipping the sets that's causing the fps lag.

    As mentioned, use of "input /ma cure3 motenten" from the console causes no fps lag at all, but entry from the chat line drops fps to 24.7. That implies that it's not the Spellcast rules that's causing the lag, since the same rules run regardless of input method.

    To validate that, I put a <return /> at the very top of the rules section, so that nothing would get run. With the return rule in place, there was no lag. Therefore it -is- somehow related to the rules.

    Going back to the console aspect, tried using "/console input /ma cure3 motenten" from the chat input line; this caused no lag. So it's not merely the fact that it's coming from the chat input that's causing lag.

    Then I tried something else: "//cure3 motenten" caused no lag, but "/ma cure3 motenten" did cause lag. I'm guessing the "//" shortcut evaluates to "/console input".

    "//cure3 <stpc>" also causes lag, as it's being injected back into the main game thread in order to do the target selection.



    My best guess right now as to why the console version of the commands doesn't cause the lag is that it's a threading issue. Anything going through the console (even if the text originated on the chat line) has to be on a separate thread, otherwise opening the console would completely stall the game. However it appears that when Spellcast is interacting with direct input from the game (particularly with <st*> type selections), it's running on the game's main thread, and thus liable to stall the game due to long processing.

    Essentially, Spellcast is sitting between the user chat line input and the text being sent to the game. /console commands are handled by Windower itself, pulling it completely out of the game thread and thus not interfering with the game directly. Use of Spellcast then happens on the console thread, and is then injected back into the main game thread, so no lag. Regular commands stay inside the game thread, though, which means every bit of the delay is felt in the game environment.

    Of course a better solution would be for the Spellcast processing to not take so long in the first place. Unfortunately I'm not sure what else I can get rid of without gutting large parts of the functionality. The whm xml has already been simplified similarly to the sch xml; both have been streamlined to remove almost all BaseSets, to minimize the amount of time spent searching through the set lists.


    Honestly, I'm just desperately waiting for the 3.0 release, hoping that it will fix a lot of the inefficiencies of the current version of Spellcast. Was hoping it'd be out by now.

  2. #122
    Hydra
    Join Date
    Oct 2009
    Posts
    109
    BG Level
    3
    FFXI Server
    Bismarck

    Re: Completed Spellcast XMLs Thread (HIGHLY recommend donators to register with Pastebin.com)

    Quote Originally Posted by Motenten View Post
    Stuff.
    Hmmm.

    I guess I do have two different curing styles between SCH and WHM, since on SCH I'm almost always curing in a different party its faster for me to just type //cure4 name. Where as in WHM I use macros with <stpc>. I will update my WHM XML to the new version and if I'm still noticing the spikes I will just change my macros! Glad there is a fix at least! I like the XML style too much to give them up!

  3. #123
    Relic Weapons
    Join Date
    Sep 2007
    Posts
    377
    BG Level
    4
    FFXIV Character
    Caprese Dionir
    FFXIV Server
    Hyperion
    FFXI Server
    Sylph

    How much fps lag and for how long could depend on the user's computer specs a bit too. Didn't they used to have 2 versions of spellcast, one for really old computers and ones for.. less old computers?

    Personally on WHM, I use <st> or <stpc> macros exclusively and haven't ever had any slowdown, although my spellcast for WHM is very simple logic. Autosets, Cure, Regen, Other Enhancing, Dark, Divine, with no includes.

    I would've thought that /ma "Cure III" <st> (from chat or a vanilla macro) would've determined the target before threading anything to Windower and spellcast. You don't gear blink until you select a target, and if you cancel the spell without selecting, spellcast does nothing.

    It seems like once that target is caught, then spellcast begins its process, it holds the inputted command, does a precast, runs the command, then processes midcast while its casting, and finally aftercasts.

    I looked at the debug, it does appear to acknowledge a select target occuring, but its different when it finally casts.
    Code:
    [3:50:38 PM] 6508:<41996> IncNormalCmd: /ma "Cure IV" <st>
    [3:50:38 PM] 6508:<0> SpellSearch Returned: (yes) Cure IV : <st> (yes) - IsST
    [3:50:38 PM] 6508:<0> Final Spell name: Cure IV
    ....A lot of stuff about sets precasts gearswaps etc...
    [3:50:41 PM] 6508:<2543> IncNormalCmd: /magic "Cure IV" <chosentarget>
    [3:50:41 PM] 6508:<0> SpellSearch Returned: (yes) Cure IV : 33472 (yes) - NotST
    [3:50:41 PM] 6508:<0> Final Spell name: Cure IV
    ...More gearswap processing...
    [3:50:41 PM] 2736:<0> Casting Spell: /raw /magic "Cure IV" 33472
    [3:50:41 PM] 2736:<0> is not <st>, waiting
    So reading that, I'd agree that it sounds really inefficient. As far as the log the reads it processed precast/midcast/aftercast sets 3 times before finally casting the spell because I used an ST and it tried to "translate it" multiple times until it was happy. I don't really see noticeable lag from when the spellcast begins casting probably because I kept my file as simplistic as possible. I'd rather have it fast and sacrifice certain functionality than have it be slow and address every impossible situation I don't have any care about on WHM.

  4. #124
    New Merits
    Join Date
    Jun 2006
    Posts
    226
    BG Level
    4

    Quote Originally Posted by Motenten View Post
    When I'm on sch (since I happen to be set up for that already), casting Cure III with <stal> causes a 1 second dip to 24.6 fps (almost always exactly that value), then it's back to 29.5. Casting Cure II with <stpc> causes a dip to 21.3-24.0 fps before reverting. Overall, a delay of about 150-250 milliseconds (ms).

    There are two areas that that delay can draw from: the rules, and equipping the gear. If I go in and comment out all the gear that could be equipped for curing, such that it only equips empty sets, fps after the above uses are 24.3 for Cure III and 22.8 for Cure II. So it's not the actual act of equipping the sets that's causing the fps lag.

    As mentioned, use of "input /ma cure3 motenten" from the console causes no fps lag at all, but entry from the chat line drops fps to 24.7. That implies that it's not the Spellcast rules that's causing the lag, since the same rules run regardless of input method.

    To validate that, I put a <return /> at the very top of the rules section, so that nothing would get run. With the return rule in place, there was no lag. Therefore it -is- somehow related to the rules.

    Going back to the console aspect, tried using "/console input /ma cure3 motenten" from the chat input line; this caused no lag. So it's not merely the fact that it's coming from the chat input that's causing lag.

    Then I tried something else: "//cure3 motenten" caused no lag, but "/ma cure3 motenten" did cause lag. I'm guessing the "//" shortcut evaluates to "/console input".

    "//cure3 <stpc>" also causes lag, as it's being injected back into the main game thread in order to do the target selection.



    My best guess right now as to why the console version of the commands doesn't cause the lag is that it's a threading issue. Anything going through the console (even if the text originated on the chat line) has to be on a separate thread, otherwise opening the console would completely stall the game. However it appears that when Spellcast is interacting with direct input from the game (particularly with <st*> type selections), it's running on the game's main thread, and thus liable to stall the game due to long processing.

    Essentially, Spellcast is sitting between the user chat line input and the text being sent to the game. /console commands are handled by Windower itself, pulling it completely out of the game thread and thus not interfering with the game directly. Use of Spellcast then happens on the console thread, and is then injected back into the main game thread, so no lag. Regular commands stay inside the game thread, though, which means every bit of the delay is felt in the game environment.

    Of course a better solution would be for the Spellcast processing to not take so long in the first place. Unfortunately I'm not sure what else I can get rid of without gutting large parts of the functionality. The whm xml has already been simplified similarly to the sch xml; both have been streamlined to remove almost all BaseSets, to minimize the amount of time spent searching through the set lists.


    Honestly, I'm just desperately waiting for the 3.0 release, hoping that it will fix a lot of the inefficiencies of the current version of Spellcast. Was hoping it'd be out by now.

    Anyone working on this? I don't see any post on windower.net
    I spend 5hours to try to fix this before i saw this post... At some point i though i fixed it by removing some pluggins from the init.txt. Sometimes, after you zone the lag disapear. When it goes down to 15FPS its really bad ><

  5. #125
    Sea Torques
    Join Date
    Feb 2008
    Posts
    580
    BG Level
    5
    FFXI Server
    Phoenix

    can anyone link me to a SAM sc with rules for using a bow/ranged attacks

  6. #126
    New Spam Forum
    Join Date
    Jul 2010
    Posts
    186
    BG Level
    3
    FFXI Server
    Bahamut

    I suggest using the copy of one of Motenten's includes which I have in my pastebin. I modified it slightly to include a dynamis group. I used this for magian trials for xp in dynamis. I simply put the ws and tp sets in there w/ only the monster +2 pieces in them, so they remain equipped while you are in dynamis. If you do not wish to use the modified version, you can remove the dynamis group from the equipment sets section.

    As far as how to make it work... use the same bindings that motenten specified in his include.
    These:

    bind f9 input /ma CombatMode Cycle(Offense)
    bind ^f9 input /ma CombatMode Cycle(Defense)
    bind !f9 input /ma CombatMode Toggle(Aggressive)

    bind f10 input /ma PhysicalDefense .On
    bind !f10 input /ma PhysicalDefense .Cycle
    bind ^f10 input /ws CombatMode Kite:toggle

    bind f11 input /ma MagicalDefense On

    bind f12 input /ma Update .Manual
    bind !f12 input /ma Reset .Defense
    bind ^f12 input /ma Update WSDistance

    you will likely want to use the following in your init file also:

    exec Pet Alias v1.4.txt


    Currently the only offense modes I use are normal and Critical. The critical is used for pet-priority. hence if set to critical, the tp set will favor pet haste over master haste, although both are equipped to dd. However, you can change this simply by setting different gear for the tp-*-crit-* sets.

    Also, the defensive tp sets are also for the pet.
    The f11 and f10 triggers for pdt and mdt sets favor the master, not the pet.


    The only other custom triggers are the following:
    /ma ClassTrigger .ready
    /ma ClassTrigger .ready-cycle

    These should be written in macros as they are. The first executes sic or the selected ready command. The second toggles thru the ready commands for your current pet. I'm quite pleased w/ this setup, because I can quickly access all ready moves via 2x macros, no matter which pet I have active.

    I do not use a call beast macro. the pets-alias.txt file contains some shorthand command which I type into the console.

    for example:

    //lulush

    Typing this alone will pull the jug out of my satchel and call lucky lulush. This requires that the Itemizer plugin be loaded. There is a variable in the spellcast to configure whether you want to pull from the sack or satchel, or Inventory. If you enter Inventory, then Itemizer is not required.
    likewise:

    //gooey
    //merle
    //mac
    //sheep (sheep familiar)

    All jug pets are included. Call beast will remember the last pet you called. if you simply execute call beast again, it will call the same pet, but it will not pull jug from satchel or sack w/out the pet shorthand.

    Another feature is to type a shorthand to change which the active pet food is. Theta is the default, however this can be changed in the variables section of the spellcast.

    I can quickly switch what the active pet food is by typing in the following shorthand:

    //zeta
    //eta
    //beta
    //poultice
    //roborant
    //theta

    Unlike the Call Beast Command, reward will not take the pet food from the sack or satchel.

    Another feature is that Ferine Gausape +2 is locked on when Killer Instinct is active. I tend to use killer effects + food whenever I have killer instinct up.

    There are some features which are currently not working. However they do not impede the other functions.

    - I'll probably need to modify the include a bit to keep pet haste feet equipped instead of skadi's for movement speed when pet is engaged and master is not. I would like to make this toggle w/ the kite mode selection which Motenten has already included. However, currently, this keeps equipping the skadi feet for movement.

    - I have a section for setting a variable for killer effects food. This should assign a killer effects type food automatically depending on what jug pet you summon. However, it is not currently functioning as intended. I need to troubleshoot it a bit more.

    Please let me know specifically what difficulty you are having if you want further assistance.

  7. #127
    CoP Dynamis
    Join Date
    Mar 2006
    Posts
    252
    BG Level
    4
    FFXI Server
    Phoenix

    Quote Originally Posted by Mrp View Post
    When it goes down to 15FPS its really bad ><
    yeah, I've died a couple times due to the freezing now. I upgraded to WHM Rev3 but am still having the problem pretty significantly. In some circumstances, it consistently lags down to ~22 FPS, other times consistently 15 and if I spam my macro I can even get it down into the 3~5 FPS range.

    I know Mot already did this, but in an attempt to be constructive I'm going to try to debug it a bit later tonight. I was hoping finally switching to Rev3 would at least make it bearable but it's still really bad sometimes, so hopefully some additional debugging will be informative.

  8. #128
    Chram
    Join Date
    Sep 2007
    Posts
    2,526
    BG Level
    7
    FFXI Server
    Fenrir

    Test environment:

    Drk61/Dnc30
    Test action: Spectral Jig
    Indication of lag: ShowFPS
    Nominal FPS value: 29.4


    Tests:

    1) Created completely blank spellcast
    FPS: 29.4

    2) Filled rules section with 40 repetitions of <if MainJob="Drk"></if>.
    FPS: 29.4

    3) Filled sets section with 50 empty sets. Added one equip rule within the first <if> to equip set1.
    FPS: 29.4

    4) Changed <equip> rule to equip set50.
    FPS: 28.4

    5) Repeated <equip> rule in all other <if> blocks.
    FPS: 13.7 - 17.8

    6) Changed set50 equip back to set1, but left the 40 repetitions.
    FPS: 25.9

    ~Conclusion 1: Equipping set1 in the list of sets is less expensive than equipping set50. Hitting set50 40 times dropped results by about 10 FPS compared to using set1. Equipping a single set50 dropped FPS by 1 compared to equipping a single set1.

    7) Changed rule in each <if> to advanced='"$TestingFPS"="Yes"'. Rule will fail because variable is not present.
    FPS: 28.2 - 28.8

    ~Conclusion 2: Advanced rules are more expensive than basic rules. 40 reps of MainJob="Drk" had no impact on FPS, while 40 reps of the advanced rule (which failed, so no equips were done) dropped by 1 FPS.

    8) Added variable $TestingFPS, set to "Yes". Equipping set50 in each.
    FPS: 13.8 - 16.4

    9) Changed all sets except set1 to have a baseset of set1.
    9a) equip a single set1
    FPS: 29.4
    9b) equip a single set50
    FPS: 28.5
    9c) equip a single set50, with a baseset of set49
    FPS: 28.5

    ~Conclusion 3: Using sets with baseset didn't seem to notably impact results.

    10) Removed basesets from sets. Changed <if> check to: MainJob="Drk|a|b|c|d|e|f|g|h|i|j|k|l|m|n|o|p|q|r|s |t|u|v|w|x|y|z". No <equip>.
    FPS: 29.0

    11) Changed the above test to put Drk at the end of the list.
    FPS: 28.6

    ~Conclusion 4: Multiple OR checks slow things down, particularly if the item being tested is near the end of the list.

    12) Added the advanced rule, so now checking that + MainJob (long list with Drk at end).
    FPS: 27.5 - 28.0

    ~Conclusion 5: Has similar impact relative to starting value as when it was the only rule. So, rule addition penalties are linear.

    13) Added baseline includes from my whm XML (return rules, equip locks, etc).
    FPS: 27.5 - 27.7

    ~Conclusion 6: Baseline includes have minimal impact.

    14a) Changed <if> checks to Spell="*Jig".
    FPS: 28.5

    14b) Changed <if> checks to Spell="Spec*".
    FPS: 28.4

    ~Conclusion 7: Wildcards have similar impact to long OR blocks when the match is at the end. The location of the wildcard doesn't seem to matter much.

    15) Changed Spell="Spec*" to advanced='Regex("%Spell", "Spec.*")'.
    FPS: 27.5

    ~Conclusion 8: advanced regexes are slower than wildcards.

    16) Activated <equip> commands again. Changed to a direct equip of <head>Walahra Turban</head> instead of a set reference. Removed baseline includes. <if> rule is MainJob="Drk".
    FPS: 27.9 (note: after clearing vars, 26.1 - 26.9)

    ~Conclusion 9: Direct equips are faster than set references. Set1 with the same config was 25.9, and set50 was ~15.

    17) Added 50 variables (aset1 through aset50) before TestingFPS. Changed <if> tests back to using the advanced check. <equip> commands remained the direct equips.
    FPS: 25.1 - 25.9

    ~Conclusion 10: Variables introduce lag the same way that sets do. Implies that every check on the value of a variable has to go through the sequential list?

    17a) Changed aset variables to zset so that they'd be alphabetically after TestingFPS.
    FPS: 24.6 - 25.5

    ~ Checked sc var list and found that the zset vars were added to the aset vars, and that there were also vars leftover from the baseline include tests.

    18) Cleared var list and checked again.
    18a) zsets
    FPS: 26.4
    18b) asets
    FPS: 24.4 - 26.2

    ~Conclusion 11: Variables are probably sequentially searched. The more variables, the more lag.


    Analysis:

    Until the Spellcast thread problem is figured out, the best way to improve things is speeding up the XML itself.

    Whm XML has 44 sets, 31 <if> checks (not counting <elseif>, <else>, or baseline includes), and 43 <equip> commands. Not all <if> checks will be encountered in each pass through.

    Since all triggers used are filtered by type="Trigger", trigger rules should have basically no impact on standard spells.

    There are up to 5 <equip> commands issued per spell (not counting aftercast, which is deferred), either referencing sets or explicitly set in the rules, though most use just 2 or 3 (cures will tend to have 3). <equip>s are always evaluated immediately.


    There are 148 variables defined when I load my whm xml. More may periodically accumulate from other job XMLs. This seems likely to be the heaviest source of lag.



    Streamlining:

    Remove wildcards wherever possible. Even short sets of OR conditions should generally be faster. EG: "Raise|Raise II|Raise III", rather than "Raise*"

    Put most common results first in an OR list. Also try to order it so that least number of characters are checked in worst case. EG: "Raise III|Raise II|Raise" (12 characters checked for "Raise") rather than "Raise|Raise II|Raise III" (22 characters checked for "Raise III").

    Do not create a gear set for any set that is not either used more than once, constructed from variables, or is an aftercast set. Enter it directly in the rules instead.

    Remove basesets where feasible.

    Minimize the number of variables used. Hardcode values where reasonable (eg: spell durations). Remove informational variables. Possibly use regexes to check for variable existance rather than testing variable values (eg: obis).




    I'll be putting together a 'streamlined' version of my whm XML, and make the pastbin versions available as direct links (they won't show up in the normal list). Would appreciate it if anyone having problems with the lag could help test them out.

    Pastes:
    http://pastebin.com/hvh1Ennr
    http://pastebin.com/65PdAA0r
    http://pastebin.com/NKA0uXin



    Preliminary results with Cure II:
    Default: 25.3 - 26.9
    Streamlined: 27.8

    Haste spell:
    Default: 27.1
    Streamlined: 28.0

    Implying it sped things up by at least a third.

  9. #129
    CoP Dynamis
    Join Date
    Mar 2006
    Posts
    252
    BG Level
    4
    FFXI Server
    Phoenix

    yeah, I've spent the last couple of hours trying a bunch of stuff as well. My garbled notes are in the spoiler below. I was disappointed to find that the results of rule removal appeared to be linear as well and that it didn't seem to be centered around a specific type of rule. This seems to imply that right now "more complexity = more lag" which is really a bummer since your XMLs are the best around imho.

    I'll test out your streamlined ones asap.

    Spoiler: show

    /ma sneak shizune
    - brief freeze with 22fps displayed. .
    drops to around 10fps if i spam it while running around in sauro

    /console input /ma sneak shizune
    - no lag whatsoever

    /console input //sneak shizune
    - same as above

    /console input /ma "Regen III" <stpc>
    - brief freeze with 22fps displayed. nasty 10fps lag if i spam it. happens upon target confirmation

    /console input //regen3 <stpc>
    - lag

    removed all rules, lag went away completely

    removed all non-include rules (left in conditionals that contained includes).
    problem seems very slightly less severe, can't get fps to 10 as easily

    gradually removing more and more rules seems to have a relatively linear effect on the reduction of the freeze

    logged out 3rd char, no effect


    Just one thing though, do you not get the outrageously low FPS bursts when spamming spells? To add a bit to why this has really been a problem, when the freeze occurs while using an stpc spell (suppose a '//cure5 <stpc>' variant), the lag spike that follows actually consumes the tab press that would ordinarily select the target, leaving you to cure yourself.

    ie, with this sequence of events:
    alt0 (for the above macro)
    tab (to the target player)
    enter key (to confirm player)
    The tab doesn't get registered since the freeze occurred at that point. It's pretty nasty.

    Quote Originally Posted by Motenten View Post
    I'll be putting together a 'streamlined' version of my whm XML, and make the pastbin versions available as direct links (they won't show up in the normal list). Would appreciate it if anyone having problems with the lag could help test them out.

    Pastes:
    http://pastebin.com/hvh1Ennr
    http://pastebin.com/65PdAA0r
    http://pastebin.com/NKA0uXin



    Preliminary results with Cure II:
    Default: 25.3 - 26.9
    Streamlined: 27.8

    Haste spell:
    Default: 27.1
    Streamlined: 28.0

    Implying it sped things up by at least a third.
    I tested your var cleanup. My base FPS was also 29.4. With the rev3 I just downloaded and filled in today, casting '//cure2 <stpc>', I got an average of 18.05 FPS over 9 samples. With the version of the files quoted above, my 9-sample average was 19.95, so it's about 10% faster. Still obviously freezing pretty bad for me but I think I may just have to temporarily disable some of the features until Spellcast3 comes out. The odd thing is I don't remember being hit by this so bad at all until the recent update; hard to believe I wouldn't have noticed it because I'm failing cures pretty often now due to the freezing.

    I do really appreciate you taking the time to look into it though, I know your hands are mostly tied here.

    edit: sorry for post spam

  10. #130
    An exploitable mess of a card game
    Join Date
    Sep 2008
    Posts
    13,258
    BG Level
    9
    FFXIV Character
    Gouka Mekkyaku
    FFXIV Server
    Gilgamesh
    FFXI Server
    Diabolos

    Quote Originally Posted by Motenten View Post
    16) Activated <equip> commands again. Changed to a direct equip of <head>Walahra Turban</head> instead of a set reference. Removed baseline includes. <if> rule is MainJob="Drk".
    FPS: 27.9 (note: after clearing vars, 26.1 - 26.9)
    Was this tested using more than one set? I imagine multiple <equip>s prefer sets.

    There are 148 variables defined when I load my whm xml. More may periodically accumulate from other job XMLs. This seems likely to be the heaviest source of lag.
    <variables clear="true"> would flush the variables properly?

    Remove wildcards wherever possible. Even short sets of OR conditions should generally be faster. EG: "Raise|Raise II|Raise III", rather than "Raise*"
    Is there a point where this ceases to be true?

    Do not create a gear set for any set that is not either used more than once, constructed from variables, or is an aftercast set. Enter it directly in the rules instead.
    Wouldn't most sets be used more than once?

    Possibly use regexes to check for variable existance rather than testing variable values (eg: obis).
    ???

  11. #131
    Chram
    Join Date
    Sep 2007
    Posts
    2,526
    BG Level
    7
    FFXI Server
    Fenrir

    Quote Originally Posted by Yugl View Post
    16) Activated <equip> commands again. Changed to a direct equip of <head>Walahra Turban</head> instead of a set reference. Removed baseline includes. <if> rule is MainJob="Drk".
    FPS: 27.9 (note: after clearing vars, 26.1 - 26.9)
    Was this tested using more than one set? I imagine multiple <equip>s prefer sets.
    It was tested against set1 and set50, if that's what you mean. If you mean <equip set="set1|set50" />, then no.

    Quote Originally Posted by Yugl View Post
    There are 148 variables defined when I load my whm xml. More may periodically accumulate from other job XMLs. This seems likely to be the heaviest source of lag.
    <variables clear="true"> would flush the variables properly?
    Yes, it would. I'll be adding that to all my XMLs. However for this tally, it was after an "sc var clear" and then reload, so there were no spurious variables in the count.

    Quote Originally Posted by Yugl View Post
    Remove wildcards wherever possible. Even short sets of OR conditions should generally be faster. EG: "Raise|Raise II|Raise III", rather than "Raise*"
    Is there a point where this ceases to be true?
    Almost certainly, however the FPS check isn't accurate enough for me to really be able to tell when. However the OR'd case that I'd tested had 27 (26 single letters + Drk) values, while the wildcard only had 1 value to test. Even if we assume it's only related to the character count and not the value count, it seems a wildcard could be the equivalent of up to 40-50 characters.

    Quote Originally Posted by Yugl View Post
    Do not create a gear set for any set that is not either used more than once, constructed from variables, or is an aftercast set. Enter it directly in the rules instead.
    Wouldn't most sets be used more than once?
    Most, yes, but not all. For example, sets that boost JAs (eg: Temple Crown for Focus) are only ever going to be used to augment that specific JA. You don't really need an entire set for it, and certainly don't need it to add to the search length of every other lookup you make.

    Quote Originally Posted by Yugl View Post
    Possibly use regexes to check for variable existance rather than testing variable values (eg: obis).
    ???
    You can test for a variable's existence with:

    <if NotAdvanced='Regex("$VariableName", "^[$]")'>

    If a variable isn't defined, its 'value' is equal to its name, including the leading $. Since it's nonsensical to have a variable value that includes a $ at the beginning (meaning you really expect it to be further expanded), you can test for its existence using the regex to find out if the variable exists at all.

    So instead of:
    Code:
        <var name="Obi-Fire">0</var>
        <var name="Obi-Ice">0</var>
        <var name="Obi-Wind">0</var>
        <var name="Obi-Earth">0</var>
        <var name="Obi-Thunder">0</var>
        <var name="Obi-Water">0</var>
        <var name="Obi-Light">Korin Obi</var>
        <var name="Obi-Dark">0</var>
    
    ...
    
        <if advanced='"$Obi-%spellElement"!="0"'>
            <equip when="midcast">
                <waist>$Obi-%spellElement</waist>
            </equip>
        </if>
    I can have:
    Code:
        <var name="Obi-Light">Korin Obi</var>
    
    ...
    
        <if NotAdvanced='Regex("$Obi-%SpellElement", "^[$]")'>
            <equip when="midcast">
                <waist>$Obi-%spellElement</waist>
            </equip>
        </if>

    The <if> check is a bit slower, but the removal of 7 dummy variables should outweigh that. Of course if you have most or all of the obis you end up slightly penalized, so eventually will need to be tweaked.

  12. #132
    Chram
    Join Date
    Sep 2007
    Posts
    2,526
    BG Level
    7
    FFXI Server
    Fenrir

    Quote Originally Posted by suji
    Just one thing though, do you not get the outrageously low FPS bursts when spamming spells? To add a bit to why this has really been a problem, when the freeze occurs while using an stpc spell (suppose a '//cure5 <stpc>' variant), the lag spike that follows actually consumes the tab press that would ordinarily select the target, leaving you to cure yourself.
    Unfortunately (fortunately?), on my system, no, I don't get lag that bad. In some scenarios there are noticeable hiccups, but any loss of target is due to gear suddenly blinking (ie: the target blinked, but I couldn't immediately tell due to the lag), not to the lag itself.

    Quote Originally Posted by suji
    -brief freeze with 22fps displayed. nasty 10fps lag if i spam it. happens upon target confirmation
    Yes, good point to note. For sch in particular, the lag is worst when I hit the confirmation for a selection. Should also note that it's not as bad when I use <stpt>/<stal> compared to <stpc>, and none at all if I manually type in the command like "//cure5 mote".

    Quote Originally Posted by suji
    I tested your var cleanup. My base FPS was also 29.4. With the rev3 I just downloaded and filled in today, casting '//cure2 <stpc>', I got an average of 18.05 FPS over 9 samples. With the version of the files quoted above, my 9-sample average was 19.95, so it's about 10% faster.
    Well, more accurate to say that it reduced the lag by about 17%. But yeah, not quite as good as I'd hoped. Will have to see if I can find other ways to improve things.

  13. #133
    CoP Dynamis
    Join Date
    Mar 2006
    Posts
    252
    BG Level
    4
    FFXI Server
    Phoenix

    Quote Originally Posted by Motenten View Post
    Unfortunately (fortunately?), on my system, no, I don't get lag that bad. In some scenarios there are noticeable hiccups, but any loss of target is due to gear suddenly blinking (ie: the target blinked, but I couldn't immediately tell due to the lag), not to the lag itself.
    Just to answer the semi-implied conjecture here, the target loss I'm seeing is not due to blinking. I keep BMN on for all categories on my mule. The freeze really eats the tab key press.

  14. #134
    An exploitable mess of a card game
    Join Date
    Sep 2008
    Posts
    13,258
    BG Level
    9
    FFXIV Character
    Gouka Mekkyaku
    FFXIV Server
    Gilgamesh
    FFXI Server
    Diabolos

    Quote Originally Posted by Motenten View Post
    It was tested against set1 and set50, if that's what you mean. If you mean <equip set="set1|set50" />, then no.
    Thanks for the quick replies. For this question, I meant to ask whether you tested more than one direct equip compared to an entire set.

    Most, yes, but not all. For example, sets that boost JAs (eg: Temple Crown for Focus) are only ever going to be used to augment that specific JA. You don't really need an entire set for it, and certainly don't need it to add to the search length of every other lookup you make.
    Interesting idea: Make a non-inherit group used for precast JAs to reduce the search perhaps?

    You can test for a variable's existence with:

    <if NotAdvanced='Regex("$VariableName", "^[$]")'>
    If a variable isn't defined, its 'value' is equal to its name, including the leading $. Since it's nonsensical to have a variable value that includes a $ at the beginning (meaning you really expect it to be further expanded), you can test for its existence using the regex to find out if the variable exists at all.
    Good idea.

  15. #135
    CoP Dynamis
    Join Date
    Mar 2006
    Posts
    252
    BG Level
    4
    FFXI Server
    Phoenix

    Quote Originally Posted by Yugl View Post
    Interesting idea: Make a non-inherit group used for precast JAs to reduce the search perhaps?
    I'm not sure I understand what you mean. If the set were available to be used in JA rules, wouldn't it have to be searchable in the set list and thus contribute to set searching delays? Faster still would be to just cover this in the JA rules section with explicit equip rules for each JA, right?

    On a related note, should one expect when="all" to perform worse than a specific stack specification (when="precast", for example)? I don't know how this stuff is evaluated under the hood, but it seems that the stack-based gear sets are collected and subsequently collapsed, so perhaps the use of when="all" could add unnecessary work in the collapsing algorithm because there would be redundant entries in the stack layers?

  16. #136
    An exploitable mess of a card game
    Join Date
    Sep 2008
    Posts
    13,258
    BG Level
    9
    FFXIV Character
    Gouka Mekkyaku
    FFXIV Server
    Gilgamesh
    FFXI Server
    Diabolos

    If sets are searched within respective groups, then you can limit the group of precast JAs to a single group and reduce the searching process.

    ex:
    <equip group="Precast-JA" set="%Spell" />

  17. #137
    CoP Dynamis
    Join Date
    Mar 2006
    Posts
    252
    BG Level
    4
    FFXI Server
    Phoenix

    Oh cool, didn't know. Thanks!

  18. #138
    Chram
    Join Date
    Sep 2007
    Posts
    2,526
    BG Level
    7
    FFXI Server
    Fenrir

    Quote Originally Posted by Yugl
    Interesting idea: Make a non-inherit group used for precast JAs to reduce the search perhaps?
    Hmm. Interesting indeed. If I didn't have area-based groups, I'd take that idea and run with it. Have one group for all weaponskill sets, one group for casting sets, one group for PDT sets, and leave the default group for idle/TP sets. Drop from 30-70 sets in the main group to ~10 per specialized group, would speed things up a lot.

    As it is, I use the area-based groups for almost nothing. Technically it's feasible, but in reality there's almost nothing that I actually find them useful for. Some items with latents, maybe. The handful of items I do separate out, I could usually just as easily do with set variations.

    One could even still incorporate area-based rules on a more selective basis (instead of the mass usurpation that's presently used). For example:
    Code:
    <if advanced='"$Area"="Abyssea"'>
        <equip group="Abyssea-Weaponskills" set="%Spell" />
    </if>
    <else>
        <equip group="Weaponskills" set="%Spell" />
    </else>
    That way you could break things down a bit more. Maybe still keep the "Abyssea-Group" type groups for the default TP/idle stuff.


    Unfortunately, it still needs to be tested. If you have 10 groups with 10 sets each, and search for the 10th set in the 10th group, will it have to search through 10 groups and then 10 sets (20 total), or through all 100 sets (ie: is the group information hierarchical or flattened)?

  19. #139
    An exploitable mess of a card game
    Join Date
    Sep 2008
    Posts
    13,258
    BG Level
    9
    FFXIV Character
    Gouka Mekkyaku
    FFXIV Server
    Gilgamesh
    FFXI Server
    Diabolos

    Tested groups:
    ~20 G1 S40 (G1-S40)
    ~18 G40 S1 (G1-S40)
    ~18 G40 S1 (G1-S1)
    ~28 G2 S1 (G1-S40)

    G: Group
    S: Set
    Parenthesis: Number of sets within Group 1

    Looks as if SC sequentially checks groups the same way as sets, but doesn't seem to run through the sets of each group. So if you make groups to split the sets up, you should run faster.

  20. #140
    Chram
    Join Date
    Sep 2007
    Posts
    2,526
    BG Level
    7
    FFXI Server
    Fenrir

    Interesting. So now it's a question of whether to scrap the [area]-groups entirely, and just build things on general category of action.

    Actually... I think I may do it like this instead:

    Code:
        <var name="Options.AreaGroups">None</var>
        or
        <var name="Options.AreaGroups">Abyssea|Legion</var>
        etc
        
        
        <var name="GroupArea">None</var>
    
    
        <if advanced='Regex("$Area", "$Options.AreaGroups")'>
            <var cmd="set GroupArea $Area" />
            <if notgroup="$Area-Group">
                <!-- set the default group -->
                <command>sc group $Area-Group</command>
            </if>
        </if>
        <else>
            <var cmd="set GroupArea Outside" />
            <if notgroup="Outside-Group">
                <!-- set the default group -->
                <command>sc group Outside-Group</command>
            </if>
        </else>
        
        
        <equip group="$GroupArea-Casting-Group" set="FastCast" />
    That way you can specify which alternate groupings you have. Most of mine have a half-dozen groups that aren't used for anything, but I can see how they -could- be useful to some people, so don't want to get rid of them entirely. The above would allow for that, while also simplifying things a great deal for most people.

+ Reply to Thread
Page 7 of 12 FirstFirst ... 5 6 7 8 9 ... LastLast

Similar Threads

  1. Replies: 6547
    Last Post: 2014-07-08, 22:45
  2. ongoing attendance thread
    By berticus in forum FFXI: Everything
    Replies: 77
    Last Post: 2005-02-21, 09:55
  3. Wiffleball 2.0 [ Dynamis Attendance thread ]
    By Medic in forum FFXI: Everything
    Replies: 1
    Last Post: 2004-08-15, 21:30