[REL] OpenArena Community Mappack - Volume 1 - FINAL

[Neon_Knight]

Some of the maps will have to wait until before the final release to have their issues solved because they cannot be compiled (for X or Y reason) or take too long to do so.

[Gig]

More tests about the most recent maps released (pre-RC2)

OAJGDM1beta5:
- Some texture misalgments seem to have been fixed. Although a few texture/brush misaligments seems to still be there. And shots do continue to impact on the white wall, while in my humble opinion would have been nicer to disappear "surfaceparm noimpact" or "surfaceparm nomarks" (however that's just a detail).
(check first three screenshots attached)

OAJGDM3beta7:
- Good, altohugh I noticed that firing rockets where you see the border "burned" in the fourth screenshot, a sort of black vertical line appears, maybe caused by overlapping brushes (or patches?). I don't know if it's worth spending time, however it's a thing I noticed.

[Gig]

Final part of my pre-RC2 quick test:

OAJGDM2beta9:
- Seems good at a first look, although there are still a few places where firing a rocket causes strange artefacts to be shown (see first two screenshots).
- I don't remember if there were more issues with the previous versions...

OA_AKOMDM1 (NeonKnight Version):
- Illumination is brighter and more coherent, although maybe before it had "more personality" (with those red and green parts).
- Look at the place of the third screenshot. Now the player cannot go there, I assume it's playerclipped. But it's strange do to not allow to get on that "Akom74" stone... what about using botclip instead of playerclip there? And similarily, one may allow human players to also get on the caskets (but without the abilty of falling laterally): I mean, playerclip the recess up to the casket level, and botclip the space above it.
- Look at the fourth screenshot: these lights are cool, but have a problem of showing a border that should be invisible. Are we sure we want to use them? Well, in theory, we may keep them and fix the problem in a next OA release (0.9.0, OA3): IIRC, somewhere in the forum has been explained that kind of artefact can be fixed by modifiying the texture in a certain way. An option may be creating a copy of that shader into an "Akom" folder, and apply the fix directly there... so that map would be already looking good, without having to wait for future OA releases!
- Maybe the Lizard statue may be also "weapon clipped": at the moment, bullets do pass through it, and this gives an unnatural effect!



I'm sorry, I would have preferred to do these tests in the past days, but real life did not allow me to do.

PS: searching for threads about those lights glitch....
http://openarena.ws/board/index.php?topic=1945.msg43505#msg43505
http://openarena.ws/board/index.php?topic=4446.msg43270#msg43270 <--!!!!

PPS:

And possibly my own version of Moixie's CTF map. I've added DOM support to it and improved it a bit visually.

IIRC, that map already had DOM support, although with a single Domination point. IIRC, we asked Moixie the reason for that, and he said he did it this way on purpose, to force everybody to fight in the middle of the arena. But I may remember wrong. I have no personal preference about any of the two.

[Neon_Knight]

About Moixie's map, well, yeah, but then all the infighting would happen in a single spot, with the rest of the map being underused. So I've improved it by adding two extra points with functional walls (func_static) separating the DOM areas.

About Akom's map, I'm afraid I had to leave the fog out, because trying with different fogs hadn't a good result, they looked more like water than fog. It's a problem of OA's own shaders. Too bad, because I also wanted the map to have fog, it looked really cool. Also fixed the clipping issue (will be released in the RC2)

About the Lizard, clipping it could be a daunting task. By now I'll release it as it is, I'll see later what can I do about it.

[Neon_Knight]

BTW, by using an older version of BSPC I have finally figured out why some maps wouldn't compile: they generate too many areas (regular/acceptable amounts are below 75000, the troublesome maps -NONE of them long enough for such higher amount of cuts- generated over 100000!) in a lot of areas. So my theory with akom's map was correct after all: by otpimizing the map's geometry I also reduced the amount of areas being generated.

So, yes, say what you want about compiling, but optimization matters. A lot.

[Akom74]

About Akom's map, I'm afraid I had to leave the fog out, because trying with different fogs hadn't a good result, they looked more like water than fog. It's a problem of OA's own shaders. Too bad, because I also wanted the map to have fog, it looked really cool. Also fixed the clipping issue (will be released in the RC2)

Can't you leave the old fog ? It's an OA original.

[Gig]

Why should it be daunting to add weaponclip? Because you think it may require many, small brushes?

IIRC, from a few tests I saw (years ago, so I may remember wrong), just a few "weapon clip" boxes (or "full clip" maybe?) roughly around the 3d model (e.g. one for body, one for head, one for arm) should be enough... But I cannot do a test right now.

How are Q3DM1 (included with Q3Radiant, IIRC) statues clipped?

[Gig]

So I've improved it by adding two extra points with functional walls (func_static) separating the DOM areas.

I have not exactly understood how (where) will you place these new walls in the map, but in general don't forget the IMPORTANT thing about gametype-dependent walls (func_static walls): bots never pass through them, but always walk AROUND them, even in the gametypes where these walls are disabled.

Gig from cell phone.

[Danfun64]

Monday 12:00 PM GMT-3 the RC2 will be released.

Its past that time...

[Gig]

Monday 12:00 PM GMT-3 the RC2 will be released.

Its past that time...

If 12:00 PM means 24:00, then there are still some hours left...
.... otherwise..... well, who cares? We have been working on this for about one year, a few hours more or less do change nothing.  
And don't forget this is RC2, it's still not the Official release...



PS:

How are Q3DM1 (included with Q3Radiant, IIRC) statues clipped?

Answer: this way (see screenshot). Note: screenshot taken with Q3Radiant. Shader colors shown differ, when mapping for OA (using Net/GTKRadiant).

[Neon_Knight]

Uploading the RC2. Sorry for the delay!

There's a bunch of unsolved issues, but I've made sure to acknowledge many of Gig's points. Some of them I couldn't acknowledge because the maps have compile issues or other issues.

[Neon_Knight]

These are the only "modified by me" maps I'll be including in RC2, all of them based on their latest releases:
- oa_akomdm1
- Moixie's DM
- Moixie's CTF

Everything else will be released as their authors uploaded them. Sorry, but there's not much time to optimize/fix before RC2. Those issues should be fixed before the final release.

Why should it be daunting to add weaponclip? Because you think it may require many, small brushes?

IIRC, from a few tests I saw (years ago, so I may remember wrong), just a few "weapon clip" boxes (or "full clip" maybe?) roughly around the 3d model (e.g. one for body, one for head, one for arm) should be enough... But I cannot do a test right now.

How are Q3DM1 (included with Q3Radiant, IIRC) statues clipped?

Exactly. Too many brushes.

So I've improved it by adding two extra points with functional walls (func_static) separating the DOM areas.

I have not exactly understood how (where) will you place these new walls in the map, but in general don't forget the IMPORTANT thing about gametype-dependent walls (func_static walls): bots never pass through them, but always walk AROUND them, even in the gametypes where these walls are disabled.

Gig from cell phone.

There are tricks for this, such as item_botroam. However I'll check that later.

About Akom's map, I'm afraid I had to leave the fog out, because trying with different fogs hadn't a good result, they looked more like water than fog. It's a problem of OA's own shaders. Too bad, because I also wanted the map to have fog, it looked really cool. Also fixed the clipping issue (will be released in the RC2)

Can't you leave the old fog ? It's an OA original.

Unfortunately, for some reason it ended as "water" instead of fog. -.-
Too bad, because I really wanted the fog to stay in that map. :/

[Neon_Knight]

Look below...

[Gig]

Because you think it may require many, small brushes?

IIRC, from a few tests I saw (years ago, so I may remember wrong), just a few "weapon clip" boxes (or "full clip" maybe?) roughly around the 3d model (e.g. one for body, one for head, one for arm) should be enough... But I cannot do a test right now.

Exactly. Too many brushes.

Uhm... do a try with just a bunch of rough brushes. Did you see the screenshot attached here? It looks like a perfect job is not required.

[Neon_Knight]

http://www.onykage.com/files/armageddonman/!oacmp/oacmp-rc2.zip

Here's the RC2! Sorry for the delay!

[Gig]

Very, very first things about RC2: today I only had a few minutes for the tests. I hope to be able to do more tests in the next days.

Oa_akomdm1:
- I miss the fog... changing lights already diminished some of the map's personality (although gave better visibility and coherency)... I really miss its fog.
- About those slightly "glitched" light textures, I already said here.
- About the clipping around the tombs, I thought about being able to jump on them, but not being able to go on their sides (not being able to get where I am in the first screenshot here). However, maybe it's not so important. Feel free to decide.  
- In the second screenshot, a detail (a corner) that maybe may get a little better "trim" work. Not really important.
- I already said about the statue.

Moixie's CTF map:
- As I feared, that glass wall you added (third screenshot) in Domination mode, is considered as solid by bots also in all other modes. So, human players have got a further advantage over bots, who cannot use the shortest path. And the map is not completely balanced for bots, considering the wall is only on one side (right?).
Switch to any other team-based gametype and order a team-mate of yours BOT to follow you, then cross that invisible wall: the bot will have to do a long trip to reach you.   Func_static has to be used with care, and unfortunately it's not adapt to manage real changes in map flow...
- I'm not sure those domination points placed asymmetrically in a symmetrical map look good.   Maybe adding some type of pedestal below them may make them look a bit better? I don't know.

In both Moixie's maps, I noticed some light textures as missing. But due to time problems, I did the tests with a non-clean OA install. Tomorrow I will try with a clean OA install, probably it's just that.
I have not had time to test more maps today, or to look into .arena and map rotation script files yet.

PACKAGING-related:
- Various txt files (including main readme) in "docs" folder do use Linux-format carriage return. This may be a problem for Windows users.
- I can guess "Under Destruction textures sources readme.txt" may be moved into the "udestruction" folder (sources/textures/udestruction).

[Neon_Knight]

JSYK the map rotation files have the final release names.

In the case of the CTF map, DOM with only one point doesn't cut it for the reason I've explained above. With two points it becomes Double DOM. Any other idea?

[Akom74]

Unfortunately, for some reason it ended as "water" instead of fog. -.-
Too bad, because I really wanted the fog to stay in that map. :/

I'm not sure at 100%, but..... what do you mean with "water" ??
The texture is an OA original and it work like fog from the first release of the map.



I'm confused..... 

[Gig]

In the case of the CTF map, DOM with only one point doesn't cut it for the reason I've explained above. With two points it becomes Double DOM. Any other idea?

Double DOM has got different rules than DOM, other than the number of points.
However, I can guess the two additional DOM points may be simply placed in the place of standard flags, or at the two extremes of the map, after the stairs (keeping the original one in the middle).

@Akom: I can guess something goes wrong while compiling the foggy map with q3map2? However, some screenshot/test version from NK would be welcome.   Some shaderlist problem, maybe?

[Neon_Knight]

My point is that I don't see the meaning of a DOM match of less than 3 control points.

[Neon_Knight]

Well, apparently the "water fog" glitch doesn't happen anymore, so I've restored the fog to the map. It seems that there's a shader or something else getting in the way. You can blast my head with a log for not following my own advice. -.-

BTW...

- Illumination is brighter and more coherent, although maybe before it had "more personality" (with those red and green parts).

With all due respect to Akom's hard work, I highly doubt that lights without lightsources can be called "personality".

[Akom74]

Well, apparently the "water fog" glitch doesn't happen anymore, so I've restored the fog to the map. It seems that there's a shader or something else getting in the way. You can blast my head with a log for not following my own advice. -.-

BTW...

- Illumination is brighter and more coherent, although maybe before it had "more personality" (with those red and green parts).

With all due respect to Akom's hard work, I highly doubt that lights without lightsources can be called "personality".

No blast, don't worry 

In The Crypt map, every light have a source, the other lights are only to improve the effect without touch the original shader.

[Gig]

My point is that I don't see the meaning of a DOM match of less than 3 control points.

I think it would be good with three DOM points, placed symmetrically due to the fact that map is symmetrical.

- Illumination is brighter and more coherent, although maybe before it had "more personality" (with those red and green parts).

With all due respect to Akom's hard work, I highly doubt that lights without lightsources can be called "personality".

Obviously, "personality" was not referring to the fact of being without lightsources, but to the fact that there were some green recesses, some red recesses, etc. One may have preserved a part of them, placing corresponding colored lamps at certain points.   However, the map illumination can work also how it's now.... that's a thing Akom should give an opinion. 

PS: Didn't you send a PM to everybody, to inform about RC2? Also the first post of the thread still mentions RC1. Do you plan a RC2v2 to include the map with the fog, maybe?

[Gig]

Next step of feedback about RC2 + z_1312302-oa-akomdm1.pk3

I gave a quick look to all maps, this time even with flares and bloom turned on. In general, things seem good. With a clean OA install, now I don't have issues with lights in Moxie's maps.

OA_AKOMDM1:
- Thank you NK for re-inserting the fog.  
- Don't forget to update the levelshot, now that there is the fog.
- Look at the first screenshot attached. Do you see that health bonus? Being the map quite specular, one may have expected to find some bonus also at the opposite side of the corridor (where there is a corner specular with this one), but there is nothing there (unless there is a powerup that does not appear at map start). Strange? Bug? Purpose?
- For other small details about this map that may be fixed, see previous posts.

Other maps from Akom:
- I have not noticed problems (this does not necessarily mean there are not), with the quick look.
- Maybe one may add a general playerclip ceiling to prevent rocket-jumping to the roof of the temple in OA_AKOMDM5, then hiding/camping there, as Suizicer noticed a few weeks ago? I don't know if that's really necessary.

Moixie's DM MAP:
- Here and there, there are various pick-ups (ammo boxes, health bonuses like in the second screenshot...) that have their model partially entering the ground with its movement. Maybe may be moved a few units up?

Moixie's CTF MAP:
- I already said about BOTs problem with gametype-dependent walls.
- Red and blue rooms are just a bit too dark, maybe? I don't know.
- Look at the third screenshot, there are a few flares generated in places where there is no "lamp texture".
- About flares, are we sure all those in this map do not interefere with players' visual? Probably not, but I'd like to read also other people's thoughts.
- Some framerate slowdown with bloom and flares on, however users can turn them off.

Jan's maps:
- I think nothing changed yet, right? So, no music yet in the CTF one, etc.

Udestruction:
- Compared with other maps, maybe it's really darker. I'm going to do a try to add some ambient light, although I know it's not recommended, and IIRC it slows down map compiling a lot. Which values to you think I should try?

About packaging:
- I gave a quick look to the .cfg files. They seem to be mappools for the "DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/G_autonextmap]g_autonextmap" feature, not classic "map rotation scripts". I was thinking to classic "map rotation scripts", like this small (untested) example (g_gametype is repeated each time to restore correct behavior after a vote changed gametype):

// OACMP Volume 1 - Free For All Rotation
set d1 "g_gametype 0; bot_minplayers 3; fraglimit 15; map oacmpdm1; set nextmap vstr d2"
set d2 "g_gametype 0; bot_minplayers 2; fraglimit 10; map oacmpdm4; set nextmap vstr d3"
set d3 "g_gametype 0; bot_minplayers 6; fraglimit 30; map oacmpdm10; set nextmap vstr d1"
vstr d1 // start loop at d1

However it may be interesting to also keep g_autonextmap pools, but I suppose we should keep in mind that the "default" OA maplists will be very different in OA3, so those "restoring original behavior" files like "oacmp_maps_harvester_original.cfg" would work for 0.8.8 only. For enabling and disabling the OACMP1 mappools, maybe we may include two cfg files to be executed with "/exec filename" (mentioning this in a comment inside the file and/or in the main readme file): the first one will correctly set g_votemappols variable to read all those oacmp1 pools you created; the second one will simply do "reset g_mappools" ("\reset <variable>" command does restore a variable to the default setting provided by the OpenArena version in use). So, all those "_original" cfg files may be removed (and if there are more gametypes which share the same mappol -e.g. CTF, EliminationCTF, OneFlag, Harvester and Overload are supported by the same OACMP1 maps, right?-, I can guess even fewer .cfg files may be used, if you wish) What do you think about that? Another thing to notice: those cfg filenames should mention oacmp1 (because there will be future OACMPs which will have their own configuration scripts).

- All the "readme files" are in the .ZIP only... apart from COPYING file (that may be renamed to COPYING.TXT for the sake of Windows users), there are no other infos of any kind provided inside the pk3. This should be fixed, for the final version.
- About individual readme files: Jan's do mention less gametypes than those actually supported (at least for the CTF one), the date is old, and does not mention Pelya's help with the CTF map. Akom and Moixie maps have no readme file.
- About main readme file:
-- it would be better in Windows format
-- it should mention "Volume 1" (we know there will be at least a volume 2  ), in both filename (e.g. OACMP1-Readme.txt) and contained text.
-- It should mention "the pack has been tested with OpenArena 0.8.8" (I mean, we are not responsible for problems with 0.8.5 or previous. And we cannot be 100% sure it will work flawlessy in OA3: hopefully yes, but we cannot be absolutely sure.).
-- It may also mention map rotation scripts/map pools existence.
-- Is there a reason those who only tested are not directly credited? Due to the fact they would have been too many? However, Pelya should be also credited for the "test server", isn't it?
-- As previously stated, some infos in the "final" pk3 should give some indication about where to download the package with sources. Maybe a generic link to (DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/OpenArena_Community_Mappack may be enough (from that page, we will create other pages about each OACMP Volume, which will contain download links). Main readme may also refer to that page "for more infos about this package and future OACMP packs".

- I can guess "Under Destruction texture sources README.txt" may be moved into the "udestruction" folder (sources/textures/udestruction).

- After that, you may also rename that "udestruction" folder to "gig01", to fit the folder name used in the .pk3
- And maybe you may slightly edit "Under Destruction texture sources README.txt" to add a mention to OACMPDM10 name inside it (when I wrote that small readme file, I was not sure about the final naming of maps).



*** In general, I have to say CONGRATS to everyone involved with the project, starting from Neon Knight. ***

[Neon_Knight]

PS: Didn't you send a PM to everybody, to inform about RC2? Also the first post of the thread still mentions RC1. Do you plan a RC2v2 to include the map with the fog, maybe?

Argh, I knew I forgot something!
Doing that right now!