[REL] OpenArena Community Mappack - Volume 1 - FINAL

[Akom74]

@Gig: in Q3A a map with the fog is more heavy for the engine that a map without fog, i don't know in OA, but i think if you want to lighten up the map, you have to try to delete the curved wall (mountain?) at the border and place simply "caulked" polygons.

[Gig]

Uhm... Even if I would want to do it (I'm not sure about it), I really don't actually have chance to try a such thing before something like 20 days... Real life asks for me, and replacing all those rounded walls with an high number of vertical brushes (many, many sections... to avoid the original "box" feel of the map) is a thing I cannot try right now (just thinking to the time required for "dragging edges").

If fog is not an optimization, the only optimization I can try this week is the one for bots: trying what happens compiling map and .aas file with the two tools Neon_Knight linked. I've not been able to even take a look to them, yet. I don't even know if they are actually working on win32, considering that he stated he has not been able to compile something for win32...

By the way, also from q3radiant documentation it looks like fog does not work well with things like moving brushes/doors...

[Akom74]

Uhm... Even if I would want to do it (I'm not sure about it), I really don't actually have chance to try a such thing before something like 20 days... Real life asks for me, and replacing all those rounded walls with an high number of vertical brushes (many, many sections... to avoid the original "box" feel of the map) is a thing I cannot try right now (just thinking to the time required for "dragging edges").

If fog is not an optimization, the only optimization I can try this week is the one for bots: trying what happens compiling map and .aas file with the two tools Neon_Knight linked. I've not been able to even take a look to them, yet. I don't even know if they are actually working on win32, considering that he stated he has not been able to compile something for win32...

By the way, also from q3radiant documentation it looks like fog does not work well with things like moving brushes/doors...

Sure, real life and time (and compiling time) are the bigger problem in editing
Fog also work bad with curved polygons and water.

The system i can suggest is to divide the map and connect the pieces with teleporter (not portals).
.....or maybe you can caulk everything you can, but the map is very large and this is the big problem.

[Neon_Knight]

Or... we can just leave the map as it is (not even with fog) and advice that the map has some requirements for fluid play due to the sheer size. That's another option, as big maps, regarding both OA and Q3A are very rare.

[Gig]

@Jan:
A small glitch noticed with oajgdm2 map.
If I shoot a rocket just above this teleporter, I can see a part of the wall "flickering". It may be similar to when there are overlapping brushes... strange thing is that this happens only when it is illuminated by dynamic lights. Jan, could you please give a look also to this?

Thank you!

@All - Can we talk a little about the final naming scheme of the maps and of the complete package?
What Neon_Knight proposed is something like oacmpdm01, oacmpdm02, etc. But what's the reason for using TWO digits for the number?
If future OACMP volumes will continue the same naming counter (oacmpdm11, oacmpdm12, etc.) instead of using their own counters (oacmp2dm01, oacmp2dm02), I would suggest to use THREE digits counter (oacmpdm001, oacmpdm002), or maybe even better, the "trimmed" number of digits (oacmpdm1, oacmpdm2.... oacmpdm10, etc.), just like Q3A does.

For the OACMP pk3 file name, instead, I would suggest a two-digit number (e.g. oacmp01.pk3), because while talking about pk3s the loading order could be very important (think about the case of future need to fix previous oacmp maps/shaders), and a possible total of 99 OACMPs sounds better than just a possible total of 9 OACMPs.

What do you think?

PS: Noone answered yet to the question about the problem of the bots chosen in .arena files being actually used in some gametypes only... Fromhell? Sago?

[Akom74]

@All - Can we talk a little about the final naming scheme of the maps and of the complete package?
What Neon_Knight proposed is something like oacmpdm01, oacmpdm02, etc. But what's the reason for using TWO digits for the number?
If future OACMP volumes will continue the same naming counter (oacmpdm11, oacmpdm12, etc.) instead of using their own counters (oacmp2dm01, oacmp2dm02), I would suggest to use THREE digits counter (oacmpdm001, oacmpdm002), or maybe even better, the "trimmed" number of digits (oacmpdm1, oacmpdm2.... oacmpdm10, etc.), just like Q3A does.

For the OACMP pk3 file name, instead, I would suggest a two-digit number (e.g. oacmp01.pk3), because while talking about pk3s the loading order could be very important (think about the case of future need to fix previous oacmp maps/shaders), and a possible total of 99 OACMPs sounds better than just a possible total of 9 OACMPs.

What do you think?

I'm not completely agree with the rename of the packages, one-two-three digit or other stuff, but if for Neon_Knight it's better, i can't say nothing. By the way, the name of the maps don't have to change for me.

[Neon_Knight]

@Gig, another thing is to make future OACMP volumes to carry filenames such as oacmp2dm01 or ditch the "dm" and "ctf" and just use oacmp101, oacmp102, oacmp201, oacmp202, oacmp1001, oacmp1002, etc...

@Akom: the reason for this is that there's always the chance that serveradmins may use beta versions of the maps, and if we keep using the older names, there could be a confusion. OACMP official names will only be applied in the release version.

[Suicizer]

@Gig, another thing is to make future OACMP volumes to carry filenames such as oacmp2dm01 or ditch the "dm" and "ctf" and just use oacmp101, oacmp102, oacmp201, oacmp202, oacmp1001, oacmp1002, etc...

@Akom: the reason for this is that there's always the chance that serveradmins may use beta versions of the maps, and if we keep using the older names, there could be a confusion. OACMP official names will only be applied in the release version.

Then use version numbers behind the name of the map, as like oacmpdm01_v088

[Gig]

@Gig, another thing is to make future OACMP volumes to carry filenames such as oacmp2dm01 or ditch the "dm" and "ctf" and just use oacmp101, oacmp102, oacmp201, oacmp202, oacmp1001, oacmp1002, etc...

Excuse me, are those two further possibilities? The first one seems like one of those I already mentioned... the second one seems a bit too "confusing" maybe?

@Suicizer: but OACMP packs would (hopefully!) not be strictly related to a specific OA release...

[sago007]

Any idea about the reason why the bots specified in the .arena file are actually used only in some gametypes, and not in others?

Bots in the arena-files are limited to FFA-gametypes only. It has always been like that. Of course that could be changed in the future.

@Gig, another thing is to make future OACMP volumes to carry filenames such as oacmp2dm01 or ditch the "dm" and "ctf" and just use oacmp101, oacmp102, oacmp201, oacmp202, oacmp1001, oacmp1002, etc...

I would prefer if the name of the map was in the filename. Numbers can be hard to remember. An example could be "oacmp101_oajgdm2". That way auto completion will be more informative (write "oacmp1"+Tab for maps from the first community pack).

[Neon_Knight]

But we have the problem of filename length in Skirmish/Start server in the GUI, do we? Filenames should be as short and easy to memorize as possible.

[sago007]

Numbers are hard to remember.
I don't think the gui has that big of a problem with long names although they likely will not be visible.
Filenames should be related to the content.

I believe it was a mistake to give all maps generic filenames in Q3A. It is something from a time before auto completion and when DOS limited the length to 8.3.

It was just a suggestion based on my personal opinion.

[Neon_Knight]

I do remember having the long filename problem 5 years ago, with am_lavactfxl. The original name was am_lavaarenactfxl, and it didn't only fit, but the GUI showed am_lavaarenactf instead. I had to trim the name to am_lavactfxl because of this.

[Akom74]

@Gig, another thing is to make future OACMP volumes to carry filenames such as oacmp2dm01 or ditch the "dm" and "ctf" and just use oacmp101, oacmp102, oacmp201, oacmp202, oacmp1001, oacmp1002, etc...

@Akom: the reason for this is that there's always the chance that serveradmins may use beta versions of the maps, and if we keep using the older names, there could be a confusion. OACMP official names will only be applied in the release version.

Then use version numbers behind the name of the map, as like oacmpdm01_v088

@Neon_Knight: Do you mean that in the official release the name of the packages remain the original or the new ? 

@Suicizer: Are you kidding ? The name like oacmpdm01_v088 seems creepy to me.....

[Suicizer]

@Suicizer: but OACMP packs would (hopefully!) not be strictly related to a specific OA release...

Sorry, that probably wasn't the best example to take. I was actually just taking a "random" number. It could have been anything else instead.

I would use the original name of the map (didn't know that actually wasn't the original name) and just package it together. Else you could add author and date in the name also which ends up in a very_long_map_name_which_takes_damn_long_to_write_down.bsp

[Neon_Knight]

@Neon_Knight: Do you mean that in the official release the name of the packages remain the original or the new ? 

I do want to use an uniform filenaming pattern for the OACMP maps for the final release of the pack. It helps distinguish the beta maps from the released versions. There's always the chance that a server has a previous version of the map conflicting with the final version.

After all, there's a reason of why a lot of packs for a lot of games have this pattern.

But it should be short (no more than 15 characters long) and easy to memorize. Other possibilities I was thinking of are oacmp1-01, oacmp1-02, oacmp2-01, oacmp10-01...

[Gig]

What would be the problem with oacmpdm1, oacmpdm2... oacmpdm10 (and up to oacmpctf3) for this package and oacmp11, oacmpdm12, etc. (and starting from oacmpctf4) for the second package?

[Akom74]

What would be the problem with oacmpdm1, oacmpdm2... oacmpdm10 (and up to oacmpctf3) for this package and oacmp11, oacmpdm12, etc. (and starting from oacmpctf4) for the second package?

At this point, i agree with Gig.

But for the betas and OUR tests i think it's not a problem if we use normal names.

In the final release all the names will be changed and listed.

[Neon_Knight]

What would be the problem with oacmpdm1, oacmpdm2... oacmpdm10 (and up to oacmpctf3) for this package and oacmp11, oacmpdm12, etc. (and starting from oacmpctf4) for the second package?

At this point, i agree with Gig.

But for the betas and OUR tests i think it's not a problem if we use normal names.

In the final release all the names will be changed and listed.

Well, that's the point! That was the idea, what I've said all this time.

[Akom74]

What would be the problem with oacmpdm1, oacmpdm2... oacmpdm10 (and up to oacmpctf3) for this package and oacmp11, oacmpdm12, etc. (and starting from oacmpctf4) for the second package?

At this point, i agree with Gig.
But for the betas and OUR tests i think it's not a problem if we use normal names.
In the final release all the names will be changed and listed.

Well, that's the point! That was the idea, what I've said all this time.

Whoops  sorry 

[Gig]

Any idea about the reason why the bots specified in the .arena file are actually used only in some gametypes, and not in others?

Bots in the arena-files are limited to FFA-gametypes only. It has always been like that. Of course that could be changed in the future.

This is an interesting topic, I think we have to think about it. I moved my reply to the OAX thread, that sounds more appropriate for it --> http://openarena.ws/board/index.php?topic=1908.msg47950#msg47950

[Gig]

Neon_Knight, I've somehow managed to compile the map using q3map2build.
A thing I have not understood of q3map2build is how it loads shader files that are not in shaderlist.txt under baseoa. NetRadiant 1.5 + OA package (the one from this link) has got a default_shaderlist.txt file inside it, that I can guess is "added" to what I specify in my shaderlist.txt under baseoa. But how does q3map2build?

I've used q3map2build from your post some pages back + the .dll files from GTKRadiant 1.5 to compile the map, then I used BSPC.exe from GTKRadiant 1.6 to compile the .aas file.
Compiling went fine, map look well (I have to do more tests, but there is not the problem of your weapon illumination in the BFG room -see udestructionV9bis map-... "scaled up" textures than what I set are still there instead -however, this is not very important-), but it seems the short "stops" during actual gameplay due to bot logic are still there.

I really need some help. After tomorrow, I will not be able to work on the map for about two weeks.

[Neon_Knight]

Well, you have to edit the file. This is even true for Radiant.
I don't know which switches you use, but try the BSP stage with -meta and -patchmeta and the BSPC stage with -forcesidesvisible.

[Gig]

About shaderlist.txt, I've done this list that should include all shader files from stock 0.8.1 + 0.8.5 + 0.8.8 packages (for those of 0.8.1, I may have to check again, maybe I missed some "scripts" folder from some pk3 file. But I can't do it now!):

[list removed]

Considering their names, I have the impression some of them may not be relevant for mapping.

UPDATE: I've removed the list for now, I have to check it again (I may have missed some .shader files from secondary pk3s). I'll post it again later, after checking.

[Gig]

Two versions in one post!  

Under Destruction Beta Version 10 is available for download here:
http://digilander.iol.it/flagraiders/files/temporary/z_udestruction-version10.pk3
(Link may not be effective forever)

Changes against UDESTRUCTION V9 are not very much:
- Added a second grappling hook, near the bfg room. Now each hook spawns every 25 seconds.
- Added some item_botroam entities in the area of the red obelisk
- Made the holes in "hall of pillars" roof a little less "square"
- Gametype key fix for the "static" part of the button that opens the door (it did erroneously appear in Elimination and LMS modes before)
- The water (except the one that falls vertically) now emits a little less light than before (value changed from 40 to 35).
- A couple of small texture aligment fixes
- Slightly moved a rocket ammo box (the one of the top of the scaffolding), just a couple of meters.
- In readme file, mentioned that one may try to set cg_simpleitems 1 to achieve better performances.

UDESTRUCTION V10 is still complied in my "classic" way: direcly from Q3Radiant, and then the .aas compiled with original Q3R BSPC, with -grapplereach and -optimize options only.

Note1: only after packaging, I noticed a texture misaligment with two sections of the woody border out from the warehouse roof. I've already fixed it in Q3Radiant, but I don't have time for recompiling again. That will be in V11.

Note2: for the next version, maybe I may remove one or two bots from the .arena file (now there are something like 7 bots there)... but at least for the moment, they are all still here, to make more tests about the "hitches" caused by bot logic.
-------------------------------------

Attached to this post, you can find also UDESTRUCTIONv10bis.
It is compiled from the same exact .map file of udestruction V10. This package REQUIRES to have also "standard" Udestruction V10 pk3.
Usage: "/map udestruction10bis". It has also got its own .arena file.

The only change is that for this version I used Q3map2Build tool to compile (using q3map2.exe that comes from the Q3map2Build package Neon_Knight posted a few pages ago... It lacked .dll files, that I then copied from GTKRadiant 1.5 folder.) and an updated BSPC for compiling the .aas file (I took BSPC.exe from GTKRadiant 1.6).

Options used for BSP stage: -flares -meta -patchmeta -v -verboseentities (just those that were enabled by default in Q3map2Build... MAYBE SHOULD I HAVE DISABLED THE -FLARES OPTION? In my map illumination comes out from nothing, I don't want lens flare effect! However, flares seem to do not appear in-game, although I have the option active in Graphics menu... I maybe some extra key is required on light entities to tell them to act as flare generators?). For "vis" e "light" stages, I just used "Normal" option.
For bspc, I used -grapplereach -forcesidesvisible -optimize options. Bspc log still reports "1 portals created and 2 clusers created". I fear we may have not gained a lot of performace improvement, but I haven't yet had the time to extensively test this version.

As like when I compiled from NetRadiant, a few textures (like the tiles on the steps in the house) are scaled up than what I set... :-/ But at least, it has not the mysterious problem with your own weapon illumination while in bfg room, that had V09bis (that was compiled from NetRadiant).

PLEASE TEST BOTH VERSIONS... and tell me anything you may notice as "different" between the two versions. Of course, tell me if you find bugs. Bots behavior and game performances (especially when there are many bots) require as much testing as possible.
Thank you!

PS: I'm still waiting for Pelya's impressions about V9...