I am not sure I follow you. The base FLHook does not even use the overloaded call for swprintf where you also pass the buffer length. There are only a few calls which use sizeof and I agree that they are problematic.

I think he just forgot. The calls are mostly correct and use wsclen stuff, but on a few occasions it is indeed sizeof, which gives double the count. Shouldn't be that bad, though, because of the formatted texts being short in those cases (just had a glance at it).

Hehe, no need to be

I create this topic so that one can post things he noticed in the SVN version.

While catching up with current development (last time I checked was about a year ago) I noticed some things.

While things like only tend to question my sanity (Edit, since it seemed to be unclear: I don't often see static variables plus write too much other languages to remember it, thus it took some time to see it. I am still debating with my self whether I think its good practice and currently am leaning against it.) , here is a rather serious bug:
of SpawnSolar is breaking the stack. You are missing at the end, since this is a call where you have to do the cleanup yourself.

I also would suggest surrounding it with pushad and popad, since in case you add more code which leads to using registers the subroutines change, this could also lead to strange behaviour. Also you notice immediately if the stack is broken, since you get a crash. The corrected version thus looks like:


It took me around an hour to get suspicious, as my code started to behave oddly. So please, while this is really cool stuff (bases have visible loadouts now etc, yay!), do a double check or tripple for at least the asm stuff. I know I am a perfectionist and thus easily annoyed by such stuff, but I think this is really worth it

If I find more stuff I will post it.

Could be a Lazarus related issue. I compiled it with the newest version (1.0.8). But neither Skotty nor me can reproduce this bug. Which Windows version do you have?

That one above was solved a while ago ^^

I have uploaded a new version (see first post):


I must say you guys must all have used the best way of creating surs, otherwise at least one would have noticed the bug? I've gotten as many as one triangle out of a converted mesh I created with just a poly reducer. The other around 2000 just got "lost" Just a simple fix, though (used wrong array).

I've also added a simple mass conversion option for non multipart meshes. For those a special config file for each source is needed to be implemented.

Using the median instead of the mean value for the target crosshair is much more robust against outliers. The automatic calculation should now yield much better results.

If you find any bugs, please post them.

No. (in regard to the first question of the op).