So, addressing the idea that FFXI's native macro/wait system accepts decimal waits in increments of 0.5.
Test methods differ somewhat from last time. I will be using lua via gearswap and the os.clock() function to check the time. This is very precise compared to my prior timestamp based test.
The involved code:
Code
if command == 'test' then
timeStart = os.clock()
message('Start:'..timeStart..'')
end
if command == 'test2' then
timeEnd = os.clock()
timeSeconds = timeEnd-timeStart
message('End:'..timeEnd..' delay:Secs '..timeSeconds..'')
end
Test 1. Measure the base delay of going from one macro line to the next.
Macro structure.
Code
/con gs c test
/con gs c test2
Results copied from logger logs.
Code
04:38:31Start:332165.66
04:38:31End:332165.695 delay:Secs 0.035000000032596
04:38:33Start:332167.123
04:38:33End:332167.161 delay:Secs 0.038000000000466
04:38:34Start:332168.482
04:38:34End:332168.515 delay:Secs 0.032999999995809
04:38:37Start:332171.44
04:38:37End:332171.473 delay:Secs 0.032999999995809
04:38:45Start:332179.226
04:38:45End:332179.261 delay:Secs 0.034999999974389
04:38:46Start:332180.722
04:38:46End:332180.756 delay:Secs 0.033999999985099
So, a 2 line macro generally incurs a delay of 0.032~.
Test 2. Does a <wait x> work when placed after /console in a FFXI macro? If it doesn't, additional macro lines will be needed, and the extra delay will need to be accounted for.
Macro.
Code
/con gs c test <wait 3>
/con gs c test2
Results.
Code
04:43:36Start:332470.944
04:43:39End:332474.005 delay:Secs 3.060999999987
04:43:42Start:332477.058
04:43:46End:332480.122 delay:Secs 3.0639999999548
04:43:48Start:332482.842
04:43:51End:332485.904 delay:Secs 3.0619999999763
So yes, a <wait x> will work after a /console. Which... honestly, is really weird. It's also interesting that the extra delay was 0.06 on a 2 line macro rather than 0.03. Maybe using a <wait> incurs an extra line worth of delay? But that's an issue for another time.
So, onto the main thing.
Test 3. Try using a 0.5 wait.
Macro.
Code
/con gs c test <wait 0.5>
/con gs c test2
Results.
Code
04:49:05Start:332799.908
04:49:05End:332799.941 delay:Secs 0.032999999995809
04:49:07Start:332801.846
04:49:07End:332801.879 delay:Secs 0.032999999995809
04:49:09Start:332803.343
04:49:09End:332803.375 delay:Secs 0.032000000006519
04:49:10Start:332804.939
04:49:10End:332804.973 delay:Secs 0.033999999985099
This is no different than the original control. The 0.5 wait is being floored to 0.
Test 4. use a wait of the same duration(0.5) but a differnt format. That being .5(leaving the 0 off)
Macro.
Code
/con gs c test <wait .5>
/con gs c test2
Results
Code
04:49:31Start:332826.052
04:49:32End:332827.106 delay:Secs 1.0540000000037
04:49:45Start:332839.721
04:49:46End:332840.776 delay:Secs 1.054999999993
04:49:48Start:332842.406
04:49:49End:332843.46 delay:Secs 1.0540000000037
Interestingly, a .5 wait(rather than 0.5) is rounded up to a 1 second wait. I guess when you use a 0 at the start, it just stops reading the number after that. I'm not going to list the data for it, but I tried a .3 as well, and it still changed to a 1 sec delay. So it's not as if it's actually rounding based on the value.
Conclusion.
Decimal waits, including increments of 0.5, do NOT work in FFXI's wait/macro system.
If you need a decimal delay, you need to use scripts, or gearswap, etc. Cause FFXI itself won't have it.