OK, I've made some tests and to me it seems that the original code is faster, when defining fast search you are using RoughBlockSearch method, which IMO is slower than a simple for each AllThinkers cycle. Because searching rough blocks uses methods inside the core of the engine that are bigger cycles and more heavy to execute, I'm not completely sure that the code is wrong, it could be optimized, but it will require further work and testing... so I would say to leave this like it was, but don't scrap this test, it could turn out to be faster somehow.

Now, another thing we could do for this purpose is to upload two internal test versions, so anyone else beside CW and me could test both and see which works faster, it's worth the try IMO, but I don't know what others think about this.

I guess it may be a bit more complicated. AllThinkers iterator may work slower on the maps with huge amount of items, while Radius iterator and BlockSearch will work slower, perhaps, in places with lots of sectors around. Maybe that's why new algoithm is generaly faster on Cathedral map and seems to be same or even slower on most of other maps.

I don't think two versions of KA needed, I suggest we stick to an old one instead. This search thing needs more work.

Now that you mention it, it's true, on smaller maps things run faster using the new algorithm... we'll need to come up with something in the middle of both (or use both in special cases each).

Yeah, I was thinking about some kind of map-specific coefficient that takes map size/complexity and amount of items around into account. But that would be too complicated in my opinion. And besides I'd rather stick to some generic algorithm.

Actually I am thinking is it possible to make something like UT2004 has. I read some of the documents on occasion, and found out that in UT they made all important items a subclasses of navigation points. So now I am considering of simulating something similar.

Regarding DoomBuilder 2. I found the reason it cannot work with our custom acc.exe. It is because DB2 tries to send it parameters old acc does not support (include paths).
There are 3 ways to solve this.
1) Get latest acc source code that support include paths and make a new custom acc based on it.
2) Make DB2 author give a way to configure acc usage so that DB2 won't use this advanced parameter.
3) Actually use common acc, but changing all our new actions special numbers to those below 256.
According to my calculations, there are 52 (fifty-two) free numbers below 256. That's quite enough for KA, and I guess may be enough for KRPG.
Currently KA has about 15 new specials, but not all of the are useful (some were created rather "just in case"), I can make a revision there and remove maybe 5-7 of them. But I was planning to add 6 more for working with Objectives for advanced game modes.
KRPG has 7 specials for controling weather (particle system), and 20 for controlling monsters (tasks), plus few generic ones.
There's a risk though, that these numbers or some of them will be taken in use by some future versions of our engine. But nobody knows when and which.
In this case we also will have to recompile scripts in ALL our maps (thirty minutes task, maximum).

Which do you find best?

Well, 1st and 3rd are a matter of time to make corresponding changes only. 2nd variant is rather a compromise, but also it has least chance to happen, because it requires DB2 creator to add certain features to his application, which he might not want to do.

1st is most safe in my opinion, because we won't have to redo anyhing in our old material if engine has any changes to action special numbers. What I mean, it is not rather problem of amount of free numbers, but possibility of conflict.

So I'd rather stick to 1st, that is to get newest acc code and copy changes I made to an old one. But I yet have to know where I can get one.

I think 1st is the best too, as for where to find the source, IIRC this change comes from ZDoom, so you can find the ACC source on the ZDoom site, it would also be nice if you could notify Janis about that, so that the code gets added to ACC source of Vavoom engine, and that later we can use that to build our version of ACC to avoid further problem with the engine .

You mean creating our own ACC distributable for KA/KRPG?

We already distribute one.

So, are we going to release this anytime soon? I feel shame again, Firebrand promised it is coming "round the corner" and yet...
Is there anything needed to be fixed/coded there?

That's why we should not do this kind of news. Posting something actually implemented every few weeks would be informative and keep people interested, promising something and not delivering for the 10th time is not.

That's why I refrained from even mentioning KRPG much in public, I think it'd be a good change to simply release something out of the blue this time instead of just saying we will and never actually do it.

At any rate, as always with releases that should be out by a certain point in time, just cut out/disable everything that's not working flawlessly yet and release it with the rest.

What I am personally still waiting for is the rest of the descriptions to finish up the PDF manual, but that's not a reason to delay 1.1.

Oh and I am still planning to put out KRPG's first public beta this year. Depends of course on how much time you have to do the necessary stuff (for the alpha, we mostly need code, the maps are ready to go except for linking them to the travel map, for beta it's mostly optimizing maps and adding more code, all kind of artwork we have is sufficient for a beta test).

The point is I guess to rather release stuff "too early" and fix things afterwards, this is how today's commercial games work so why does a free mod need higher quality standards?

I'm working slowly on newer maps for KA, but I'm taking too long, apparently...

OK, let's release it as it is now and we'll make a new mappack ASAP.

Internal build first, so that we could test everything just in case. Maybe there are some little flaws here and there.

Any ETA on the internal build?