insane q3map2/bspc behaviour

(Cardigan) #1

ydnar please help me before I go mad…

my map Estatica is finished, I’d just finalized item placement using ICE to test out various different item layouts - loading the new layouts into CPMA to playtest against bots using my precompiled BSP and AAS. All luverly jubbly no problems. But when I change the items in Radiant and recompile the map it breaks some of my cluster portals. I am certain that I have changed nothing except the items - no new brushes, models or anything. Surely this should make no difference to AAS compiling if the precompiled AAS works with a new item layout loaded in at runtime?

Whats more, I tried going back to the old version (which still works fine) and changing the items one by one. Sometimes bspc crashes completely, other times it works but breaks the cluster portals.

Any idea what might be happening here?

edit: btw I posted this here because if I use different versions of q3map2 I get different results with BSPC, unfortunately none of them work properly… I want to compile with q3map 2.3.32 as then my oddly angled models stay in the right places, but I would upgrade and use the beta release of GTK 1.3 to move the models if I thought it would help. At the moment though it just seems to break it in a different way…

(ydnar) #2

Erg.

Well, Radiant doesn’t guarantee the order of entities or brushes. So a map can be saved twice and end up with different BSP results…

You are using -forcesidesvisible on the BSPC commandline right?

I’d install GtkRadiant 1.3.x (7 is the latest, I think?) and use Q3Map 2.5.4 (or 2.5.5 test). Those have proper angles keys.

y

(Cardigan) #3

heh, I guess I should have said ‘then my oddly angled models stay in the WRONG (GTK 1.2.11) places’ actually… :slight_smile: Moving them into the right places in GTK 1.3.x is more of a job than it sounds, simply because my finely tuned lighting and shadows are reliant on their positions and its not like each model is consistently 8 units to the left or something, they’re all over the place…

I seem to be making some progress at finding out which portals are breaking and I’ve found in the past that simply changing the shape of the portal slightly will fix it, so I’ll give that a go first but christ is it frustrating… :banghead:

(Cardigan) #4

hmmm… narrowed it down to one broken portal, even though there’s nothing actually wrong with the portal and it worked fine before :confused:

but everytime I change it from botclip back to clusterportal the thing screws up again. Change the items back to their original places and it works… madness…

just out of curiosity, would I avoid these problems if I compiled with q3map1 and without forcesidesvisible? or was bspc a buggy POS to begin with? :slight_smile:

(Cardigan) #5

heh, the saga continues… get this:

going on what ydnar said about gtk not guaranteeing brush order, I took a working version of the map (with old item placement) and opened it up in wordpad. I changed several items to different items by changing the classnames. Recompiled. It worked. I added a new lightning gun in a place where there was no item before (by typing in a new entity at the end of the file - GTK not involved). Recompiled. Clusters broken. I changed it to a shotgun. Recompiled. It worked??!!!?!

pray for me guys…

(ydnar) #6

It’s probably BSPC.

Your map is, um, quite complex, and may just be confusing BSPC.

Are you using lots of botclip slabs?

y

(Cardigan) #7

yeah I guess you could say it was pretty complex :slight_smile: - its botclipped up to the nines though and doesn’t actually take BSPC very long to compile (only uses 12 megs mem). Anyway, I did eventually fix it :smiley: - it was that lightning gun that was causing the problems for some reason - I swapped it with a 50 health that was about 256 units away and now it works again. Hurrah! Now I just have to test botplay a bit and then off we go with the final compile… :smiley: