Quake3World

when using q3map2, i use the standard uncompile line:

q3map2.exe -convert -format map (location of bsp)

now when it decompiles it q3map2 like "re-applies" every texture, so there wont be any textures in its original state as seen in the original .bsp in-game. does q3map2 have the ability to uncompile a map without this defect?

and yes, i did do a forum search. and no, i didnt find anything.

thanks for teh help in ADVANCE!!!!

I seem to remember that the decompilation that q3map2 performs ends up hosing the texturing as part of the process. I don't think I ever actually used that feature, or maybe just once or twice when I lost an early .map version, so I'm not 100% certain.

well is there a way to avoid this "hosing of textures", like a command to skip the texture decompilation or to keep them in there original form?

Nope. What you have is the best that you can hope for. Texture coordinates are lost in the process and are irretrievable.

I think it was done deliberately to stop people effortlessly plagiarising other people's work. As it stands if you want to enhance an existing level, you have to get the original .map from the author, or painstakingly recreate the level.

Foo wrote:I think it was done deliberately to stop people effortlessly plagiarising other people's work. As it stands if you want to enhance an existing level, you have to get the original .map from the author, or painstakingly recreate the level.

I'm not sure it's wholly intentional as I remember ydnar saying something about it being related to what the '-meta' optimisation does to the original mesh (that's assuming this is a 'modern' q3map2 era map), has a big effect on how polygons are organised in the BSP which then has a knock on effect on decompiling becasue the process can't then decompile into valid triangles (polygons).

i think quark has the ability to edit .bsp and save them as .maps. the only problem is that it has problems with the download. sometimes it corrupts.

It wasn't intentional. Forgot the technical reason why, but the textures are basically 'hosed'.

fittley sticks. well since that is pretty much done with... to save space on the forum... i have another question.

this is a troubleshoot ? on bspc.exe

whenever i use this command line (the one it says to use) in the command prompt to convert a bsp to an aas. i also tried q3build:

bspc.exe -bsp2aas c:\program files\quake iii arena\baseq3\maps\pillcity.bsp

(im trying to write an aas for pill city just cuz its so good i want BOTS for it )

it gives me this error message:

bspc.log
no files found
created by Mr. Elusive
(copyright info blah blah blah)

or something of that sort.

i then re-installed q3build, q3 radiant, and gtk build.

still didnt work.

i tried it on my moms PC with the EXACT same command line and guess what?

IT WORKS!!!

is there a fix to this? would just copying this to my computer and replacing what i currently have be the answer?

i figured since you people are the q3 technical gurus then you would be able to answer this.

i think i found out why. i read that vis leaks can lead to invalid or unfinished .aas files, so since i knew that my map was already good (and his map, 2 now) i put my map in a giant box of caulk that was the entire size of the workspace but hollowed out. when there is a vis leak it says like "2 point lin file" which is the pointfile for finding where the vis leak is. when i put it in the box of caulk, it doesnt give me that error message, it generated the .aas, but the .aas and the .bsp arent compatable with eachother. though i did have like 3 different versions of this map, i was almost sure that the version i compiled it with and put it in the same .pk3 file were the same version. after that, i checked if it worked, it didnt. i used the thread -reach *filename* and it recalculating grapple reachabilities and it still wont work. any suggestions?

Whoa, reading that gave me a mild headache.

First of all, make sure that you don't have multiple copies of files lying around. Most problems can be traced to file overwriting/resource sharing/multiple copy issues. Remove the PK3 from your developer install since unpacked files can still have issues with packed files.

Don't enclose your entire map in caulk. This is not a suitable fix to leak errors and will cause all sorts of performance issues. Bots don't seem to like this any better.

To find leaks, you should be able to use the find next leak spot option in the Misc menu. Fix the leaks and try to recompile.

Vis leaks will not generate a completed BSP file, so you won't be able to run BSPC on the BSP in the first place. Fix leaks first, then worry about creating AAS later.

well see thats the problem. the red line generated by the .lin file draws the line completely outside the level. should i change the caulk texture on the box to the sky tex and erase the sky tex already there and put it as "fullclip", it already has player and bot clip though. i re-saved and generated a new .bsp with a new filename. ill see if this works.

why was my last post hard to read? was there just to many technical words in it?

Foo wrote:I think it was done deliberately to stop people effortlessly plagiarising other people's work. As it stands if you want to enhance an existing level, you have to get the original .map from the author, or painstakingly recreate the level.

it's a rubbish precautionary method though. hammer maps have a worldspawn flag that prevents decompilation with vmex, yet without that flag bsps decompile without tex coordinate data loss. much better system, as it allows you to a) decompile official maps and learn from them (better than any tute) and also b) save yourself from the embarrassment of accidentally losing the original map file of your own work *holds up hand*

squirell man wrote:why was my last post hard to read?

Lack of capitalization, some run-on sentences, and lack of line breaks (IMO).

If your pointfile starts outside the level, then there must be some reason for that. The pointfile will always start at an entity (or where the compiler *thinks* an entity is, based on origin).

My guess is that either (a) you have something filtered/hidden that's sitting outside the map, or (b) there's something in the map that has an origin in some nonsensical place (maybe a model with the origin way off, or a brush-based entity that got stretched/altered in some way that would leave the origin behind).

Try making sure that you don't have anything filtered or hidden, and draw a brush around the leak line and do "select complete tall" and see what gets selected...

yay it worked.

Another question to ask on this thread to save space on the forum:
I created another "city" level. I placed cluster portals, botroams, info_camp and everything else to help bot support.

I went into gtk-build and compiled it into a .bsp and .aas for a level with playable bot support.

I went to go try the level out in-game. When I tried to start, it got past "connecting to localhost" (thats the last thing my eye can catch) and the game quited to the main menu and said "HUNK ALOCK FAILED ON *like 10 #s*"

I removed the bot support file from baseq3/maps and then I tried it out again. The level worked PeRfEct! There was just no bot support. The level is a city, surrounded by skyscrapers for boundries. (like q3tower) and then if you get past the sky scrapers, you fall into the space void and die. the level is HUGE but stays in the workspace.

I cannot figure out why this hasnt worked. Thanks for all the help so far and to come by the way.

(was this post easier to read?)

much

not an answer to your problem (maybe you need to set a higher com_hunkmegs for that, or make sure the bots are totally boxed in with botclip?), but something you can do to make problems easier to diagnose is save the console output.

if you hit the 'tilde' key (top left) to bring down the console and type:

\condump filename.txt

then it'll dump the contents of the console to a textfile in your q3 directory (or maybe baseq3, i forget). you can look at the end of that text file to see exactly what the last error was and whatever happened just before it occurred.

I'm not 100% sure on this but it may help to increase the "com_hunkmegs" setting in your q3config.cfg to get rid of this.

Map must be quite huge if this is the reason though.

And btw: imo it would have been better to start a new thread as this has nothing to do with the rest of this topic.

then I will next question I have

The map is the size of 1/3- almost 1/2 of the workspace. There was also this map - phobosbase1 - that this happened on but after a while it never happened again.

it isnt working the same.

it still gives "hunk_alloc failed on 910394" or something like that.

thats what it says on that txt file.

seremtan wrote: t's a rubbish precautionary method though. hammer maps have a worldspawn flag that prevents decompilation with vmex, yet without that flag bsps decompile without tex coordinate data loss. much better system, as it allows you to a) decompile official maps and learn from them (better than any tute) and also b) save yourself from the embarrassment of accidentally losing the original map file of your own work *holds up hand*

wait, does this mean that there is a way to decompile a map without tex data loss? i didnt really understand this post.