Cocerello's War Journal

[cocerello]

Greetings!

Here i am opening this to update my status an let you know i am on the breach.

Currently i am mapping slowly but steadily, after searching all over for everything needed for mapping and chosing an editor (Jackhammer). 

This has been more interesting than i thought, relearning mapping for Quake 2 which i haven't touched in who knows how many years, and making a DM map, which i am not used to, as even as a player i barely play DM, as i myself and my friends always prefered to play CTF or assault the base modes in any shooting videogame. Unfortunately, i won't have time to learn all the options Quake 2 give, so my map would fit any videogame, textures aside, which will have to be Quake 2 Id ones (Jackhammer's issue), and i can't assure that the gameplay will fit DM one, much less the one Quake 2 players are accustomed to, but i can assure you one thing, it will be a strange map, as that's what i usually tend to map  . 

Screenshots and more will come soon!

[Null]

It's a battle out there, so maybe some improvised guerrilla warfare can work in your favor
A lot of people like strange maps, especially if the elements are tied together well.
A collection of unique ideas often times set them apart and defines their personality.
I'm sure it'll be as interesting to play as it was to make.

[cocerello]

Yes, you are right, Null, an all-out war is more tiring, guerrilla tactics divide the war in several more manageable objectives

One third done completely. I used several setpieces to improve the mapping speed, but the setpieces themselves were way harder to make than expected, and gave many problems, so one thing nullified the other, and there was no improvement in speed. At least that part is done and the rest will be easier.

The last surprise i got was this: I overstimated Quake 2 original engine capabilities, and got this error when opening the map:

ERROR: map has too large visibility lump

In fact i surpassed the limit by doubling it, and the culprit was this (and 17 more like it). Which achieved by themselves more than 1x10^6 (the limit is around 0.9x10^6) visdata. 





It was a surprise, as i tried to keep visibility as low as possible (and it is (10 sec to vis)). So i had to delete them and part of the map, which is a shame, but at the rate i was, the rest of what i have planned wouldn't fit on the engine's limits even by deleting those 18 setpieces.

Also, while investigating this i found something surprising. Aren't world brushes supposed to block vis? Because i get high r_speeds when i face (and touch) a flat wall if it faces to where the rest of the map is, and even more i i look at the center of the map from a side of it. And more importantly, there is no leaks in the map.

And finally, a question for you all: Is it unusual nowadays to play a map for 6 players max? It is going to be hard to add more spawns than 6 in this one.

[jitspoe]

Make sure you set the "detail" flag on brushes like that and anything else that doesn't block visibility. That will greatly reduce your vis time and vis data size. r_speeds are still likely to be an issue, though.

[cocerello]

Yeah, its that or turning them into func_walls, Jitspoe. Vis time isn't a concern with this map, with 10-15 seconds on fastvis and 2-3 minutes on a full vis. Accostumed to fullvising that takes hours and hours this is a bliss, as i can even check lighting and details, or even just how much the visdata has changed if i change something in the map, tons of times without concern.

I'm checking r_speeds from time to time, but as i did the layout with them in mind, i haven't gotten anything big (500-1000wpoly on most areas and some with 2000-2500 (the ones with the detail i showed before) on fastvis, and half of that or even less with a fullvis).


This map is being a fight against Quake 2's vis compiler and original engine. Everytime i hit a limit, i check what i can change to lower it. The first time deleted some rooms and deleted the details mentioned above, the second turned lots of things into detail brushes, and now i am close to hit the limit a third time, the limit on fastvising, with a ''Vismap expansion overflow'' warning, and between those times i twist the layout to reduce visibility as much as possible.
Well, the main reason this happens isn't that the map has many open areas, which hasn't, but more that it is a monster in size (typical beginner map error ). What isn't so typical is that it isn't related to beign overambitious as usual in this caes, but more to a bad early decision on brushwork style.

Progress in the map has been getting slower, as i also got lots of leaf portal saw into leaf errors. Even though i know they aren't critical by reading Aguirre's and Qworkshop's advices, i get remembered of those times back in 199x when i continued mapping in WC1.1.2 for Quake without caring about compiling errors, because didn't know a thing about them neither had Internet or someone to ask to, so now with all the info there is out there the perfectionist in me won over mysel and fixed them all.

Overall, its being an interesting lesson on mapping.

[jaydolan]

Don't do that `func_wall` thing. It adversely affects renderer performance and in extreme cases will also cause overflows when connecting. When you make a group of brushes into a `func_wall`, they are rendered in a separate loop, outside of the main world rendering loop. The penalty for this is a bit of OpenGL state thrashing. Not an issue for a handful of inline-BSP entities, but can easily become a big performance hit if you've got 100 light fixtures each grouped as a `func_wall`. In terms of network penalties: every entity in the game takes up an entity slot, and must be transmitted when a player connects as part of SVC_BASELINES. So if you're grouping random, stationary brushwork into `func_wall`, you're just wasting entity slots and inflating the size of the baselines the server must send. This is where you'll eventually run into overflows.

In short, don't use `func_wall` as a bandaid for bad VIS. Fix your VIS using SURF_HINT, CONTENTS_DETAIL, SURF_SKIP, etc.

[cocerello]

Don't worry and thanks, i know its dangerous to depend on brush entities for that, and the virtues of detail brushes. What i didn't knew were the details you are providing. Very interesting indeed. also don't know how to use SURF_HINT, CONTENTS_DETAIL, SURF_SKIP, but i'll learn that on the next map.


About the map itself its going very well. It is almost complete, just have to so some tweaks here and there. r_speeds are good on it, with 700 wploys at the highest.

The bad part, i have two bugs i don't know how to fix.
- I have items on top of func_plats. They spawn well, but after i take them, when respawning, they do below the plat, instead of on top of it. Is it fixable or is a common Quake 2's behavior?
- I have a button that never triggers the first time is pressed. the rest of the times works fine, only the first fails. Very strange.

[Null]

Quake 2 items have a drop to floor property enabled by default. In certain mods like wodx and lazarus you can turn off this flag so the items stay fixed in space.
You can try "spawnflags" "12" but I doubt it'll work in regular Quake 2. You might need to have them spawn away from the elevator unfortunately, or maybe use some invisible brush which I'm not familiar with.
In the following example I used the spawnflag to suspend Coin pickups in mid air:

http.tastyspleen.net/~p1/quake2/weapons/maps/tltfun.bsp.override

[cocerello]

The map is done and prepared to submit. Still have some issues like the buttons not working the first time, but are minor.

[Null]

Thank you cocerello for submitting your map!