SolarStrike Software

I'm using a simple tag based waypoint to navigate to the correct location: guild = api:GetGuildInfo() __WPL:setWaypointIndex(__WPL:findWaypointTag(guild)) and then have a tag="guild" for each guild I run in as location of buildings are different, then I do a findNearest.. as above to open...

Great, thx Rock

-dx

P.S. Works as a charm with the re-set the next waypoint code.

Na, this is just a small waypoint where I've isolated the bug - I seen this issue in big waypoints where points are way apart.

-dx

I'm using a simple tag based waypoint to navigate to the correct location: guild = api:GetGuildInfo() __WPL:setWaypointIndex(__WPL:findWaypointTag(guild)) and then have a tag="guild" for each guild I run in as location of buildings are different, then I do a findNearest.. as above to open ...

When I run a waypoint file it gives me a message about which waypoint is closest and executes it before moving on to next in file as expected. Loaded waypoint path tt.xml No return path with default naming tt_return.xml found. We use the normal waypoint path tt.xml now. Waypoint #2 is closer then #1...

Any1 know the flag to determine if a guild gate is open or closed?

-dx

Ye I don't know either, I added a timer function to freeze the memory locations and kept right on flying as it should.

Seems some operations overwrite the fly flags somehow.

-dx

Whenever I make a transport point in client with the fly function active the characters stops flying and falls down, any idea about why?

-dx

Upgraded to 1.03, seems this bug is present there, must have leaked between releases

best regards
DX

Ye, even better

-dx

In skill.lua we have default value of self.TargetMaxHp set to 9999999, i.e. 9m HP.

This is getting to be to low for boss fights, we end up with a lot of [DEBUG] TARGEHP messages as target has more that 9m hp.

I recommend increasing default to ex 999m

-dx

Very nice debug option, will it make it into the std fastlogin?

-dx

Lol I normally agree but having issues w. compiling addons for Lua 5.2 like SQL interface, so until thats done Im stuck backlevel.

-dx

For 5.1 users I found a backport http://smbolton.com/lua/lbitlib-5.2.0-alpha-backport1.c, I've made an .dll of it and tested and it works flawlessly.

-dx

For us still stuck with "old" micromacro this doesnt work, among other things u use the bit32 which is a Lua 5.2 feature.

-dx

Agree, need support for both versions.

-dx

Well, the lock might be stale if a process gets killed while holding the lock, its a rare event but might happen. Another way would be to put in a timer and remove lock if its not gone in 60s, assuming all multi-login sequences will be faster than that. Assuming a login uses 10s this leaves room for...

New locking, take 2 :) -dx local function lockdir(lockPath) return (os.execute("mkdir "..string.fixPath(lockPath, false).." 2> nul") == 0) end local function unlockdir(lockPath) os.execute("rmdir "..string.fixPath(lockPath, false)) end local function setTimeout(pidPath)...

No matter how u twist and turn it u cant make a locking mechanism in Lua file module, its simply not atomic and u will get race condition, u can make the chances small but not remove them totally. The mkdir/rmdir Windows commands (and underlying api) are atomic on the other hand, they either fail or...

There is a race condition in the window reservation which results in random login failures, particularly when starting multiple windows simultaneously. This is due to the reserveActiveWindow() using a "check file" loop followed by a make file which is absolutely not atomic, ie two logins c...