Quake3World

Since q3map 2.5.16, aas file can be reattached to different bsp.
Below is a step by step procedure to make it work.

1. create an original map file(let's call it "original.map") and fully bake it(bsp,vis and light)
2. copy the "original.map", open it in radiant then remove unnecessary geometry, adding spoofing brushes and uncheck autoclipping for mapobjects, etc... then save as "orignal_b1.map"
3. bake "original_b1.map" (only bsp, no need to append "-meta")
4. create bot file("original_b1.aas") for "original_b1.bsp" with the switch "-bsp2aas", no need to append "-forcesidesvisible"
*warning* DO NOT OPTIMIZE HERE!
5. rename "original_b1.aas" to "original.aas"
5. run q3map2 with the switch -fixaas "PATH_TO_original.bsp" (now "original.aas" has been fixed and broken again)
7. download aasfix2 then fix the aas again.
8. now run bspc again for "original.bsp" with the switch "-reach"
9. finally optimize the aas with the switch "-aasopt"
10. play with heavily optimized bots

I prepared a quick sample map for -fixaas.
This is a rough cut, so more sophiscated version may come later.
Sample map for -fixaas

What I've noticed so far(might be wrong):
1. Botclip doesn't necessarily have to be aligned to the geometry for human players; it can go both below and above as long as they won't exceed excessively.
.
2. Map runs faster with this fixed aas!

3. Some entities need to be "suspended" depending on the place where they are laid.

Nice post, several people have had trouble getting this working so it's good to have a step by step guide and some pointers!

Cool I will have to test this, I could not get it working before.

Back later with results.
Sims

Great write up and great timing too since a lot of people have been asking about this. Much better than some of your more "elaborate" topics.

a13n wrote:2. Map runs faster with this fixed aas!

It's not specifically faster because of reattaching the AAS file. It runs "faster" because the AAS is optimized better so when loading bots, there is less information to process. You could theoretically do the same in the original map. What -fixaas solves is it allows you to compile an AAS for a map that could normally cause BSPC compile errors.

a13n wrote:7. open original.aas in a hex editor and change the first 4 byte to 45 41 41 53, namely "EAAS", overwrite the file

Curious, why is this step necessary? What exactly is going on here? What happens when you skip this step?

@everyone
Thank you.

@Shallow
If only the readme file of q3map2 had told us more and q3map2 itself had done a little more.
More than 2.5 years of waste since the release of 2.5.16.

@sock
from http://splashdamage.com/forums/viewtopic.php?t=10278

ydnar wrote:Q3Map 2.5.16

Some stuff for Sock mainly.

:icon22:

@obsidian
Without "EAAS" bspc and quake3 don't recognize it as an aas.
It's apparently possible to automate from step 3 to 9 if q3map2 stops kidding or other small apps dare to have the trouble to write it instead.

a13n wrote: If only the readme file of q3map2 had told us more and q3map2 itself had done a little more.
More than 2.5 years of waste since the release of 2.5.16.

I'm not quite sure what that means, I guess.

What exactly has been "wasted" in the last couple of years? And what's with the rolleyes?

@pjw
Never mind, please.

By the way I succeeded to reduce the size of aas for q3dm6 and q3dm17 by about 150kb with quick hand work.(much more would be possible and there seems to be a lot of fun possibilities(such as spoofing cluster portals) with trial and error)
Bots seem to love it. :icon25:

I prepared a much more excessively optimized sample map for q3dm17.
The file contains "q3dm17_bot.map" and "q3dm17.aas".
The aas file is smaller than the official one by 1/2, so is the CPU/Memory usage.
Now bots don't go for porn/poker anymore. :icon25:

bots jump at the edge like human players where they had never!


experimental cluster spoofing for space maps(works like a way point)

Sorry for the delay getting back to this thread but have been busy testing the process and making sure what I got works. The original reason for this feature was so that I could create a bot file for Pyramid of the Magician but 2 years I could not get the process to work. At the time lots of things kept breaking and Pom was not a good example map to be testing with.

I found a slightly different approach to a13n and used 2 batch files to automate the process. These batch files could be merged into 1 batch file but I wanted to see the results of the bspc.exe process half way through.

Batch File 1:

@echo off
@set Q3_PATH="C:/Program Files/Quake iii arena"
@set COMP_PATH="C:/Program Files/Quake iii arena/q3map2/q3map2.exe"
@set BOT_PATH="C:/Program Files/Quake iii arena/q3map2/bspc.exe"
@set MAP_PATH="C:/Program Files/Quake iii arena/baseq3/maps/%1.map"

@set GEN_OPTIONS=-fs_basepath %Q3_PATH%

%COMP_PATH% -meta %GEN_OPTIONS% %MAP_PATH%
%COMP_PATH% -vis %GEN_OPTIONS% %MAP_PATH%

%BOT_PATH% -forcesidesvisible -bsp2aas %MAP_PATH%

This batch file is run on the bot only version of the map. It does a basic q3map2 compile (In theory could skip the -vis stage but it was so quick it did not really matter) and then does a normal BSPC compile. I had to use the -forcesidesvisible because all of the floor in my original map was terrain. I experimented with flat bot clip floors but the bots just spent most of their time floating above the terrain.

This first batch file should produce a working bot file but it is attached to the wrong map file. I manually renamed the AAS file to match the original map file but this process could be automated. I paused at this point because I wanted to see what cluster portal area's had been created and decide if I need to do anymore tweaks to geometry.

If the cluster portal arrangement was bad I would go back to the bot map file and tweak things a bit more. I removed all lights, terrain blending textures, non solid patches and models from the bot map file. I even removed all wall and floor detail and turned most rooms / corridors into huge flat caulk faces. Textures in a bot map file don't really mean much so most of my work was done with caulk.

One thing I did find with testing was the final AAS file was merged with original map geometry in game so you can force the bots to do certain things. When I removed all the wall brushes I thought the bots would just fall out of the map or fall into original map space but they did not. They would often beat themselves senseless against corners because they did not believe they existed but they did in game.

One problem I had with the bots was they would pull back while in the air after hitting a jump pads. In the original map file the brushwork in front of the jump pads was gradually sloped but the brushwork in the bot file was flat and the edge was a lot further back. This had an interesting effect because the bots then used the air control of the jump pad to move forward instead of back and then landed correctly. If they missed for some reason, the original map geometry was still there so they did not fall into the gap, but fell down and tried again.

Batch File 2:

@echo off
@set Q3_PATH="C:/Program Files/Quake iii arena"
@set COMP_PATH="C:/Program Files/Quake iii arena/q3map2/q3map2.exe"
@set BOT_PATH="C:/Program Files/Quake iii arena/q3map2/bspc.exe"
@set MAP_PATH="C:/Program Files/Quake iii arena/baseq3/maps/%1.map"

@set GEN_OPTIONS=-fs_basepath %Q3_PATH%

%COMP_PATH% -fixaas %GEN_OPTIONS% %MAP_PATH%
%COMP_PATH% -meta %GEN_OPTIONS% %MAP_PATH%
%COMP_PATH% -vis %GEN_OPTIONS% %MAP_PATH%
%COMP_PATH% -light -fast -samples 2 -pointscale 1.4 -patchshadows %GEN_OPTIONS% %MAP_PATH%

%BOT_PATH% -optimize -reach %MAP_PATH%

There are 3 problems with the -fixaas parameter as follows:

1. The compiler says the parameter is invalid, but yet still seems to work!
2. The -fixaas parameter trashes the light map (most of the time) in the original bsp file so you have to re-compile the original map again.
3. The bot AAS file has to have a newer date than the original bsp file so you have to end the process by optimizing the bot file so that it is regenerated and work correctly with the original bsp.

This is the part of the process which really is wierd, and was the main reason I gave up 2 years ago trying to get it working.

After a week of creating a new brushwork and pulling my hair out at stupid feckin-bot feckin-cluster feckin-portals, I do have a bot file for my original map Pyramid of the Magician. Once I hear back from some friends who are testing it, I will release the source files so people can see what I did.

Hope that helps
Sims

@sock
Your method looks different from mine in that you bake the genuine bsp afterwards.
With my method mappers don't have to re-bake the time-consuming genuine bsp again and again.
Instead they can devote themselves to create the fake bsp with trial and error once the genuine bsp has "gone gold".
You know which is better. :icon26:

But your method, if it works at all, could be an alibi that there was no such malicious inteintion of its implementation as mena666 complained at forum damage. :icon25:

sock, your new upgraded POM seems to work just fine--the bots were kicking my ass quite well.

a13n wrote:@sock
Your method looks different from mine in that you bake the genuine bsp afterwards.
With my method mappers don't have to re-bake the time-consuming genuine bsp again and again.

This is true. However, you can always have the bsp compiling while you do other things. Some people might be more comfortable simply recompiling it again, rather than messing around with a hex editor. Of course, there might be confusion with two different .bsps floating around...I guess(?) you could just release the new .aas by itself in a stand-alone pk3 and it would work? Both methods seem valid, so it's down to personal preference on this, I suppose. On the other hand:

a13n wrote:But your method, if it works at all, could be an alibi that there was no such malicious inteintion of its implementation as mena666 complained at forum damage. :icon25:

I'm starting to think that you have some sort of serious mental/social issues. What you seem to be attempting to do here is to create some sort of cross-forum drama, by posting under two different nicks. You posted the above comment here, and then this at the SD forums:

mena666 (who is actually a13n) wrote:BTW, guessing from the report@q3w, I can't help but imagine a sort of malicious intention of its implementation.

Sooo...hmmn. No one anywhere actually complained about any malicious intent (that I can find), but you refer to such posts on "the other forum" in order to...well...I'm not quite sure, and it doesn't really matter--it's not my job to figure it out. I got out of that line of work quite a few years ago.

Short form: Please stop doing weird shit like this. Please? You're obviously an intelligent individual, but behavior like this does nothing but tend to invalidate (by simple association) anything legitimate. People tend to ignore good ideas and contributions when they're overshadowed by general weirdness.

a13n wrote:But your method, if it works at all, could be an alibi that there was no such malicious inteintion of its implementation as mena666 complained at forum damage. :icon25:

Sorry just skimming through this.. errm. what? LOL..

hold on a minute here, what kind of malicious intentions? hehehe
I know I shouldn't encourage him but I am just wondering.

As far as all of this optimizing your AAS.. really now the best method is to make a clean level, cluster portal, clip, and bot clip. If you do those correctly you win on all fronts right?

Am I suddenly eligible for being malicious on some other forum now? lol...

zZCastleZz wrote:As far as all of this optimizing your AAS.. really now the best method is to make a clean level, cluster portal, clip, and bot clip. If you do those correctly you win on all fronts right?

The point is that the .aas is no longer directly dependent on the .map/.bsp using these methods.

This allows you to make various simplifications of, and improvements to, the .aas file, independently of the level geometry.

pjw wrote:

zZCastleZz wrote:As far as all of this optimizing your AAS.. really now the best method is to make a clean level, cluster portal, clip, and bot clip. If you do those correctly you win on all fronts right?

The point is that the .aas is no longer directly dependent on the .map/.bsp using these methods.

This allows you to make various simplifications of, and improvements to, the .aas file, independently of the level geometry.

Ah yes I see..

I like the idea because then you can make bot paths by clipping a level more extensively in the aas level than the actual level. Questions seem to come up though. Like how easy is it to confuse the bot navigation AI with this method. I can see possible advantages for doing this yet at the same time im wondering if it is really necessary.

You can do a couple things with this that I can see off the top of my head.

1. Removing extraneous geometry.

2. Add geometry that doesn't exist to further enhance bot navigation.

3. no need to compile your AAS for your current level as often as you compile BSP/VIS/RAD ect???

4. Smaller file size for your AAS???

====================================

1. hmm.. doesn't the compile process already do this? I am pretty sure although I can be very wrong about this but as far as I know when you compile a level with AAS it goes through and does this stuff for you via automated process. I can think of many examples where automated processes aren't as smart as a person but how big of a difference does this make?

2. I see this as being a double edged sword. Adding additional bot clip to make it so bots navigate more effectively. While it will simplify things for the bots it has me wondering if it is really a good idea since it would be very easy to knock bots in locations on the level that are normally deemed as null and void or even possibly solid geometry according to the AAS file. How does a bot react when it is inside of null space?

And the real kicker to this concept that has me scratching my head is that all of the things you can do in a different level that is referenced for AAS compile can also be done in your main level with the added advantage that you only need to deal with one level.. I'm kind of confused about how this idea offers a real reward for the effort.

3. I can see this as being an advantage.. However when it comes to compile times I'm more concerned with VIS and Lights. the AAS practically compiles instantly compared to those two. to each his own though right?

4. Potentially smaller AAS file??/ I'm not even sure if this is true since what I pointed out with point 1. If the AAS file is able to be truly smaller with out negatively effecting bot AI then I am might be wrong about the AAS file pruning extraneous geometry from the level at compile time.. However if the compiler does prune the levels extraneous geometry at compile time then its possible that your not going to gain much from using a separate level for your AAS in regards to your AAS file size.

What about Potentially smaller AAS file in regards to game performance? Well if the file size of the AAS is reduced then it would take less time to load the file when loading the level and take less system ram. However this doesn't necessarily guarantee less processing power is needed for bots to navigate your level.

What I can tell you is that I am pretty sure that AAS files small or large are used as optimally as possible. If this is true then even a AAS file with extraneous level geometry stored with in the file would take nearly the same processing power for bot AI when compared to an AAS file that was created with the same basic navigation space with little or no extraneous geometry. So if you are seeing a difference in performance there is a very high chance of it just being Placebo..

Maybe I have just been out of the loop for awhile. lol obviously too long right?

zZCastleZz wrote:Maybe I have just been out of the loop for awhile. lol obviously too long right?

Yes you have and here is brief history of events and why this feature existed in the first place...

I was creating a map 2.5yrs ago called Pyramid of the Magician and it had terrain/tri-souped brushwork everywhere, floors, walls and ceilings. It had far too much crazy odd angle brushwork and to be honest, it was never designed for bots. It started life as an experiment for alpha terrain blending and q3map2.

When it came to creating a bot file for the map it had a lot of problems. Firstly the bspc.exe is very old and was never designed to work with the way I created the map. Sure you are thinking why not just bot clip the map off, well bspc still reads in all the other brushwork buried in botclip and eventually runs out of memory. I needed to create a special "light" version for the bot file, that had all the excessive detail removed.

Then after speaking to Mr Elusive and Ydnar we came up with the idea of creating a separate bot map and re-attaching it to another BSP. This parameter was never created for general optimization, no one in their right mind would maintain two copies of a map. As Ydnar stated this was a feature I pestered him to add to q3map2.

ydnar wrote:Q3Map 2.5.16
Some stuff for Sock mainly.

Well after a lot of discussion and testing I could not get the feature to work right and left it. I published the map, wrote an article on alpha terrain blending and moved on.

Roll on 2.5 yrs ...

A13n looked at this feature and found a way to get it to work, which was very good news. Once I had a working example of the process I could maybe see where I was going wrong with the original map and try and fix it.

I spend a week working out a procedure I was happy with and then created a bot file for a map, which I released 2.5 yrs ago. There is no conspiracy or internet drama just the end to a map journey I started a very long time ago.

Sims

AH!

I see!
its something that can be used to get around AAS compiler limitations.
I wasn't even thinking about it from that angle.. :icon32:

I remember reading in other locations on the net where people mentioned this method of AAS optimization over the years. I suppose up until now I never really stopped and asked why. Context I suppose was always in respect to improving performance/AI navigation and never really about circumventing compile limitations.

I totally understand now. Thanks!

sock wrote:I [...] used 2 batch files to automate the process.

I've rewritten them for the UNIX bash(1) shell. They are available here for people mapping under linux/unix:

==> http://maps.sp1r1t.org/stuff/tools/fixaas-unix.zip

Documentation is included in the script files.

By the way I found a curious fact on the size of aas.
I believed that my optimized aas of q3dm17 was the smallest ever.
But dc_q3dm17(q3dm17 for dreamcast) tured out to be smaller!
So I decompiled dc_q3dm17 to see if what's going on down there.
Surprisingly the geometry there was far much complicated than mine.
Yet smaller aas it has.
This doesn't make sense unless dc_q3dm17 used special version of bspc.exe to overcome the restriction of the non-PC hardware.

Since AAS files tend to be relatively small in the first place and yields very good compression rates, I don't see how smaller AAS files necessarily co-relates as being "better". As long as the bots don't do stupid things, that's as much as you need to worry about.

tru dat

-fixaaspwned!

CSP for q3dm6 is ready!
This community service pack contains refined aas files for q3dm6.
There are total 2 aases, one for vq3 and another for cpma.


Any comment will be appreciated.

I'm sorry for digging out this ancient thread, but the cluster spoofing a13n wrote about could be of great use for me. I can't figure out what to do to make bots use these shortcuts, and the example map is no longer available. What can be seen on the screenshot looks like he just bridged the corner with some clusterportal brushes, but when I use them to fill gaps between simple angled platforms, bots still manage to fall down the edge with ease instead of jumping across. Can this map still be downloaded anywhere or can someone explain what to do in detail?

Looks to me like he's using clip brushes, not cluster portals.