[REL] OpenArena Community Mappack - Volume 1 - FINAL

[pelya]

Could you please also put more lights to side corridors? They were a bit too dark for me in the last version of akomdm1, I don't know how they are now though.

[Neon_Knight]

Torches may do the job. Today I'll be releasing my version of oa_akomdm1.
Then, to work on oa_akomdm4, which also has the lighting problem.

[Neon_Knight]

Well, here it is.
Changes:
- Compilation problems fixed by way of optimizations (only caulk optimization and mittering weren't done)
  - Hintbrushing (less things drawn from many POVs)
  - Clipping and Botclipping
  - Detailbrushing (less things interfering with the BSP Tree)
- Lighting improved (I wanted to add flares and beams, but well, not everything can be done, besides, there're tons of lights, and some of them are made of patches) Now every light has a source, and the light corresponds with the level.
- Some architectural changes (many archs made as patches, a new statue in the central hall near the fog area providing cover, the previous H-shaped southern hall has been redesigned so it doesn't look symmetrical)
- Entity placement (weapons/items/playerstarts) changed, the map now doesn't look too symmetric.

Only known bugs: for some reason, the bevelcaps at the lower level don't look right. Also, I forgot to place the fog back. -.-

Attached download.

Requires Akom's OACMP1 mappack.

[Akom74]

Good job, but why don't you insert the fog ?
In the editor you have leaved it outside of the map 

 

[pelya]

Fog was kinda cool, I would prefer if it will stay.

[Neon_Knight]

Oh, yeah, another mistake of mine. -.-
I wanted the fog to stay, but I've removed it temporally for optimization reasons. But I just forgot to place it back. -.-

[jangroothuijse]

Right, i do not know how helpfull this still is...:

http://jan.groothuijse.net/img/zzzz_oajgdm1_2_3r.pk3

Fixes,
dm1: texturing defect
dm2: some texturing defects, some z-fighting issues
dm3: texturing along patches, some z-fighting
all of them now have a seperate skybox shader, and the shader used in the game match the one used in compilation.

Could other changes that were made be ported to this? Like in the editor open it up, filter anything but entities and copy them over that way?

[Gig]

Jan!!! Welcome back!!! Nice to read you!

Unfortunately, I will not be able to test your updated maps (did you check the forum since pre-RC1 for pointed out issues?), and the NK version of Akom's map, before the next week.

Merry Christmas guys, although I'm two-three days late!

Bye!

[Neon_Knight]

I haven't changed anything yet in your maps, Jan. Though I was thinking on doing two versions of oajgdm2 as the namesake and oajgdm2ctf, as the map has potential for an asymmetric CTF but has some issues which should be corrected.

BTW, updated links on the Wiki. Once I solve akomdm4's problems, we're ready for RC2.

[Gig]

BTW, updated links on the Wiki. Once I solve akomdm4's problems, we're ready for RC2.

Excuse me, I have not yet understood (I'm a bit dumb sometimes, please forgive me)... will you release two different versions of RC2, to let people decide to use original versions or your versions of the maps? Or will you release a single RC, with some maps modified (re-compiled by you) and others not (keeping those we previously sent)? Or what else?

[Neon_Knight]

Single version. But I'll include my edits of those of maps which didn't compile at first, such as oa_akomdm1 and oa_akomdm4. The previous version of oajgdm2 also didn't compile, I have to test the new version as well.

Because, you know, every map in the pack must be compilable from any version of q3map(2)/bspc (about editors being able to read them, that's other thing which can fortunately be solved). Otherwise, they couldn't be really GPL.

[Gig]

I'm not sure about gpl really requires the map to be compatible with ANY q3map(2) compiler. Otherwise, I may create my own q3map2 fork (e.g. q3map2 version 2.gig003), and put a little change in there that would make 99% existing maps not really compatible with it. Would that automatically make 99% of existing maps not GPL-compliant? I don't think so.

[Neon_Knight]

oajgdm1: Some botclip brushes weren't fully botclipped. BSPC wouldn't compile. Problem fixed. Map compiles good and well.
oajgdm2: Compiles good and well.
oajgdm3: BSPC doesn't compile. Trying to find the culprit, perhaps I might have to redo the whole botclipping/clusterportaling of the map. Though it's a pretty complex map with tons of curves. A very good and interesting one, so this must be part of the pack.

I'm not sure about gpl really requires the map to be compatible with ANY q3map(2) compiler. Otherwise, I may create my own q3map2 fork (e.g. q3map2 version 2.gig003), and put a little change in there that would make 99% existing maps not really compatible with it. Would that automatically make 99% of existing maps not GPL-compliant? I don't think so.

This is out of discussion, Gig. Besides, as I've realized after working on oa_akomdm1, the problems regarding to map compiling have to do with problems in the construction of the map itself (prior to turning every decorative brush into detail, the map didn't compile), so they can and should be fixed.

[jangroothuijse]

oajgdm1: Some botclip brushes weren't fully botclipped. BSPC wouldn't compile. Problem fixed. Map compiles good and well.
oajgdm2: Compiles good and well.
oajgdm3: BSPC doesn't compile. Trying to find the culprit, perhaps I might have to redo the whole botclipping/clusterportaling of the map. Though it's a pretty complex map with tons of curves. A very good and interesting one, so this must be part of the pack.

I'm not sure about gpl really requires the map to be compatible with ANY q3map(2) compiler. Otherwise, I may create my own q3map2 fork (e.g. q3map2 version 2.gig003), and put a little change in there that would make 99% existing maps not really compatible with it. Would that automatically make 99% of existing maps not GPL-compliant? I don't think so.

This is out of discussion, Gig. Besides, as I've realized after working on oa_akomdm1, the problems regarding to map compiling have to do with problems in the construction of the map itself (prior to turning every decorative brush into detail, the map didn't compile), so they can and should be fixed.

Can i help?

The botclips/cluster portals were constructed with great care to avoid any botstutter....any indication about why they would not compile?

"Some botclip brushes weren't fully botclipped" you mean some faces werent actually botclip?

[Neon_Knight]

Yep, some of them weren't botclip, otherwise they would hide when you filter them in the Editor.

The clusterportals have very annoying tight requirements. Unless they're placed in a specific way and surrounded with specific brushes with specific textures in specific faces, *sigh* they won't work. Though once you learn what are the requirements and what they're supposed to do, then it's easy to use them.

From what I've understood at looking at Cardigan's bot optimization tutorial (which I've transcribed and resumed in the wiki page DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Bot_play]Bot play) the clusterportals:

* must completely seal off a section of the map to make that section a cluster in its own right,
* will not function if they are crossed by a trigger_push trajectory,
* will not work properly if they can be fallen through, rather than walked through,
* will not work properly if they have other brushes intersecting them,
* should be axial (squared) as far as possible, and made from a single brush,
* should always have identically shaped and sized 'entrances' and 'exits' (usually done with botclip),
* should always be surrounded on all sides but front and back by solid geometry or clip,
* should not contain less than 10 areas,
* should be 16 units thick, or 32 if absolutely necessary,
* must separate no more and no less than 2 clusters, and
* should never extend into the void.

In the case of clusterportals they must be 16px, some of yours were 13px. But that's the only error I've spotted so far. Yet, BSPC stops at a certain part saying "Tried parent". This also happened in Akom's dm1 map, it turns out a hugely complex set of brushes was getting in the way, so I made it detail and clipped it, and the map compiled just fine.

[Gig]

Maybe in the sum up about clusteportals, one may also mention that teleporters do fuse the starting and destination clusters into one. I thought I read that somewhere. Right?

PS: In the example I did in my last post, that 99% was an extreme example. Thinking about that example with a different percentage (e.g. 30 or 40%) may be more indicative.

[jangroothuijse]

I actually made the clusters 16px...because i was aware of these requirements, but then a few months back i scaled the map down, to indeed 13/16....oajgdm2 also got scaled down a bit too, to 7/8.

These are the first real issues that occurred from scaling, but i have not tried 'less nice' ratio's.

[Neon_Knight]

Maybe in the sum up about clusteportals, one may also mention that teleporters do fuse the starting and destination clusters into one. I thought I read that somewhere. Right?

Yep, Cardigan's tutorial mentions that as well.

An important point to remember is that the virtual water will be able to flow through a teleport, so if we had a teleport in the room above which led to a destination in the corridor, cluster 2 would no longer be watertight. A possible solution to this is to encase the teleport in botclip as far as possible and then make a clusterportal 'entrance' the bots will have to go through to get to it.

That could have been made as it's own paragraph, as it's another thing to bear in mind.

Maybe in the sum up about clusteportals, one may also mention that teleporters do fuse the starting and destination clusters into one. I thought I read that somewhere. Right?

PS: In the example I did in my last post, that 99% was an extreme example. Thinking about that example with a different percentage (e.g. 30 or 40%) may be more indicative.

I still stand by my point. Especially when those issues can be fixed in order to make the map compilable.

[jangroothuijse]

New revision of oajgctf1, based on the .map file from the latest RC...but no one changed it since then, right?

http://jan.groothuijse.net/img/oajgctf1p.pk3

It fixes:

• the visibility of some corridors, by having a lighter texture for the ground...
• has its own skybox, which is compiled using the same definition as found in the file
• replaces a last few references to textures i once put in the common directory...
• Some slight construction error in the tunnels

Jan!!! Welcome back!!! Nice to read you!

I actually appreciate the welcome, i was feeling like i let you guys down...

[Neon_Knight]

Oh, don't worry, nothing was changed.

Since all the maps are right here, I might as well start the packaging.
Monday 12:00 PM GMT-3 the RC2 will be released.

[jangroothuijse]

made a small texturing error in the last version:

http://jan.groothuijse.net/img/oajgctf1pr1.pk3

[Neon_Knight]

Noted. Also downloaded.

[Gig]

I'm going to download your maps... (Did you add some bullets ammo boxes? And background music? And updated "readme" files?)

In the meanwhile, for Neon_Knight:
- In these days you have been busy with recompiling maps... don't forget those notes about packaging:
http://openarena.ws/board/index.php?topic=4679.msg49304#msg49304 (your replies here)
http://openarena.ws/board/index.php?topic=4679.msg49306#msg49306
http://openarena.ws/board/index.php?topic=4679.msg49340#msg49340 (Note: latest Jan's maps have been released after that test. His latest .pk3 files seem to do not contain the "textures/common" folder anymore... but I haven't checked inside the .map or inside the .shader files!!!)
http://openarena.ws/board/index.php?topic=4679.msg49341#msg49341

- I have not understood what are your plans about udestruction. That screenshot you posted a few days ago made me think the compiling with q3map2, although technically working, introduced a few differences than how the map was expected to look like. When I was trying to make the switch from q3map to q3map2, months ago (such as v09bis and v10bis, I don't remember if there were more tries), I encountered some problems, and very little feedback/help on the forum IIRC, so at the end I gave up. If I can help in some way (for example, I may explain the reason I did a certain thing in a certain way), let me know.

[Neon_Knight]

From how things evolved, I guess I'll have to pack every sent version, except oa_akomdm1, which I'll include my version. And possibly my own version of Moixie's CTF map. I've added DOM support to it and improved it a bit visually.

About your reminders, Gig, I'm starting to see them in my dreams. -.-
And remember: many players are jerks, they will never offer criticism except when something already came out or is about to.

About udestruction, the version which will be included in the pack will be v17. We have two more weeks to work on all the maps.

About what you can do, you've already done a lot with your map and your reminders and organizing the pack in my absence, that's why you're also credited as OACMP coordinator.

Anyway, the packaging has started.

[Gig]

I have been extremely busy with real life this morning. So I started testing the most recent maps only a few minutes ago.

- OAJGCTF1p: Seems good, but it still lacks background music. As a side note, I would have liked to find some machinegun ammo boxes in the lateral tunnells...