Quake3World

The MOD's getting along pretty well, if only I had had time to take part in the test and suggest phase during the last 17 pages of this wonderful thread. Nevertheless: Definitely a MOD

ad notbot issue: I believe that in an old map of mine I managed to get that thing working? Whatever, how about experimenting a bit with the botdonotenter clip to seal off specific areas? Would this help in any way?

monaster wrote:The MOD's getting along pretty well, if only I had had time to take part in the test and suggest phase during the last 17 pages of this wonderful thread. Nevertheless: Definitely a MOD

If you have any suggestions, feel free to let me know. I might actually get to implementing some of them, who knows. In my experience though, the most changes come from hands-on experience with mapping now. Most of those entities and keys that have been added in 1.1 are there because I needed them for my own map

So it's still open for suggestions? Good to hear! If I stumble upon any urgently needed implementations I'll let you know for sure.

It's always open for suggestions

I see that you updated to 1.1.1 so I updated the 1.1.0 link in your post above.

ah ok ty

It's mostly working out alright, mostly.



I had a hell of a time unwrapping that model and getting 3ds Max to render out the lightmap. Something strange was happening to the UV's on the green cube, so I trashed it and remapped it. FML.

heh, it's looking pretty good though

@obsidian: Is that going to be an official MOD menu background or is it more of a personal project of yours?

Both. It's something obsidian made to test lighting compile stuff (correct me if I'm wrong obs) but he kind of donated it to become the background for the mod's main menu. He also made the logo model. The current release of the mod includes a version of the model that's kind of alpha so he's working on improving it and getting himself some good headaches in the process

Obs would actually release something map-related? Then get the man some aspirine!

tehSandwich wrote:I cannot go pass the open door after the fight against Anarki.

This is a strange issue indeed, and I've done some testing now and found the reason why I missed this issue when testing my map. When I test my map, I was using a shortcut. The shortcut runs quake.exe directly with some parameters, such as: sv_pure 0, g_gametype 8, devmap, etc.

But the parameters don't matter with regard to this issue.

I did some more testing, and I found out that the cause is when you load my map using the EntityPlus menu system--where you select your Skill Level as well--and click Okay.

So, it appears the solution would be that you simply goto console, and type "/map krep1" to load it directly. Make sure that Quake3+EntityPlus is loaded properly, and that sv_pure is 0, and g_gametype is 8 before using "/map krep1" command.

Eraser wrote:Looks like there's some clip bru... ... For some reason though, there is a "nobots" key on that invisible door. ... ...

I added "nobots" because I assumed bots would trigger doors--even though it was not shown in the entity defs--I added it anyways. : )
I added it because I saw the bot trying to go out there, and so I figured I'd add "nobots"--thinking it wouldn't hurt anything if I added it. hehe

This key was introduced in v1.1 and prevents bots from opening the door, so now suddenly the invisible door refuses to open.

I'm not so sure though if the issue is my map--or more specifically the unnecessary "nobots" property, which I assume could be ignored by the mod's programming.

I loaded my .map in GTKRadiant again today and reviewed my entities, targets, and targetnames; and everything looks correct.

Any door with targetname can only be activated by a target--which now I realize that means I don't need a "nobots" anyways, but yeah--and that targetname is set to the same value as the deathtarget from the bot. Everything looks good in my map. So, maybe we can do something with the mod? What do you think, Eraser.

This key was introduced in v1.1 and prevents bots from opening the door, so now suddenly the invisible door refuses to open.?

hmm. interesting.

Deqer, what are you on about? The issue has been identified and a fix specifically for your map was introduced in version 1.1.1 of the mod.

Yeah, I updated/tested with 1.1.1 and the issue still happens if you run the map from the EP menu.

EntityPlus 1.1.2 released

I've updated EntityPlus to version 1.1.2. This version fixes some problems with scoring where the game reports the wrong number of secrets and the wrong accuracy. Sounds familiar? Yeah I thought I fixed that in 1.0.2, but apparently the problem still occurred when running the game as QVM. During development I compile to DLL and then the problem didn't occur. Really strange.

But this release should fix it for both QVM and DLL. I suggest everyone replay their maps again because you're bound to get a higher score this time around

Oh, it also sneakily introduces a "wait" key for info_waypoint entities.

There is a problem: When player restarts game (the map), he have only machinegun. I've registered it in Testing Procedures campaign. I had only Machinegun in final battle with the AI computer. Is it possible to make any buffer for inventory at start of map? If so, then player will have all items which entered the map, when restart game.

Could we get a new grenade launcher spawnflag to create teleporting grenades like as (somewhat) discussed in this thread viewtopic.php?f=16&t=46340 ? (the spawnflag would specify that the GL would only shoot teleporting grenades)
This could introduce some cool new puzzle-solving scenarios for mappers to challenge players with.

Is there some way in your mod to deactivate some kind of shader after 3 seconds? Let's say a monitor starts a movie and afterwards it should turn itself off and can't be turned on again? Or is it already possible in q3a?

Yeah it works but I've never got it to work reliably myself. Shaders do swap but afterwards, there is often some weird graphical artifact, like weird colors on the new shader. Not sure what causes it, as the technique is used correctly in Team Arena.

-seems to work for me

Bliccer wrote:Is there some way in your mod to deactivate some kind of shader after 3 seconds? Let's say a monitor starts a movie and afterwards it should turn itself off and can't be turned on again? Or is it already possible in q3a?

This is indeed possible in vanilla Q3 but you will have to make sure you got the latest patch (1.32b) release. Most of the effects I did in my Forever map used the TA shader swapping feature. I also released the source files of the map if you want examples (http://www.simonoc.com/pages/design/map ... source.htm) Remember to use editor filters and camera clipping so you can move around the source map easily.

Eraser wrote:Yeah it works but I've never got it to work reliably myself. Shaders do swap but afterwards, there is often some weird graphical artifact, like weird colors on the new shader.

The shader swap function does not work correctly with lightmap stages and causing fullbright and/or visual corruptions. Split the light stage into a different shader so the swapping only affects the texture stage and layer them on top of each in the editor. I had this problem with my forever map and solved it by splitting the shaders. Also the shader swap feature does not reset back to original state when the player dies or respawns which could cause problems with visual clues or progress in a SP environment.

LOL... sock. I was searching for our PM discussion about this problem for "Forever" and you beat me to it.

Perhaps the player spawn could trigger a relay which resets the original shader state might work to solve the respawn problem?

obsidian wrote:I was searching for our PM discussion about this problem for "Forever" and you beat me to it. Perhaps the player spawn could trigger a relay which resets the original shader state might work to solve the respawn problem?

The problem with resetting shaders at the beginning of a map reload is that you can cause the client command line to over run and crash the game. (1024 chars is the limit) The TA shader swap feature always seemed like an engine hack to me and not something that can be done on a larger scale. Ideally there should be a new feature created for this, maybe Eraser could code something better?

Here is my PM about shader swapping, if anyone is interested ...

My story so far ...

Solution 1: Originally I used a pair of func_door/buttons to switch shaders around. This was easy to implement and it worked a treat, but Q3 has a 255 hard limit on func items and it is extremely easy to hit this limit if you have multiple brushes for each shader swap. Both brushes have to be in the same position and one has to be moved on start (func_door-start open function) in order to get the lightmaps looking right. The func_ items were moved with -1 speed (instant move) and had the added bonus of additional sound attached to the func_ commands. I originally thought the -1 speed thing was instant but it is not, on one rare occasion I was standing on top of a func_ item and it pushed me upwards as it travelled 'instantly' to its new position. Not really an ideal solution as I was pushed out of the map into the void.

Solution 2: Setup multiple brush surfaces with different shaders and used the remap command via various trigger relay/delay entities. The off shaders were triggered on start of the map to be empty so the 'on' shader was visible. Getting a nodraw texture past the compiler was tricky at first but eventually I settled on the following shader:
The trans was needed because the on/off shaders were on top of each and the compiler would randomly remove one. (it usually depended on which one was found first in the map file)

This solution heavily relied on the 'off' shader being setup at the beginning of the map correctly and I soon found a couple of new Q3 hard limits. When the remap command is run, it is instantly run, no delay and several at once will cause the client command line to over run and crash the game. (1024 chars is the limit) Each setup trigger had to be batched and delayed so they did not all happen all at once. The second limit was a maximum of 128 remap shader commands per map and with duplicates for each trigger this can be reached very easily as well.

The final problem is when the remap command is used, the engine assumes the shader assets used in the target shader are cached/loaded into memory and if not will cause huge fps drops (20-40) while it is loaded. The target shaders have to exist somewhere in the map before the remap command is used, so a small gallery box with a target shader is required.

Other compilications come from the shaders and the best results are when the source/target shaders share similiar/same amount of stages. Going from a 1/2 stage shader to a 4/5 stage shader will again cause huge FPS drops. Going down in stage numbers is fine but huge leaps upwards in stages can be serious. I found the best number of stages to use was 3 (lightmap+source+blend). Some of the more compilicated shaders I was testing with had multiple stages of tcmod commands which again 'seemed' to cause fps slowdowns. Eventually I tried to keep all tcmod stages to a bare minimum and not make the target shader too complex.

Solution 3: Based on solution 2 but removing all the startup remap triggers and using only one shader surface instead of two. The start up of the map was getting to be a huge problem with timing co-ordination and it was easier to just setup the source shaders in the shader file first. This solution involved re-working all the shader file but it did mean the map did not have any startup lag issues.

Unfortunately this solution still had one big problem, lightmaps. When the remap command is used the lightmap on the source shader is broken and will often randomly be full bright, black or a different colour shade to existing surfaces around it. I tried various shader tricks to fix the problem (tcgen lightmap, stylemarker and lightmapscale) but nothing worked 100% all of the time. If anything the various extra shader options just made the problem worse and even more random on which remap surfaces would be broken next compile.

Solution 4: Split the remap shader into two parts. The section to be remapped from the original shader was split into a separate part while the background + lightmap stayed static. Again the shader file had to be re-worked to fit with the new layout but it worked perfectly. The target shaders were cached via the gallery box, the remap shader were single staged so no weird engine redraw lag and best of all, the lightmaps were perfect across all surfaces being remapped.

Example shaders: The stuff that needed to be switched on/off was in a seperate shader and using the previous nodraw shader (above) it was simple to use. Each instance where the shader was required, two patches were created. One had the background shader + lightmap and the second one had the remap shader which was switched on or off depending on remap state. Patches were used because the texture co-ordinates need to align up perfectly and brushes at weird angles do not always work correctly.

Final solution involved no extra func_ entities, two patches (background and remap surface), various trigger relay's to activate the remap commands and the target shaders cached in a gallery box. The remap shaders were all single stage and this was good news for the engine fps.

I have literally spent weeks on this trying to find the best solution and I think I have found a good one but I imagine the best solution will probably come from ydnar as he knows what the compiler is doing to the remap shader surfaces. (unfortunately he has left the Q3 scene so it is impossible to get his input anymore)

(please ignore my last post.)