this sounds to be something that isnt quite that handy to be honest wed already has a built in version of this, and an automated process? how are we supposed to know were our vertexes will end up in that case? it just doesnt sound all that useful.

not handy?? he's trying to create a solution to the 1 point snap error thats caused by the integer value. It can be a pain because 1: it creates an ugly line accross the block and 2: In certain places, physics objects can SNAG to these seams.

How does this tool actually snap the block together, just edit the positions in the wmp file? Do they overlap? I mean, in certain occassions overlapping blocks is actually faster than placing blocks next to eachother with perfect precision (builds faster, less portals etc.)

A tool or possible (future) feature of your tool that would be very useful to me, as long as bsp is around, is turning none visible levelblock faces into 'none' surfaces .. This is something that usually takes a lot of precious time, eventhough it can be done faster if done right from the start off course, but still ...

Edit: Btw, will this tool work with the recently released A6.50.2 update?
Edit: Btw2, eventhough it's perfectly fine with me posting this in showcase II, since you promised screenshots and I think a demonstration, shouldn't this be in tools?

Cheers

I debated about putting it in tools but because this is will have a demo this looked like the place to put it at the time.

How this tool works is by ajusting the vertex coordinants of all verteces in the level. It makes no attempt to align blocks but instead fixes the one quant error mentioned above by stansmedia. The report that is generated at the time of the processing lets you check to make sure that the movement was in the right direction. You may end up with a gap but you can quickly find the gap by using the find object functionality in WED. If it moved in the wrong direction then you can use the move face to move the offending face back into alignment.

The one quant error is real and the only way to fix them is to use the move edge and/or move face and/or move vertex with a one quant snap on each and every face/edge/vertex in the level. Even this may still leave some non-integer values in the WMP file. This program will process the WMP file like the map compiler so that the vertex coordinates are at exact integer values.

The options for using snapping to other values than 1 are for more advanced processing that will fix major alignment issues so that you can really slap a level together and have it come out looking good. For example if you used the vertex round at 16 and had walls that were 16 thick then they would be put at exact multiples of 16 throughout the level.

As for your sugestion to the texture none problem that will be a future tool (it was alread on the list).

Stansmedia:
The tool is already created and tested. I just need to get the web site fixed with the problem being having to wait on third party providers to get there part installed.

Thanks for the extra information, good luck getting your website fixed and stuff,

Cheers

well i guess i dont get it... wed automatically snaps anyways so whats the problem, what does this fix?

WED snap works as expected but not as needed by the map compiler. open a wmp file and you will see mostly non-integer values in the vertex addresses. The map compiler will convert these to integers. this leads to gaps and visible seems. The main reason for this is that move is based on the center of the block.

Would be interesting what jcl and co says about this tool...

it still will make gaps tho cuz i remember at one time i wrote a program that would turn a terrain into a terrain made of blocks, all integer-based and it still didnt close the seams....