OpenArena Community Mappack Volume 1 v3 Re-Release

[Akom74]

@Gig @Akom Did oacmpctf1 crash when you tested it in OACMP ver2 package? Can you please check again? Also, what happens if you replace all textures with textures from OACMP ver3 package? It seems strange to me that just replacing the texture caused it to crash.

No no, in V2 there's no issues about this, in V3 yes, don't know why..... 
In V2 also the white texture give the same message, but it works..... i really don't know what to tell about this.....
.....
@Neon_Knight: are you sure you don't change a .shader in the wrong way ? Maybe it's a stupid question, but it's possible that it's a shader file that cause this issue.

[Neon_Knight]

I've found the error, and it's way dumber than it sounds, and I'm the one to blame. -.-
The game doesn't support progressively-encoded JPG files. It crashes when it tries to load one. Accidentally, I've saved the red effect texture with progressive encoding.
I've re-saved it without such compression, and the map loads fine.
Damn me. -.-

[Neon_Knight]

- Buggy fog of oacmpdm9 fixed.
- oacmpdm1 misaligned torches and some dark areas fixed.
- "Too dark" bug won't be fixed.
- Suspended items in oacmpdm7 fixed.
- Troublesome texture on oacmpctf1 fixed.
- Also fixed: recompiled all the maps with -subdivisions 0. They now show awesome curves!
- Also fixed: optimizations to brushwork, patchwork and botplay in oacmpdm4. Only lighting remains. The map layout and item placement is kept intact.

Uploading tomorrow a beta, 30/1 the v4 final release. GTG and have some more fixes to do so the pack can be finally delivered.

[pelya]

Brighter sky shader in oacmpctf1, please please


_{* puppy not mine}

[Gig]

For completeness, a few other (minor) "problems":
- Do you think it's possible to get levelshots without those yellow dots in the upper left corner?
- "Copying" file in .pk3 lacks .txt extension.
- No "readme" file for OACMPDM8 and OACMPCTF2.
- Main readme file in the .zip may mention the availablity of the single player mod (specifying it's designed for OA 0.8.8 and it's OPTIONAL). Alternatively, it may have its own "readme" file. Maybe mods "description" may mention "Volume 1".
- Oacmpctf2 (moixie ctf): in Dom mode, I remember that in Volume 1 version 1 at least one quad damage did spawn in the same exact place of the dom point. I haven't checked if this is still true, but I can guess so.
- Maybe you may even remove those "map pools" .cfg files which are useless at the moment, due to their filenames to long to be actually used. Alternative may be using shorter names for them, and placing apposite scripts to enable and disable the feature.

Brighter sky shader in oacmpctf1, please please

In case of this, it should be checked what would happen to other jan's maps. I do not know if they use the same exact sky shader, or just a similar one.
In case oacmpctf1 is recompiled, one might also consider making lateral tunnels a little more bright (Akom asked for that, IIRC) and to add there a few machinegun ammo (I asked for that). However, those are not mandatory.

PS:

- Also fixed: optimizations to brushwork, patchwork and botplay in oacmpdm4. Only lighting remains. The map layout and item placement is kept intact.

I thought dm4 was still as Akom did it, and it was considered "Completed and perfectly okay" for months (well, also other maps from Akom were considered "already completed" up to the last days of December...). Considering what happened with other maps "reworked in 2014" (ended up darker than original, some "new" bugs...), are you sure that modifying it now is a good idea?  

PPS: Has someone an idea if some current maps do cause "bot stutter", maybe?

[Neon_Knight]

The thing is that now I've discovered how to get perfect curves ingame instead of ugly triangled curves. I've never used -subdivisions 0 in the BSP stage (the option isn't present in q3map2build, I had to add it) and it shows now perfectly rounded curves even if I use -meta and -patchmeta.

Besides, as I've said in the dev thread, mapping is 50% learning and 50% practice. Nobody knows the editor or concepts at 100% and should be open to learn new things.

Since there were no readme files for those, I might create them.

[pelya]

Will there be any FPS hit with new perfect curves? I suppose videocard will be drawing a lot more tiny triangles.

[Gig]

Will there be any FPS hit with new perfect curves? I suppose videocard will be drawing a lot more tiny triangles.

Right, this may be important. Also, while testing, try with different r_subdivisions values (linked to "DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Manual/Graphic_options#Geometric_detail]geometric detail" option in menu) in-game.

/r_subdivisions <number> variable: it affects curves (that will be shown more or less smooth). "High" is 4 (the default), "medium" is 12 and "low" is 20. A vid_restart if required after changing the value in console. It is possible to set a quality higher than "high" by setting r_subdivisions to 0 or 1, however remember your custom value will be overwritten when you will make some other change in the "graphics" menu.
Videoflags locks, if engaged (by default), prevent users from using r_subdivisions values higher than 20.

If we are not sure, we may do more accurate testing for OACMP Volume 2...

[Neon_Knight]

There's r_subdivisions to control how curves are drawn by the engine. Before, this command was irrelevant as the curves were baked with a preset subdivision.
Besides, the curves of the pack aren't really that complex (even on oacmpdm8, the most curve complex map of the pack). They're on par with those of Q3A. In all realty, there shouldn't be much of a difference.

EDIT: Ninja'd by Gig.

[Gig]

Done a few tests with r_subdivisions, and I discovered that r_subdivisions set to 0 may show some ugly glitches with some curves. I don't know the reason^[1]. So, maybe r_subdivisions 1 may be safer than 0?

Please look at the attached images.

Test2 shows the glitch.
Test3 is taken with r_showtris enabled, to see how much more complex geometry is rendered.


^[1] Maybe one should not set r_subdivisions to a value lower than the -subdivisions value used during map compiling? Just an idea. I don't know. Does someone know what's the default value q3map2 uses if no "-subdivisions" value is specified? 1? 4? I don't know.

[fromhell]

If there's too many vertices on a surface (>1000) it will fall back to the highest subdivision level.

I would also prefer the subdivision number to not be reduced so low as well.

[Neon_Knight]

Any ideal value for subdivisions? I mean, in the BSP stage, r_subdivisions is another thing IMHO.

[Gig]

Just a secondary thought. Maybe one may place a small text file in "textures/xcsv" folder, where to explain <<Don't worry, although folder name may seem to refer to the CC-licensed "XCSV Hi-res Q3 texture pack", these textures are NOT those from that package.>>.

Just an idea.

[Akom74]

Brighter sky shader in oacmpctf1, please please

Brightness need to be fixed i think, the only map i've seen right it's my 4 map.
The others are very darker than before.
Don't know why, maybe the value in the script need to be raised up ?

I'm asking this not for me, but for the community that will donwload the pack.
As i've said, these are not my map anymore.

[Gig]

Two very, very small notes about oacmpdm6 (not really relevant, but just to say):
- First screenshot: occasionally, bots tend to run against that column, before continuing to move. Strange.
- Second screenshot: that area has got something strange (illumination maybe? Probably patch texture aligment...)... :-/

UPDATE: I did forgot to upload the second screenshot. Now it is attached.

[Neon_Knight]

Now I've found out why -subdivisions wasn't documented elsewhere. It seems to give nicer curves and an overall better look at the expense of a higher BSP size and more tris to render.

[fromhell]

and that's why you shouldn't use it. What happened to 'don't fix what ain't broke'?

[Neon_Knight]

Due to certain things which were happening to me (constant energy cuts in the city I live due to storms, and some other personal problems) I'm only going to deliver the following updated maps with the rest of the pack:

- Buggy fog of oacmpdm9 fixed.
- oacmpdm1 misaligned torches and some dark areas fixed.
- "Too dark" bug won't be fixed.
- Suspended items in oacmpdm7 fixed.
- Troublesome texture on oacmpctf1 fixed.

The rest will be kept untouched.

Uploading the pack in two hours.

[Gig]

NOTICE: I wrote this post AT THE SAME TIME Neon Knight was writing his one just above this.

Hi NK, how's going with fixing?

- While I was trying the maps on Harvester mode, I noticed a strange bots bug in OACMPCTF2. As you can see in the first two screenshots attached, two red bots did "stay still" there, seeming camping... but there is something strange: apart from there is so much action around and they stand still where they are, they are also suspended from the ground. Also, on the opposite part of the map, two blue bots were doing exactly the same. Could you please check? This sounds a medium/high priority one.
-- About oacmpctf2, there is still also that minor problem of some flare-emitting light entities placed in wrong places (see third screenshot).
-- Maybe the fact that so many lights emit "flares" may be a performance issue, with flares turned on...
-- Is it possible that instead the problem of the quad damage spawning together to a gametype objective (Dom point maybe? I don't remember.. that was from V1) has already been fixed, in V3?

- Very, very minor problem of OACMPCTF3 and OACMPDM4: if the player falls in the void, its corpse does not immediately explode, but lies on the invisible bottom (see fourth screenshot). I don't know if this is worth spending some time, I just mention it.

PS: In case someone did not notice, I added the missing screenshot in the post above. Sorry for the inconvenience.

PPS: NK, not even levelshots without yellow dots?

[Neon_Knight]

oacmpdm4 in its actual state (v3) doesn't properly pass the light stage (too many verts), and as a result the map looks overbright, as if it wasn't lit at all. The VIS stage reports over 9000 portals [NOT A MEME], something like 9225 or so. I've managed to reduce this to 3800 and make the map compilable by detailbrushing and turning many stuff into models (arches and the stuff at the cabins). But the compilation switches I use doesn't make the map to look the same as it was in v3, so I had to work the lighting as well. I don't think such fixed version will make the cut for the final pack, as there's a lot of work to be done.

Also with oacmpdm4 I've learnt why "_minlight" is preferable to "ambient" or "_ambient": the latter switches add value to the light entities while the former doesn't. Suppose that you have a light entity with value 30. With ambient = 20, the overall level is lit with a value of 20, but the light entity now has a value of 50! With minlight = 20 the overall level has a value of 20 but the light entity still keeps its value of 30. I might consider this for future levels and I can finally get rid of the tons of light sources without having the map look too dark!

About oacmpctf2 I thought to have solved those bugs. I'll re-check again. About flares, well, too many flares on is a problem in maps with too many light sources, this is why for 0.8.8 am_galmevish2 had to be recompiled without them. I might have to do this as well with oacmpctf2.

EDIT: confirmed bug for harvester/overload bases for oacmpctf2. I don't know how such a detail escaped to me. -.- Fixed.

[Gig]

About dm4, I agree it may be safer to just use Akom's original version, to avoid the risk of new major bugs.

I really hope V4 will be the last re-packaging.

PS: About ctf2, what about keeping flares only on the lights of the outer part of the map, removing them from the small lights near to the ground? Just an idea...

[Neon_Knight]

The way flares are implemented in OA (they're shader-dependant) don't allow that unless new shaders are written.

[Gig]

The way flares are implemented in OA (they're shader-dependant) don't allow that unless new shaders are written.

Oh... I never tried adding flares. I did guess they were entities-dependant: I imagined there was some additional key to set in a light entity, to enable flares for it (and then compile the map with right options, of course). I was wrong, patience. That's another topic that may be interesting for the mapping tutorial, if you have not written about it already.

EDIT: confirmed bug for harvester/overload bases for oacmpctf2. I don't know how such a detail escaped to me. -.- Fixed.

Because we all are just humans.

[Neon_Knight]

Like I said, mapping is 50% learning and 50% practice. You learn new things every time you create a map, isn't it?
With this pack I've learnt a lot of things I haven't and remembered a lot of things I forgot.

[Neon_Knight]

oacmpctf3 glitch fixed. But this called heavily my attention:
- v3 size: 10.6 MB
After turning all the complex stuff into .ase models (and their original brushes to weaponclip models):
- v3.5 size: 6.7 MB

I still don't know if it's that or the fact that I removed three switches from the light stage of my "final compile" command line (-dark -dirty and -filter) the responsible of such size loss.

oacmpdm9 though can't be solved with this method, because of the complexity of the map itself. Or the fact that there's still a lot of stuff to make into models. (The Chaingun area, bridge included, and the RL "minihouse" could be some)