OpenArena Message Boards

Due to some certain problems, first with a pair of bugs and then with a non-Free asset, the OpenArena Community Mappack Volume 1 had to be, well, repackaged. The good thing is that this time the 100% of it is still GPLv2-compliant. Server admins who are going to use the pack should delete the old versions of this pack (and if you were using betas, those as well) and use this new version instead. Likewise, people who's going to mirror this pack must use this version and delete the older ones.

And, in the name of the OACMP team, sorry for all of the inconveniences!


For information about the pack, head this way (http://openarena.ws/board/index.php?topic=4899.0).


We are also gauging interest for the second volume, so if you like to map, we're waiting for you in the Maps subforum (http://openarena.ws/board/index.php?topic=4901.0)!

Hey, I just got offline half day and a lot of things happened!

Then, let me understand.
"Oacmp-volume1-v2.zip" has got a few textures which were not GPLv2, but CC-something instead.
So, NK somehow changed them with something else and re-uploaded an updated version of the pack "Oacmp-volume1-v3.zip".

So, people holding v2 or previous (betas, rc), should delete them.

Please, whoever uploaded the v2 pack to other sites, then delete the old one, and upload the new one.

At the moment, there are various v2 mirrors still working! Who can, please pull them out/update them!
http://www.atomicgamer.com/files/106800/openarena-community-mappack-volume-1
http://www.moddb.com/games/openarena/addons/openarena-community-map-pack-volume-1
http://download.tuxfamily.org/openarena/upload/oacmp-volume1-v2.zip
Pleople will have to do not be able to download v2 anymore: please remove the old files from those servers.

PS: I can't find those links now, but I remember that Akom uploaded it to mega and box.com, maybe?


PPS: I just DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/index.php?title=OACMP%2FVolume_1&diff=15971&oldid=15887]updated the wiki page (http://([b) for V3, adding a note about deleting older versions. I suppose that note should remain in that page for at least some monts (of course, it may be better "refined" if necessary, and be kept there forever).

Waiting for the definitive release.

;)

Gig, the older link at ModDB is already gone, I have deleted it.
Here's the new link at ModDB: http://www.moddb.com/members/neon-knight/addons/openarena-community-mappack-volume-1-v3-re-release
I have also uploaded it at Tuxfamily: http://download.tuxfamily.org/openarena/upload/oacmp-volume1-v3.zip
All that remains is Atomicgamer, which I'll do now.

This post:
http://openarena.ws/board/index.php?topic=4899.msg49686#msg49686
still contains some v2 links which seem working (their maintainers should remove those files, please):
- http://sourceforge.net/projects/libsdl-android/files/OpenArena/0.8.8/oacmp-volume1-v2.zip/download Sourceforge (I can guess this is from Pelya).
- https://app.box.com/s/qlsoj1ghbau5n71sdfyy (Akom's?)
- Mega (https://mega.co.nz/#!zwp2iSjZ!ddOfkWKj8NLa3lo9KFgGnEa0jz1z532_8HiIgRtAblY) (Akom's? Removing the link from your web site isn't enough, better to also delete the file from the cyberlocker).
- http://download.tuxfamily.org/openarena/upload/oacmp-volume1-v2.zip Tuxfamily (Neon Knight maybe?)
http://www.atomicgamer.com/files/106800/openarena-community-mappack-volume-1 Atomic Gamer (NK said he will take care of this)

Also, the post itself (http://openarena.ws/board/index.php?topic=4899.msg49686#msg49686) should be updated with new links.

By the way, what's the exact situation of that problematic texture? XCSV sounds to be this CC replacement package (http://ioquake3.org/2010/08/24/high-resolution-creative-commons-texture-replacement-pack/), hi-res textures for Q3A. But it seems a bit strange that of all the files in XCSV folder, only one was actually taken/edited from that package (http://openarena.ws/board/index.php?topic=4899.msg49791#msg49791). Has anyone asked Jan for infos?

I can't edit anything because the post is blocked  ::)
I'm deleting the file at the sources in my accounts.

;)

Well, that post is closed. The best thing which can be done is to delete those links from the forum. But I don't want to bother fromhell much of what I have already bothered. :/

About the XCSV package, yeah, it was indeed mostly a false alarm, but a derivated texture from that NC-ND package indeed slipped out. And nobody reported this in a whole year.

Well, nobody notice this, even you. Things happens :P :P

By the way, now we are ready ? I mean, the pack (V3) can be considered the official one ?

 ;)

I can guess yes, but however I asked Jan to explain here what happened. If you prefer to wait for his explaination, to be sure there are no other problems...

Hey guys, I was testing the maps to place them in our *SoS*-server... and with the v1.3 mappack there is 1 problem on my machine that I got only with version v1.3(I hope only mine). All maps work apart from oacmpctf1. Screenshot loads and then OA crashes and give me an error (see attechement).
/!\ Please try someone to open OA, write /g_gametype 4 and /map oacmpctf1 and report if you got the same problem. (I hope it is  just me, then I will see how to fix that. And no, I don't have this map twice in my baseoa-folder )

With version 3, I have the same problem, which does not happen with version 2.

It seems a problem that does not prevent a dedicated server to run, but prevents clients from playing (dedicated servers managers may not recognize it immediately)!!!!

DDDDDD'OOOOHHHHHH!!!

How's possible that just replacing a jpg file did that?
Uhm... I see the v2 jpg (xcsv/metalfloor_wall_14bglow2r.jpg, right?) was 512x512, 72dpi, 24bit. V3 jpg is 256x256, 72dpi, 24bit.
Maybe a 512x512 replacement (or map recompiling) was needed, because the map was compiled with a such dimension texture? I didn't thought there were such problems...  :-\

Oh, no, not again... -.-

http://tvtropes.org/pmwiki/pmwiki.php/Main/MurphysLaw
http://tvtropes.org/pmwiki/pmwiki.php/Main/FinaglesLaw

 :(

I'll solve this. After solving it, CAN I FOCUS ON THE OTHER THINGS I COULDN'T FOCUS YET?

Of course, my friend.... Obviously, if the fix does not cause more major problems. We do not seem very lucky, lately...  :-\

You know, all of this started because the guy who reported the violation said that he already knew about it while the pack was in development, but he told us about such bug only after the pack was released. And we had an entire year of development.

I've also found why Jan's maps played the windfly sound. This is an excerpt from the GTKR Manual:


I have never checked if Jan's maps used target_push instead of trigger_push, though.

I've updated my server with v3. I did not notice crash with oacmpctf1, I've tested with clean OA 0.8.8.
Also, Android package and servers are updated, and include this pack.

Maybe the crash happens on Windows only? It happened to both me (on two different machines) and Adriano... a problem does exist!

I really think you should have waited for v4 before updating android package and servers with the pack!

Neon_Knight, will you re-compile the map with the 256x256 texture, or will scale up the texture with an image editor, to have it 512x512?

In case of the second one, I tried to simply scale up the red texture with Photoshop. You can find it attached here, compared with the "old" (V3) version.

I haven't tried it in-game yet.

UPDATE: I packaged it into a pk3 called "_test.pk3" (attached here), but the map still crashes! What do I did wrong?

NK, are you sure that .jpg file was really the only one difference between V2 and V3? Uhm... looking for file dates inside V2 and V3 pk3, that one image really seems the only one modified that day... I don't understand.

Don't know what to tell, but i have the same error and the game shutdown.

Here is the log:


It seems that the problem it's caused by textures/q3j/white.tga
Don't know why  ???

;)

@Gig @Akom Did oacmpctf1 crash when you tested it in OACMP ver2 package (http://sourceforge.net/projects/libsdl-android/files/tmp/z_oacmp-volume1-v2.pk3/download)? Can you please check again? Also, what happens if you replace all textures with textures from OACMP ver3 package (http://sourceforge.net/projects/libsdl-android/files/OpenArena/0.8.8/z_oacmp-volume1-v3.pk3/download)? It seems strange to me that just replacing the texture caused it to crash.

That "warning" line about white.tga is displayed also if using Version2, which does not crash...  :-\

Are you all really sure that there's no other "surprise" in the pack? Because I'm not going to release a v5 even if there's a big problem.

I'll release a v4 tomorrow and move on to other things.

I just tried to re-package the original XCSV texture (CC licensed!!!!!!) into a separate pk3, and use it together with V3.... and it works!

You can download the attached file (_test2_NONgpl.pk3) for testing purposes only: it's NOT GPL (it uses a restrictive CC license instead), you CANNOT use it on GPL servers.

What can make the original XCSV file so different than the other JPGs?

Opening it with notepad++, I see it has got various XML-style code at its beginning (EXIF data maybe?)... maybe the map compiling process used some of those data? I really have no idea....

Completely sure not... the issues I remember (just listing, without considering their weight):
- the buggy fog of oacmpdm9,
- Pelya and Akom mentioned some maps which seem to be too dark after recent changes
- a couple of misaligned torches in dm1
- strangely suspended items in moixie's dm map...
- Other??????

I don't remember other problems right now.... I don't know if those brightness problems are major, you know I have difficulties in figuring out the right brighness level.

But from when the ctf1 problem has been pointed out, I haven't tried other maps anymore... I don't know if others did...

PS: I will not be able to perform any more tests today.  :-[ Pelya, could you please do some more?

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.

;)

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. -.-

- 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.

Brighter sky shader in oacmpctf1, please please

(http://i.imgur.com/JxuujOal.jpg)
_{* puppy not mine}

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 (http://openarena.ws/board/index.php?topic=4679.msg49699#msg49699).

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:
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?

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.

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 (http://([b)" option in menu) in-game.

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

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.

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.

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.

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

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.

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.

;)

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.

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.

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

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:
The rest will be kept untouched.

Uploading the pack in two hours.

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 (http://openarena.ws/board/index.php?topic=4905.msg49885#msg49885). Sorry for the inconvenience.

PPS: NK, not even levelshots without yellow dots?

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.

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...

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. :)

Because we all are just humans. :)

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.

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)

I'm sorry... I know something about .md3 models, but I have no idea about what an .ase model is.  ???
In general, I can only suppose that turning too much geometry from structural to detail or to models may risk to be backfiring, causing faster compiling time, but lower framerate in-game. But I'm not an expert.

About oacmpctf3 glitch, do you mean the one of the corpse did not explode at the bottom of the "void"? Could you please explain how to achieve the body explosion, so Akom may fix his DM4 map, too? Probably it's something easy such as extending the "killing" trigger to make it reach the bottom, but I don't know and I don't want to cause more bugs, so it would be better to follow a clear instruction about how to get it. I can guess we may take a look to Moixie's DM map .map...  :)

About the "maps edited in January look darker than originals", I just took two screenshots (with r_gamma 1) of Akom's CTF map: the first one from the "current" OACMP1 V3 (compiled by Neon_Knight), and the second one from the previous OACMP1 RC2 (compiled by Akom). I have the impression NK version has really got some parts too dark...
Is it possible that those Q3MAP2 options you mentioned above (e.g. -dirty) may have a role in this?

About mapmodels, I wrote a page for the mapping manual some days about this. It's the mapmodels page and it also explains what .ase models are and how and why to use such feature.

About oacmpctf3, I already took care of the bug and also raised the lighting of the level. The process about the creation of death pits is already explained in the mapping manual too.

About lighting on levels: that darkness was indeed caused by some of that and my (then) lack of enough knowledge of what _minlight does. Now that I've learned what it does, the old level of lighting may come back.

However, I can guess even _minlight may not be the magic wand for all problems. I mean, also it may risk to "flatten the difference between enlighted and dark parts"... isn't so?

_ambient light in general does that. And it also makes the weapon/item models to look dark in lighted environemts, making it a "lighting contradiction". _minlight isn't also a recommended solution, (the best solution is to light the level oneself placing the light entities where they should go) but IMHO it's better than ambient light.

Well, here it is.

http://www.onykage.com/files/armageddonman/!oacmp/oacmp-volume1-v4-beta.zip (http://www.onykage.com/files/armageddonman/!oacmp/oacmp-volume1-v4-beta.zip)

Due to space issues, the v3 version was deleted, so this would be v3.5. ONLY FOR TESTING PURPOSES.

The only maps not modified regarding v3 are oacmpdm4, oacmpdm6, oacmpdm8 and oacmpdm10. All of the other maps have been modified in one way or another. I've dropped my changes to oacmpdm4, though the models I've extracted from it are still in the pack. The sources for these models (.map files) are also included, in the models folder inside of sources.
I've also renamed the xcsv folder to oacmp_jan, changes in shaders and references in maps included. That way, those who use the xcsv original package doesn't get problems.

Also, I still have to figure out how to cut the size of oacmpdm9. 13MB for a small map is just too much. Especially now that the fog was removed.

The release date is still 30/1. 1/2 at worst.

The .bsp size is determined by amount of detail/rooms/triangles in the map, not by map geometrical dimensions. Setting big allclip areas around torches/ceiling/complicated geometry might help a little.
Testing it now. Mirrored it just in case, I'll remove this link in few days (http://sourceforge.net/projects/libsdl-android/files/tmp/oacmp-volume1-v4-beta.zip/download)

Well, oacmpdm9 in that regard is extremely detailed. I've removed a lot of stuff but the outer floor itself is extremely detailed.

Oh, V4 beta without waiting for Akom fixing his DM4 deadly pit?  :(
Well, I'll try that on Monday. I hope to have some time.

Neon_Knight, I thing is not clear here:
(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Mapping_manual/Creating_dynamic_features#Death_pits
It talks about "half of the bottom" sized triggers... but I don't get what does it mean exactly. Also, then it mentions to make a brush sized 1.5x the previous one.. but horizontally, vertically, or both? I can guess vertically... Could you please check if that's clear enough? Maybe also a screenshot may help...

Vertically, I thought it was clear.

I'll try to release a fixed version of oacmpdm4 this monday, however don't count on it being the same as the v3 version.

I've tested it, and there are some issues (Akom I'm sorry for lot of big images).

dm1 - OK, it seems a bit brighter now in lateral tunnels, but I'm not really sure, the difference is small.

dm2 - OK. I did not notice misaligned lamps. Lighting is okay.

dm3 - OK, did not notice any issues. Lighting is good.

dm4 - not tested.

dm5 - there is a missing texture here:

(http://i.imgur.com/MAjGH8Q.jpg) (http://i.imgur.com/ZNIThDg.jpg)

Also, slight white line between textures, but it's minor bug. Lighting is good.

(http://i.imgur.com/u6VjRqw.jpg) (http://i.imgur.com/7gLzAi8.jpg)

dm6 - not tested.

dm7 - lot of items on the death pit floor, is this intentional? Also, I've tried to use bottom jumppad 5 times, and died each time, maybe it's my sloppy playing on cellphone, maybe not. Lighting OK.

(http://i.imgur.com/5JnZlzs.jpg) (http://i.imgur.com/SnBM0NO.jpg)

dm8 - not tested.

dm9 - uhh, why death pit now have concrete floor? It looks like big gray box now. Please bring back the fog to cover that ugliness. Lighting OK.

(http://i.imgur.com/CeNJeh1.jpg) (http://i.imgur.com/mdjroRT.jpg)

dm10 - OK, did not notice bugs, now it's little dimmer, but lighting still within comfort range.

ctf1 - it's now way brighter, that makes it way better to play. Your map compiler played dirty jokes on you though, look at those screenshots:

(http://i.imgur.com/09UhTYs.jpg)

screenshot 1 (http://i.imgur.com/3WHOTIf.jpg)
screenshot 2 (http://i.imgur.com/pA0wBDS.jpg)
screenshot 3 (http://i.imgur.com/oMFqXsC.jpg)
screenshot 4 (http://i.imgur.com/3wHxBbQ.jpg)
screenshot 5 (http://i.imgur.com/I9pvzUm.jpg)

ctf2 - I remember lateral tunnels were brighter. Can you spot the bot?

(http://i.imgur.com/or80zgm.jpg) (http://i.imgur.com/5QP6Bbx.jpg)

ctf3 - OK, and the lighting still OK, despite that it's now darker than the original Akom's version.

Pelya, can you reduce the size of your images, please? Thank you.

Once you've done that, I'll be able to reply.

oacmpdm5 - That bug is a HoM, Hall of Mirrors. It's a classic bug where a BSP plane is broken by an interference. I can't do much against it except reworking that whole part.
oacmpdm7 - I've considered redoing the whole weapon/item placement, I also find it a bit too much.
oacmpdm9 - If the fog comes back the fog bug comes back with it as well. There's no way to separate them. :/
oacmpctf1 - Those bugs are pretty annoying. -.- There are also many texture misalignments.
oacmpctf2 - The map was recompiled without flares. I should have remade the whole lighting on that level, especially now that there isn't a sky providing light.

There's something I can do for oacmpdm9, though. What if I surround the map with a mountain and re-add the fog as a death fog? It could make the map even more complex than what it actually is, but at least the bug won't theorically appear. And the map would look more realistic.

It does not look like hall of mirrors to me in dm5, it looks like the geometry has a hole, because I can see the other part of level through the hole without any visual artifacts.
Is it possible to put a skybox instead of the solid floor on dm9? I've got impression you can put skybox everywhere, like in space maps.
I've fixed screenshots size.

Yeah, but the cause for dm5 may be the same. Brushwork.

Glitch solved in oacmpdm5.

A basic rule for map building: vertexes should meet with other vertexes, not with planes.

Here's a test of oacmpdm7 with new weapon/item placement. I still have to redo the lighting.

About dm4, if Akom has got some time to fix it, well. Otherwise, I think we can just keep the original version. It's not a serious issue... someone else heavily modifying the map now would be risky...

I doubt the impossibility to compile a map can be called a minor issue. If someone can't compile the map, then there's something bad about it and should be fixed.

The good thing is that the required work to make it compillable isn't really much. Just make some stuff detail and that's it.

I'll see what can I do tomorrow.

dm7: I've noticed some bugs in lighting (they were also in previous version, I've missed them). And there still are items in the death pit, although that's a minor thing.

I was referring to the corpse not exploding when reaching the bottom of the map...  ::)

Well, how can I fix that if I cannot compile the map? ::)

I can guess by using Q3radiant as Akom does...
... or as I told, we can live with that small defect.

It's not necessary to usa Q3Radiant, it's just a brush to move and recompile the map.
It can be maked with GTKradiant or NETradiant.

;)

I'm really confused now where this 'final' map pack is going.  I thought it was just a texture problem holding up the release?

Yeah, at first, but other problems surfaced. As I'm not going to release a v5, this is the last time to report and fix everything before v4 ships on 30/1. Just in case there are other... "surprises".

In case you didn't notice, just opening a map perfectly optimized with Q3Radiant (q3map) and re-compiling it from GTK/NetRadiant (q3map2) may skrew up optimizations such as lighting. Unfortunately.  :( And in some cases, it may even not compile successfully.   :-[

I think that optimizing all maps for q3map2 may have been a good thing, but probably we should have done the switch something like August 2013... having done this in 2014 (I mean, at final release time) seems to have caused brightness problems in various maps...

First of all, I just realized an important thing about "corpse not gibbing" glitch. The corpse DOES explode also in V3 versions of those maps (DM4 and CTF3), but you have the time to see the beginning of the death animation, unlike what happens in DM7, where you immediately explode. I can guess there is some difference in the position of the triggers, or something similar. But in my case, the corpse did not explode at all was also related to the fact I forgot DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Dmflags#Dmflags]DMFLAGS (http://([b) 1032 active (no self damage). However: with dmflags 1032, in V3 DM4 and CTF3 your corpse does not get gibbed at all when you fall in the void... while in DM7 it does. With dmflags 0, your corpse gets gibbed in all three maps, but in DM4 and CTF3 you did have the time to see the initial part of the death animation. V4 CTF3 has got immediate gibbing in both cases. I have no problem if DM4 is kept unfixed, the problem is less noticeable than I though before.

Giving a quick look to the V4-beta maps (quick run in gametype 0, no bots):

- I have not understood: DM4 is the version from Akom, or has been modified? This post said it has not been modified (http://openarena.ws/board/index.php?topic=4905.msg49920#msg49920), but in the .pk3 I can find some .ase "mapobjects" with their name starting with "akom4-".  :-\ .bsp "last modified" date reports 05/12/2013.
- DM5: I also noticed the thin "white dots line" Pelya noticed in this post (http://openarena.ws/board/index.php?topic=4905.msg49936#msg49936). More, I just realized that some jumps from the outer platforms to the central platform are possible with 125 Hz physics, but not (or at least, I have not been able to perform them with a few tries) with 90 Hz or "accurate" physics. See first screenshot attached. I'm sorry, I should have tested this before. You decide what to do.
- DM7: The V4Beta version has got some items dropped to the bottom of the void, and has got some parts too dark (especially the lower side of the arena). TEST version has still got too dark areas, and some new lights have something weird (are some red and yellow lights mixed?) -see third and fourth screenshots-. I don't know about the new item placement, maybe Moixie should tell... maybe this one may even be better, but however isn't it a bit too late to change map flow?  ???
- DM9: Now that it is without fog, that "end of the world" looks bad. Maybe Akom's original one was a bit better, with the sanctuary suspended in the air? Other ideas are welcome, too...
- DM10: I'm not sure what Pelya means exactly with "it's a little dimmer": I think it's still the same map than V3, no? .bsp file modify date reports 15/01/2014, just like in V3 and V2 (15/01/2014 is the date I released udestruction beta version 18 (http://openarena.ws/board/index.php?topic=4679.msg49668#msg49668), which added "ambient 2"). Do you mean there is less difference between light and dark? May be the side effect of ambient light (I purposely used a low "ambient" number trying to limit this side effect, but...). Or maybe you did mean something else?
- CTF2 I fear the bug I noticed here (http://openarena.ws/board/index.php?topic=4905.msg49900#msg49900) with bots standing still in that place, suspended from the ground, has not been fixed yet. I tried the map in Overload Harvester mode again (the only V4 map I tried with bots, for the moment), and after some time I found again Gargoyle where you see it in the second screenshot attached (standing still, suspended from the ground).  :(

OTHER (packaging, minor):
- Zip file -> sources/mapsources.txt says "The maps are located inside of the z_oacmp-volume1.pk3 file.". I can guess it should mention "z_oacmp-volume1-v4.pk3".
- Maybe the .pk3 file "sources" folder may contain a similar txt file, mentioning textures sources? However, that's already at the beginning of the main readme file, so it's not stricly necessary. Decide yourself.

Yep, oacmpdm4 wasn't modified at all, but I was modifying it. In the end I've decided to rollback those changes and keep the v3 version untouched, so those models are leftovers of those changes which didn't made the cut.

That part on dm5, I guess, shouldn't be reachable at all.

dm7 has lighting as a pending improvement. I can rollback oacmpdm7 to the previous placement, but there was a huge overload of items.

dm10 hasn't changed from the v1 release at all.

About the ctf2 bug, are you sure you don't see the flag platforms? Because the three models are aligned with them, and those platforms are already aligned with the obelisk models.

Note sure. Maybe we should ask what was Jan's idea?

Where did I mention missing "flag platforms"? :-/ I said there are bots appearing camping in the air, but I did not mention "flag platforms". The place of the screenshot is NOT next to flags/skull receptacles, but is on the extreme part of the map (near to that lightning gun spawn point). It's not in the middle of the room, but on the platform you get after a few stairs. Please give a better look to the first two screenshots at http://openarena.ws/board/index.php?topic=4905.msg49900#msg49900 to better distinguish about which place I'm talking about. Then, I have no idea which bug you did identify the other day (the one you were surprised you didn't notice before)... :-/ I'm a bit confused...

Maybe I misunderstood something from your post? Do you have some screenshot about the part you are talking about?

What are you talking about ?? The only difference is in the light that has to be incremented in the .shader (in case of skybox) or by entity light (in closed maps).

The geometry optimized rest as it is.

By the way, my Sanctuary map was surely better in the original version, but i think that for optimize it, it was necessary to do some changes....... :-[.....

I think that Neon_Knight does not matter about brightness problems, he likes dark maps  :P :P

;)

Maybe not exactly. I think Neon_Knight said he had do to some "under the hood" hacks to be able to correctly compile some of your maps, starting from "making detail" many brushes (a thing I fear may negatively affect in-game performances). When he did a try with a customized version of Under Destruction, apart the quite different lighting, a few strange things happened: a part of the water started "blinking"... and some textures were scaled up (those textures scaled up also appeared to me when I tried to move to q3map2 last summer), and framerate was lower. His version was not so bad in general, but it would have required to spend a lot of time for fixing it.

This happen in GTKradiant or in NETradiant ?

;)

Hi! I've prepared FIXED (meaning "corrected") mappools, that should be working (a quick try I did was successful).

Usage:
place this pk3 in your baseoa folder

/exec oacmp1_enable
 to set g_mappools variable
/exec oacmp1_disable
 to reset it to its default (load a map first).
Oacmp1_enable.cfg and oacmp1_disable.cfg files include brief usage infos. They do not control g_autonextmap variable, which should be set to 1 to use DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/G_autonextmap]auto change map (http://([b) feature.

I renamed the .cfg mappool files NK previously did, to make thir names shorter: now the g_mappools variable does not become too long and do not cause the game to crash anymore. I haven't modified the maplists themselves.

I hope I did not make mistakes, however you all are invited to check and test!  ;)

NK, could you please just remove the old .cfg files from the OACMP package, and place those from the pk3 attached here instead? I think that should be enough. Thank you!  :)

------------
@Akom: Ask NK.  :)
When I tried, last Summer, I had problems compiling from GTK Radiant, NetRadiant and Q3map2build, IIRC. They did compile the map, but the map showed some differences I did not know how to manage.

I'll replace them if they're correctly tested.

About GTKR, NetR and q3map2build, I still insist that there was something wrongly done with those installations of GTKR, NetR and q3map2build. I've been using those tools since I've started mapping for OA (I've even switched flawlessly from GTKR to NetR, which I currently use) and never had a problem with them.

The current guides on the wiki should be rewritten, though. Hopefully the Mapping manual will contain better info for GTKR/NetR configuration. And prior to that I have to finish the gamepacks.

ctf2: Bots spawned inside of botclip. Looking and floating bug in the areas marked by Gig solved.

White glitches in dm5: Won't be fixed. They're pretty complex to be fixed.

(I wonder why do they use fractionary grids to build maps -0.5, 0.25, 0.125-, when it isn't something recommended and for many good reasons...)

More tests with mappools performed (also thanks to "callvote nextmap"). They work very well!!!!  :) :) :) I think you can add them safely enough.  ;)

The only one which does not work at all is the "tourney" one. But it seems this is not due to the mappool, but due to some bug in gamecode (if Sago may give a look...  ;)), or simply due to how the "tournament" mode works. Does a "tournament" match ever end? However "/callvote nextmap" with g_gametype 1 causes the same map to be restarted also with default OA 0.8.8 mappoools: the problem is somewhere in gamecode... I suppose we should still include the tourney mappool, so if nextmap for tournament mode will ever be fixed, its mappool will start working. Other gametypes seem to work perfectly, instead.  :)

I also compared those mappool files with the map/gametype table in DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/OACMP/Volume_1]OACMP1 wiki page (http://([b), and thus I added oacmpdm5 to Elimination pool file (it was listed in the table -and in the .arena file-, but not in the mappool file). So you can use the updated package you find attached to this post.  ;)
Changes against yesterday version are just that small addition to Elimination pool, and the creation of a ".txt" file about "OACMP vol 1 auto change map" (not strictly necessary, due to the fact most of those infos are already in the .cfg files... but people may find simpler to open a .txt file than a .cfg file with a text editor): decide yourself if you want to include it.  :)

I also repeated the "items start solid" check for BETA4 maps:
- OACMPDM5 reports two item_health startsolid.
- OACMPDM7 (V4-beta version) reports many health items startsolid. (NK-Test version does not).

Note for who want to try OACMPDM7 NK TEST (from this post (http://openarena.ws/board/index.php?topic=4905.msg49943#msg49943)), remember rename "zz_dm7-test.pk3" to something like "_zz_dm7-test.pk3", otherwise the standard version of the map will be used instead.

Oh, yeah, forgot to mention.
Pelya's reported bugs on ctf1 fixed as well.

Might as well upload the pack with all the fixed maps.

Well, here's a small fixpack. Includes all the modified/fixed maps (ctf1, ctf2, dm5, dm7, dm9) It also includes the modified, compilable dm4.

http://www.onykage.com/files/armageddonman/!oacmp/z_oacmpv4-fixpack.pk3 (http://www.onykage.com/files/armageddonman/!oacmp/z_oacmpv4-fixpack.pk3)

Known issues:
- oacmpdm4 needs more lighting work.
- oacmpdm5 "sparklies", which won't be fixed.

Given a quick look to the edited maps...

- CTF1: Better now, although there are still a few small glitches (see the first three screenshots). In case you compile the map again, what about adding those famous few machinegun ammo boxes in the lateral tunnels?
- CTF2: the bots bug seems fixed now.  ;)
- DM4: Yes, more lighting work is required. However, how's possible that the sky light does not illuminate at all the vertical walls? Maybe some q3map2 options control how much light "bounces" and you disabled it completely, or something similar? It's very strange... However, I may also just live with Akom's original version of this map.
- DM5: the view-through polygon bug seems fixed. No, now the problem has just moved a few units below (a different brush), but is still there.  :-[
- DM7: not sure what actually changed from your previous "test" version. It seems quite similar to your previous "test" version... maybe the lower side (visible when you fall down) is even darker now? Is it normal that no items spawn around the hatch? Those red/yellow lights (fourth screenshot) still have something "strange", IMHO...
- DM9: Maybe now the skybox effect is a bit better (with the dark instead of concrete)... however the upper part of the map is really too dark (I cannot attach more screenshots to this post, however just look at the upper part of the buildings...).

dm4: as you've already said, more lighting work needed (ambient light perhaps).
dm5: another missing texture on the same place as before, and lighting bugs around bevels. Gig, are we using the same version?

 

dm7: inconsistent lighting at the upper platform, it's pitch dark on one side, and illuminated on other side.
dm9: lower area is much better now, and I don't care much about dark upper part of building. Would be nice to fix, but still a minor bug.
ctf1: okay now, I've noticed some Z-fighting if you shoot rocket in the middle tunnel, but that's minor.
ctf2: still too dark.

We are using the same version... but in the first quick run with the map, I didn't notice the bug had moved to the brush below the old one (about this, I corrected my post before you posted yours). About (lighiting?) bugs (black dots and lines), probably in the first quick run I confused some of those with some marks on walls caused by weapons. I confirm there are.
More, now I also noticed another thing: for some reason, those bevels do not show "marks on walls".

All the mentioned bugs makes me even more convinced that good brushwork should always be the rule while mapping.

OA3 should definitely enforce good brushwork and patchwork.

Apart from better or worse patchwork, I don't understand the reason why your compilings gave such different results than those Jan (and Pelya) got. I mean, I can understand some difference with maps that were previously compiled with Q3Radiant (mine and Akom's)... but Jan's were always compiled with Q3MAP2, isn't it?

And I still don't understand why do your compilings have such completely dark areas (like in DM4)... how's possible the sky does not illuminate vertical walls at all?  :-\

I base the final compile settings (sans -dark and -dirty) on those which appear on the Q3Map2 page.
http://en.wikibooks.org/wiki/Q3Map2


What I also use is some other switches, so this is really the final compile I use for the maps I compile:


(-flares in maps with tons of light sources like oacmpdm7 is omitted)

For BSPC I use this commandline in all of the maps:

Well, it's time to confess this.

I'm a dumb idiot. -.-

I forgot to add Akom's shaders to my shaderlist.txt. -.-

I think a higher value in the script will solve the problem (it can work also for the other maps of mine)


It's not a texture missing, it's a "brutal" graphic bug, i don't know why.
See it in spectator mode:

(http://i55.servimg.com/u/f55/13/33/70/40/shot0021.jpg)

;)

You are not an idiot, it's a solvable mistake :P
Don't worry.

;)

Note: while I was writing this post, three other replies were written in the meanwhile...

Q3MAP2 switches seem to be a sort of hell...  :-\

https://en.wikibooks.org/wiki/Q3Map2/Light#-fast

https://en.wikibooks.org/wiki/Q3Map2/Light#-gamma_.3CN.N.3E

https://en.wikibooks.org/wiki/Q3Map2/Light#-compensate_.3CN.N.3E

https://en.wikibooks.org/wiki/Q3Map2/Light#-sky_.3CN.N.3E
The one above may sound interesting for maps which come from Q3Radiant, maybe?

https://en.wikibooks.org/wiki/Q3Map2/Light#-bounce_.3CN.3E
Some tries with these, too?

Giving a quick look inside a few very, very older beta versions of oacmp maps:
From an *OLD* Moixie DM map .bsp file (something like February 2013):
"_q3map2_cmdline" "-meta -flares; -light -faster; -meta; -vis -saveprt; -light -fast -filter"

From an *OLD* Jan's "the other side" map .bsp file (something like February 2013):
"_q3map2_cmdline" "-meta; -vis -saveprt; -light -fast -super 2 -filter -bounce 8"


So...
https://en.wikibooks.org/wiki/Q3Map2/Light#-super_.3CN.3E
???

https://en.wikibooks.org/wiki/Q3Map2/Light#-filter

I'm quite lost...  ???

Note: "readme" files of some maps from Jan (inlcuded with OACMP zip and pk3) do mention some of the q3map2 switches he used. Such infos are now probably outdated. Maybe those lines should be removed by those readme files?

Update:
"Happens also in best families", as we say in Italy.  :)
I suppose something will need some more optimizations...

Well, nobody said that mapping is an easy thing.

There are some switches which were left in q3map2, but -samples does the same as them but in a better way. That's why I don't use -filter anymore, for example.

Also I do use -bounce. In fact, I use -bounce 8.

Yes, the first options I checked on that wiki where those you mentioned in your post.

But what dwould that additional "-bouncegrid" option do exactly?

[OT] I notice you have not downloaded latest mappols pk3 (http://openarena.ws/board/index.php?topic=4905.msg49981#msg49981) yet. Just a reminder.  ;)

Also, Gig, you forgot this:

(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Mapping_manual/Compiling_and_packaging

Argh!

By the way, maybe it would be better to split that quite long page into two distinct pages for compiling and packaging?

PS: In that veeery old version of jan's "the other side" map I tried a few minutes ago, bevels did get marks on walls...

Another thing: In ctf1 the sound is not loaded, it say "couldnt load OA03.ogg"
In central passages, looking up you can see another sort of texture that seems not choerent with the others.
In lateral passages still missing source light and some ammobox.

In CTF3 the red and blue light added from Neon_Knight emitt white light, it's a pouposed effect ?

;)

No, it's not.

I'm redoing all the lighting in your levels because of this omission of mine. -.-

BTW, ctf1 has overlapping brushes in the caves. That's why you could see the effect. This will be solved as well.

Another Update, sorry if i'm late :P

In the "Crypt" map the cross block the players:
(http://i55.servimg.com/u/f55/13/33/70/40/shot0022.jpg)

In "Danger Arena" please, remove the fog, the effect is so ugly.... :P
(http://i55.servimg.com/u/f55/13/33/70/40/shot0023.jpg)

I don't remember the name of the map, but it's really necessary to go so high ?
(http://i55.servimg.com/u/f55/13/33/70/40/shot0024.jpg)

I've found a glitch in that jump:
(http://i55.servimg.com/u/f55/13/33/70/40/shot0025.jpg)

In "Sanctuary" arena, now you can't die jumping here, it has to be fixed :P:
(http://i55.servimg.com/u/f55/13/33/70/40/shot0026.jpg)

@Gig: Are you kidding me ? (http://illiweb.com/fa/i/smiles/affraid.gif)(http://illiweb.com/fa/i/smiles/affraid.gif)  ;D
(http://i55.servimg.com/u/f55/13/33/70/40/shot0027.jpg)

Flags are uncentered, both:
(http://i55.servimg.com/u/f55/13/33/70/40/shot0028.jpg)

;)

dm1 - I'll clip.
dm2 - I'll remove it.
dm5 - That area shouldn't be reachable at all, indeed.
dm8 - I'll see what can I do about that.
dm9 - I'll fix.
dm10 - I'm not going to fix the map. That could be left to Gig, as I haven't touched his map at all.
ctf1 - I'll fix.

Thats an old friend of mine! We had some battles, i reconstructed that portion a few times, but then out of nowhere it would reapear.

Anyway, this was literally my first map, i'll never make a map with so many slightly off angle walls ever again, eventhough i think it does add to its unique look. Anyways, it only happens to me when i change something in that general area...what did you do?

Yes, in CPMA style physics you could use the ramps and a double rocket to jump from one end of the map to the other, but you do need some headroom for that.
Not present in the version i compiled.

Yeah i saw that one, i must ask, why are we recompiling maps? I've documented how i compiled them which should enable anyone with a computer and internet access to compile them exactly like i did, so why not use the binaries i supplied? Or use the exact tooling and compiler options?

A demonstration of why headroom is nice to have: http://www.youtube.com/watch?v=o96Eybzxztk

I do nothing, only spectate and roam in the map. It happen to Pelya too.
It's the last version compiled by Neon_knight.
http://openarena.ws/board/index.php?topic=4905.msg49983#msg49983


So high ? O my god...  :P :D


But in the version we have, there is the glitch, don't know what t tell you.  ??? ???

;)

Don't you know how that happens? You only want to replace one tiny little texture, and end up with 6 broken maps, 5 of which do not even use that texture  ;D
Similar thing happens to me every time, when I update Android build.

I may be too meticoulous at times, but this time you beated me...  :D
For the blue "bar" on the left, okay... I'm going to recompile the map, although I don't consider it a real issue (I'll have to scale up the texture on that face).
About the other blue parts you pointed out, I will not modify them: that's just how that texture natually is, showing some "junction points": in case I would modify the top side of those brushes, they would not fit anymore with the lateral side.

It's part of the GPLv2 compliance.

Because not everyone will have them. A map should be compilable using any compile set.

Under destruction version 19 is attached to this post (not a "standalone" package).

Changelog against Version 18 (http://openarena.ws/board/index.php?topic=4679.msg49668#msg49668):
- Fixed the texture on one side of a "blue bar" which appears in CTF mode (see post above (http://openarena.ws/board/index.php?topic=4905.msg50022#msg50022) for info) (Akom, is it okay now? By the way, some OACMP maps have worse imperfections (http://openarena.ws/board/index.php?topic=4905.msg49885#msg49885) than those blue bars...)
- Moved 16 units down the light entities inside the scaffolding -in both ground floor and middle foor- (also slightly lowered the light value of two of them to compensate). The reason is just that I can guess it's more useful to illuminate the ground than the ceiling. This is just a minor change, that does not really fix the non-optimal lighting of that part of the map. But I had some fear making bigger changes at this moment.

Note: files in the package still use "udestruction" name: they have to be renamed to "oacmpdm10" for the release.

PS:
@Jan: in OACMPDM5, in your idea, the jumps from lateral platform to central platform should have been possible or not? (screenshot (http://openarena.ws/board/index.php?action=dlattach;topic=4905.0;attach=5116;image)). It looks like they are possible/easy with 125 fps physics, but not with 90 fps or "accurate" physics.

In OA original textures folder there is the "pulchr_simple" that have the blue and red color.
(and a lot of other colours)

Why don't you use them ? Textures like the one you have choose are to manage for prevent misalignement, by the way it's a minimal issue.

;)

I'm having difficulties updating the maps (none in the technical side, but RL is calling me -.-), but I'll do as much as I can.
For tomorrow's final release, many "fixed" maps may have to be kept aside of the pack, so it's possible I'll be using v3 versions.

Does anyone experienced pelya's ctf1 glitches too? Because I seem to have found the solution to those bugs, and it involves the use of the func_group entity.

Excuse me, what do you mean exactly?

By the way, I have no problem to postpone the V4 a few days, if you need some more.
I think for OACMPDM4 you may just keep the original version, if you still have to work too much on it. For DM9, instead, a "fixed" version would be appreciated (ar at the limit, what about its very original version, directly from Akom?).

Uhm... in theory I can guess I may have put a copy of them under baseq3 folder, to have them working in the editor. However, I also like those red and blue textures I used. And I suppose in this phase we should follow "don't fix what's not broken": I don't want to risk causing "damages" now. Maybe for the next map...  ;) However probably my next map will be a "micro-tourney" one, where red and blue textures would have little use.

And I've also realized why the maps I've compiled looked too dark...
I was using very low values for lights. -.-
I started using lights with values 150 and 75 and they gave a better lighting. I was using many lights with values of 60 and 30. -.-

Put one light with value 700 near a ceiling, and call it the sun ;) That's what I did, before finding out how to make light-emitting sky.

Neon_Knight, I don't know if you are going to release V4 today, or if you need some more days (I however propose a V4 beta2 before officially releasing V4). For me, there is no problem to wait for some more days.

However, I just quickly looked at all the pages of this "v3 re-released" thread, to give a look to which posts did contain infos about known issues. I suggest you to give a look to them, to check out what's done and what's missing. However, if you want to scroll the whole thread yourself, you can do it... it's just five pages, so it's a relatively fast operation!

Some posts which listed some problems (some of them have been fixed, some of them are packaging-related and I don't know):

(Since v3)
- http://openarena.ws/board/index.php?topic=4905.msg49847#msg49847 (of those mentioned here, maybe only the darkness problem still lasts?)
- http://openarena.ws/board/index.php?topic=4905.msg49862#msg49862
- http://openarena.ws/board/index.php?topic=4905.msg49885#msg49885

(Since V4 beta (http://openarena.ws/board/index.php?topic=4905.msg49920#msg49920))
- http://openarena.ws/board/index.php?topic=4905.msg49936#msg49936
- http://openarena.ws/board/index.php?topic=4905.msg49967#msg49967

(Since V4 beta fixpack (http://openarena.ws/board/index.php?topic=4905.msg49983#msg49983))
- http://openarena.ws/board/index.php?topic=4905.msg49985#msg49985
- http://openarena.ws/board/index.php?topic=4905.msg49986#msg49986 (and the one under it)
- http://openarena.ws/board/index.php?topic=4905.msg50007#msg50007

Extra:
- Fixed mappools: http://openarena.ws/board/index.php?topic=4905.msg49981#msg49981 (the post also mentions "item startsolid" problem with OACMPDM5)
- Under destruction version 19: http://openarena.ws/board/index.php?topic=4905.msg50026#msg50026

So far, the changes I've got registered are the following:

oacmpdm1:
- Keeping the v4-beta (not the fixpack) version, also adding Akom's suggested change to the cross area.

oacmpdm2:
- Keeping the v3 version but removing the fog.

oacmpdm3:
- Keeping the v3 version.

oacmpdm4:
- At this point I'll still keep the v3 version.

oacmpdm5:
- Changes regarding v3 version: fixings to the BSP hole area. Sparklies won't be fixed.
- Startsolid items.

oacmpdm6:
- I'll try to fix those bugs, but I won't guarantee anything.

oacmpdm7:
- I'll try to raise the lighting. Again, I won't guarantee anything. And still waiting if the people wants me to bring back the old placement or keep the new one.
- Add more items.

oacmpdm8:
- I'll keep the v3 version.

oacmpdm9:
- I'll add the new version with better lighting at the top and Akom's suggested change. (I'm going to clip that area)

oacmpdm10:
- v19 will enter.

oacmpctf1:
- Sparklies won't be fixed. The MG ammo will be added. Overlapping brushes will be fixed, though.
- Replace music so Gig won't complain as much.

oacmpctf2:
- The v3 version will be kept, with the extra of the botfix and quadfix.

oacmpctf3:
- Recompile with sky shaders.
- Redo the bottom pit.
- Redo the lighting at bases.

In general:
- "Yellow dots" won't be fixed.
- "Copying" without TXT won't be fixed.
- Readmes will be done for dm8 and ctf2.
- OACMP readme fixes.
- Mappools removed. Gig's mappools will be placed instead.
- OACMP mod message fix.

oacmpdm7: I would like at least some items in the center, it's too empty in v4-beta.
oacmpctf3: you can keep v3 version, it's okay, but I would prefer if you recompile it with Akom's sky shaders, because some parts of the map are pitch-dark.

Isn't there the Quad Damage in dm7? Or I just forgot to keep it in place?

Oh, about oacmpdm3 I thought to have that problem solved. Do the newer versions look and act the same as v3?

Well, there's only one quad, which does not respawn often, it's not a big issue anyway, so just do as you like.
I was talking about oacmpctf3 - oacmpdm3 is fine as it is.

Oh, that.
Yeah, dumb me who hasn't added those shaders in my shaderlist. -.-
I'll see what can I do.

This will take some extra days, so today there won't be a release. 2/2 will be the final release date.

What about those "startsolid" items? I don't know if they have already been fixed...

About item placement, I don't know what's better...

... and the fact it searches for the wrong music file?

Not sure, maybe the "quad"s were already fixed in v3? However the botfix is surely an important fix.

What do you mean? IIRC, the changes after V3 were just a change in the way the player dies when falling down (however also the original way to die was acceptable, unless the server did disable self damage, showing the corpse on the bottom). And IIRC, Akom mentioned (http://openarena.ws/board/index.php?topic=4905.100) he noticed some red and blue lights which emit white light, or something similar (but I don't know if that issue affects V3, V4 beta, or both)...

Are you referring to sparkles like those in DM5? If you are talking about those mysterious yellow dots in the upper left corner of levelshots, it seems to me that in "V4 beta" they (or at least, most of them) were fixed. I can guess updating levelshots should not be a very time-consuming operation.... maybe it's me I don't get which "yellow dots" you are talking about?

Uh? Why?  :-\
Good.  :) Thank you!

A small note about me: on 01/02 and 02/02 I think I will not be able to test anything, due to Real Life. Sorry.
In any case, I really suggest a V4 beta2 before the real V4. Really.

Maybe Pelya means on the floor around the hatch. Before, there were too many items. In your test version, there are zero, IIRC... what about something in the middle?

No more delays. Sorry. We should have moved on to OACMP2 and other things on January 15th. We're still dealing with this Vol1. I hate this. So no. This time, only bugfixes. February 7th will mark a year after the first beta was released! This is insane.

So no. For a third and last time. NO MORE BETAS.

And before anyone else says this, yes, it's (partially) my fault. But well...

I suppose they were already solved.

I'm very tempted to keep my placement. But if enough people says so, I may revert it.

OK, that will be fixed as well. -.-

I thought they were fixed.

Oh, that. The ? ? ? was because I didn't knew which things needed to be fixed. The lighting in that area might need to be lowered.

The levelshot dots. It's not really a big deal.

I find it unnecessary. It's still a text file.

If you don't want another beta, then be sure you will check all the maps, after having compiled (and packaged) them.
Especially those particularily undefined such as DM7 and DM9.

However...
Uhm... I just checked with V4beta+fixpack and the game reports them.

Maybe you may keep your placement, just adding a few items around the hatch?

Uhm... we have no idea about how Akom's maps lighting looks like now that you compiled them with the right shaderlist. In V3 they were quite dark... now we don't know.

I don't know what caused it in the previous release. However, in V4 beta, none of them had that problem....

Decide yourself. Adding .txt extension allows windows users to open text files also if they are PC noobs (opening files without exension is a sort of problem on Windows), and I don't know about bad side effects of this. However, I suppose PC noobs may be not so interested into the full license text.

I can raise the lighting from 60 to 100 or 125. Though in some maps this will break the ambience, but since in OA visibility is important, that should be sacrificed, I suppose...

Remember also that in multiplayer game i want to see my opponent and not come a rocket from the dark  :D :D

;)

About oacmp mod, did I say that in previous versions its description.txt (despite not mentioning Volume 1) was too long and thus the name was cut in the mods menu?

And that it should be mentioned somewhere that mod is designed for 0.8.8?

I remember these things from V1 v1.

Gig from cell phone.

I forgot to say that for dm6, if it has got only minor glitches and Neon Knight never compiled it before, maybe it would be safer to just keep the original version? Just a thought...

I hate delays, especially when we should have moved on to other things more than two weeks ago, but... *sigh* it's necessary. 2/2 I'll be releasing a beta 2 of v4. 7/2 the final release.

I'm rolling back all the weapon/item changes to v3, except the bugfixes. Items in "startsolid" will be deleted if they won't spawn in-game.

Hi guys.

I was playing with oacmp1 version3 on the Android edition, and I noticed a strange thing in OACMPDM4: when entering a teleporter, I exit next to the other teleporter, but FACING IT, instead of facing the back of the ship. This is strange. Now I can't check if that happens on PC, too... If in the meanwhile you may take a look...

Another thing (smaller), in OACMPDM5: the rocket launcher on top of the middle platform maybe may be moved a few units, to be better centered on the platform. Unlike the one above, I don't think this one is Android-related only.

Gig from cell phone.

It's Android thing, with incorrect teleporter camera angle, it will be fixed in the next release.

Oh, yeah, I owed an update.
I'm still trying to solve oacmpdm5's BSP hole problem. I'm remaking the problematic area and cleaning it up, though it's a pretty irregular area. Hopefully there won't be glitches.

I'm still waiting the word if people wants me to bring back the old placement or keep the new one on oacmpdm7.

Keep rhe new one, but please add al least some items to the center, few +5 health would be fine.

If Moixie does not tell his own opinion, I can agree with Pelya.

Attached, a texture misaligment I just noticed in DM7 (I think it's version4beta-fixpack version).

Very good news!
The BSP hole in oacmpdm5 has been solved!
Once I take care of a lightmap glitch, I'll call it a day and upload beta 2.

Yay! It will be named OACMPv1ver4beta2, v1.4.2 for short.

Hmmm... no. That's 1.3.7, 1.4 will be the final version. After that one, no newer versions will be released at all.

Here are oacmpdm1 and oacmpdm5 fixed. I'll attach the rest as I fix them.

Two known glitches, though. I consider them minor, anyway. At least, compared to the BSP holedm5 was suffering.
- dm1: the beams.
- dm5: that shadow. -.-

BTW, how's the new lighting on dm1? I've raised it, though the ambience was screwed. -.-

DM1: Now it is lighter (was it too dark before?), and light colors seem to have something different (maybe now is even too bright for a crypt?)... There is the problem with the new light beams (were they necessary?). The "clipped" cross seems to work correctly. Why did you modify the "Akom74" tomb? Weren't us in bugfixing-only phase?

DM5: That "hole" bug seems to have gone.  :) But various bevels continue to do not get "marks on walls" (see second screenshot), and I don't know why. Also, the rocket launcher is still uncentered (third screenshot, although this one is not really important).

Oh, I knew I forgot something. -.-
I've made it model, but I forgot to place the model in the map. -.-

ctf1 is giving me headaches. -.- Now I'm experiencing pelya's mentioned glitches.

While I fix this, here are the modified dm1 (no beams, lowered lighting, coffins back), dm2 (without fog), dm5 (hopefully, definitive version, sparklies won't be fixed) and dm7 (v3+new lighting+new placement+extras in the middle area).

http://www.onykage.com/files/armageddonman/!oacmp/zz_oacmpdm1257.pk3 (http://www.onykage.com/files/armageddonman/!oacmp/zz_oacmpdm1257.pk3)

The v3 versions of dm3, dm4, dm6 and dm8 will be kept.

dm10 will be udv19.

The only ones remaining are dm9, ctf1 (everything sans those two glitches) ctf2 (v3+botfix+quadfix) and ctf3.

Sorry, I only had the time for extremely quick try for today.

- DM1: seems good at a first look. Did you also remove those light beams which actually worked? However, I can guess that's not a real problem, considering they also at that small glitch...

- DM2: seems good... Is that black background on that jump-pad on purpose? (first screenshot)

- DM5: What are the differences from the version from yesterday (http://openarena.ws/board/index.php?topic=4905.msg50124#msg50124)? Bevels continue to do not get "marks on walls", and the rocket launcher is not centered. However, those are just minor details which do not really matter...

- DM7: Lamps seem to be more similar to "classic" version, right? And you moved quad higher to induce human players to use the hard path, right? Lower part (looking from downside) is still dark, but the main problem is that item placement has got something strange: there are some places marked as "weapon spawn area" where nothing seems to spawn (second screenshot). And some weapons have minor items next to them, while others not (in this map, one would have expected symmetrical item positioning -although with different items-).

I hope Pelya may do better testing.
I have to run, now.
Bye guys!

dm2: No, that wasn't on purpose. I don't know why I haven't seen it yet...

dm5: "Marks on walls" won't be fixed. It's a limitation of the engine. It's not really that important.
Also, I thought the RL was centered...

dm7: Oh, yeah, damn me. -.- I forgot to move that.

Pretty sure polygonoffset in the shader could fix that mark problem...

Uh? IIRC, in the original versions from Jan, those were working correctly. Did you change something like making them "mapobject", maybe? However, I agree that's not important.
See attached screenshot. I see it on the left, and not in the middle of the platform. However, that's not a real issue.

No, I haven't turned it into a mapobject at all. I've just reworked the entire platform so it doesn't generate the BSP hole it was showing. Though turning it into a mapobject would have been a good idea...

I've made some more testing (still hoping someone else will do)...
I used team deathmatch mode and ordered a bot to follow me, to see if I noticed bot navigation problems that way.

Dividing into more posts due to the four-screenshots limit...

OACMPDM1:
- It looks like (two?) torches near to the portable medkit are not touching the wall (Strange, I thought that was fixed before).
- The ground around the "Akom74" tomb is strangely black (first screenshot)
- The recess on the left of that one (not visible in the screenshot) now does not have a coffin anymore... but the "weaponclip" invisible-but-solid brush is still there!

OACMPDM3:
- The place of the second screenshot (where the wall brush touches the bevel) has got "small white dots" problems, although they are not shown in the screenshot itself. I suppose that will be "won't fix" (it's a minor issue), however I notify it.

OACMPDM4:
- IIRC, there are "bot do not enter" brushes which close the "doors" which bring to the Invulnerability platform. However bots may get to that platform by jumping down from the upper floor. And then? Look at the third screenshot, the bot gets stuck there (to get away from there without passing though "botdonotenter", the only alternative is suicide)... As I told something like a year ago, maybe placing "donotenter" as borders of the "boardwork" may have been better than placing it on those doors?

OACMPDM6:
- Black line appearing at bevel border (on the right of the fourth screenshot), similar to "white dots" problems maybe.
(DM6 continues on next post)

(continues from previous post)

OACMPDM6 (continues)
- This megahealth (first screenshot) is shown partially in the ground. I don't consider it a real issue, but I point it out.

OACMPDM8
- Second screenshot: it looks like the bot is not able to get to the upper floor using that bouncepad? It repeatedly jumps but falls back to the ground...
- Maybe botclip in the area of the third and fourth screenshots may be more accurate? I can understand botclip helps bot navigating there, but maybe in the last screenshot it's a bittle too much floating in the air? Not sure if this is worth anything (may cause further problems?), but I point it out anyway...

You know what? I want to be done with this. I have already took a stance about what will be fixed and what won't.

Little glitches ("white/yellow dots" a.k.a. "sparklies") won't be fixed.
BIG bugs/glitches (BSP holes and items not appearing, for example) will be fixed.

I don't want to spend any more time on this pack. I can't believe we're still dealing with this.

Also, don't expect testing from people who hasn't appeared when we really requested them. They are only going to give it AFTER the release. In fact, I bet that someone who hasn't appeared at all in this year and a quarter will come only to complain about the pack after v4 was released. They always do that.

I'm not telling everything has to be fixed. I point them out, you decide.
Those glitches that are there since a long time, probably are not so important (otherwise they would have been noticed before). Although I expressed some dubt about a few bot-related things something like a year ago.

But I think problems caused by latest changes (from those mentioned in my two posts above, those about dm1) should be fixed.

PS: Also I wish to see V4 out. :)

Botclip is solid for BOTs, the player and the bullets go in and out this brush, but for BOTs is walkable.

For DM4, it's not completely true, if in the map there is only one BOT, he remain at the invulnerability and don't move (but non all BOTs, and not always), in a deathmatch with other BOTs, as spectator i can see that the 90% of the suicides are for bad jumping or shooted by another BOT, in normal walking BOTs go -> take the items -> and go on.

;)

Who said botclip? About dm4, I mentioned botdonotenter...

However I can guess that's not a so common problem by the fact I haven't noticed bots "standing still" there during normal deathmatches. But I haven't spent too much time spectating at that place: when playing I see that spot only occasionally.

In the test I did, I was roaming the map with a teammate bot which I ordered to follow me. Sarge followed me there (he jumped from the upper floor), but then did not follow me when I left the boardword. No other bots in the arena.

Gig from cell phone.

Update: spectated some minutes a ffa with various bots. They go there rarely enough. When they do, sometimes die in the void, sometimes take the door and continue fighting. I can guess the rate is acceptable... I'm not sure if the default bots of that map is one of those who better play it (during those minutes of testing, Kyonshi was the bot with better scoring, but I don't remember if I ever seen her on the boardwork...).

Ps: Android port comes useful also for spare time testing. Nice! :D Of course, having it including a non-definitive package is an anomaly, but...

Sorry, i was meaning OACMPDM8 for BotClip.  :P

 ;)

Then, I know what botclip is. And I can also guess the reason why it's there (bots do not like round structures too much, they do prefer simple, axial brushes). Simply, I said that maybe it may have been placed a bit more accurately there, to limit the "flying bot" effect a little. However, that's not a real issue.  :)

PS: I checked in the editor, and "botdonotenter" is just named "donotenter".  :)

NK, how's going with the last problems? (dm1, ctf1, idontrememberwhatelse apart from dm2 jumppads with black background and dm7 misplaced items)

In this case I should include the v3 versions, whether they have bugs or not.

Uh? Those issues with dm1 should be very easy for you to fix.

For the rest, you did a lot of work in these weeks, why should you discard it?


(Note: I'm not sure you correctly interpreted what I meant with the previous post. I was talking about the bugs introduced in dm1 with the changes of the last two days).

Oh, only dm1, isn't it?

About dm1, I was saying it's almost perfect... just please fix those few problems (torches again not touching the wall, etc... see previous posts).

For the other maps, I can remember dm9 was too dark (was compiled without sky shader), latest dm7 version had some items misplaced, latest ctf1 had major glitches (fixing them would be better... in case it's not possible, rolling back to v3 may be an option -but careful with those texture folder in that case). Latest dm5 was ok, maybe (the rocket launcher not perfectly centered isn't a real issue)?
I cannot do a better recap now... I got a bit "lost" in post-v3 changes and I'm writing from phone.

I hope someone else may do a better recap of the situation.

v4 will be published at the end of the month. There's just too much work to be done.

(GDMITTTTTTTTTTTTTTTTTTTTTTTT!!!)

Any news about Volume 1 release ?

 ;)

It will be released when it's done. It will be called "OACMP1 Forever". (?)

In all seriousness, I have told that February wouldn't leave me with the time I had in January. March won't be different in that regard, if worse. Also, nothing ensures me that Gig won't complain and request another beta after I release this beta, and honestly, for a pack whom which we should have moved on from a month and a half ago, this is demotivating.

Do you need some help ?

If you want i can modify the maps and leave to you only the compiling process.
Tell me.

;)

Hi all!

Searching for a way to better illuminate my new oacmp volume 2 map (this time, I'm working with GTK/NetRadint), I found this page:
http://q3map2.robotrenegade.com/docs/shader_manual/light-emitting-shaders.html
Maybe switching from q3map_sun and q3map_surfacelight to (q3map2-specific) q3map_sunext and q3map_skylight may help better illuminating some maps?

http://q3map2.robotrenegade.com/docs/shader_manual/

Just did a Github repo for the OACMP1, complete with a pk3 generator. It's updated to the latest fixpacks.

https://github.com/NeonKnightOA/oacmpvol1

I'll restart development in this, finish it ASAIC, and then move on to restarting OACMP2.