MoonDog

It's a deprecated shader preview utility, that is supremely out of date.

No problem! I wouldn't mind seeing a shot or two of your results. I've never used lightFilter, curious to see how it turns out.

Much like a shadow casting grate, you'll need a lightsource behind the material pointing in the desired direction. Is your source material setup properly for transparency? I imagine it'd have to be for lightFilter. I've never used lightFilter tbh.

surfaceparm lightfilter Causes the Q3Map2 light stage to use the texture's RGB and alpha channels to generate colored alpha shadows in the lightmap. For example, this can be used to create the colored light effect cast by stained glass windows. This can be used with surfaceparm alphashadow.

I prefer to use categorized dynamic Icarus scripts for my doors( Ex: double_doors.ibi, single_door.ibi, double_rotating_doors.ibi, single_rotating_door.ibi, etc... ). That way I can have a huge amount of different types of doors, and adjust lines in a script accordingly. To me, it's easier to setup entities to properly use dynamic scripts, and then just change the one script, rather than changing KVP's on large amounts of entities.

I didn't mean to say it was caused by OpenJK. I remember asking when someone told me that certain Icarus functions were made to work in MP in OpenJK if the problems were fixed, and they erroneously told me they were fixed in OpenJK. Thanks for the info. I'll pass it along.

I'm sorry, you said it wasn't an OS specific issue. I thought you might have meant there were issues setting timescale via Icarus in Windows that I was not aware of because they are not immediately apparent. I'm brain washed.

I don't know if I have time to put together a sample. There is an area in my FFA3 mod with a navgoal scripted AI. This would be inconvenient for debugging due to the size/load times. Correct. I don't want to stop offering support for my mods, but it's starting to get to the point where I am considering it. I'm told the mod is regular JA+, on Linux. AFAIK, the last time I attempted to utilize the the AI movement on Openjk + ja+(not ja++), it was not working as intended. Are there some sort of hidden issues on the Windows Ded? The only time the Icarus/manually setting the dvar has worked for me has been on a Windows machine.

To be clear, I'm not "doing" anything. I'm just tired of getting emails about my mod not working on linux servers, referring people to OpenJK, and getting emails back that the problem is not fixed.

In interest of reducing the amount of emails coming at me about my FFA3 mod, I will ask for what seems to be the 4th time. When will OpenJK fix the following two issues with the dedicated server on LINUX. NPC's don't follow scripted navgoals. They glitch about in circlesSetting the timescale either through direct commands, or through Icarus does not work on Linux servers I've opened reports for both of these issues on Github previously, but as I remember it was laughed off. Rudely.

Not to be rude, but this topic is covered quite well in the plugin documentation.

http://www.blendswap.com/blends/view/18777 or http://www.blendswap.com/blends/view/4405 Make sure you read the licenses. Some Blends don't require credit to the author, but it's always best practice to do so out of good faith.

I'll have Mozzarella sticks for starters.

JKA != Half-Life

I looked at this a while ago. The scripting required actually wouldn't be too advanced. The thing that deterred me from even attempting this would be the massive amount of entity work. You'd need to gut a lot of stuff out, and you'd need to do it for all the BSP's. Then you'd have to redistribute all of the BSP's, and provide instructions on how to setup the proper rotation vstrs on a server, as well as how to setup the scorelimit. Then there would be a lot of relying on people not to be dicks and intentionally break shit. Too much work. ><

lil_binger said he loves criticism and feedback, so here you go! Visibility: Level needs visibility optimization. Either with better structural brush layout, or hint brushing. Both preferably. lockpvs and showtris indicated that performance could be a good deal better throughout most of the level. *Side note*: Brushwork needs a good bit of treatment in terms of edge mitre to reduce tris counts. Also, there are a good deal of unnecessary surface splits from small brushes lying coplanar with larger brush planes. In the long run, this will cost performance. Examples: Lighting: There are quite a few incidents in the level where there is light, but no light source to provide the light. Where is this light coming from? Light entities need accompanying geo/models. *Side note*: Where some areas DO have logical light sources, the light generated is not consistent with the light source. Meaning, the amount of light generated is disproportionate to the size of the light source. Also, light colors do not seem to always match the color indicated by the light source. Examples: Theme/Texturing/Geo: The theme is relatively inconsistent throughout the level, which isn't necessarily a bad thing, however the "Bespin" theme and tones in the map look like a frankenstein of Bespin/Cloud city community made maps, or the JKO map. The textures, generally, match the colors and themes of Bespin. This are base textures however, so I guess Raven did a good job there. However, if we look at reference of Bespin, either through art or other games, we find the shapes and geo to be quite different. Surfaces in Bespin generally have a very curved quality. Not harsh edges, hexigon/octogon shapes. Examples from reference image search: In terms of texture application, I'd say this level needs a really good pass on alignment and stretching. Some of the patch surfaces have stretched textures, or textures that are misaligned. Some of the brush surfaces need an alignment pass as well, to bring up the quality of the aesthetics. Layout: Numerous layout issues for gameplay types. Inconsistent ramp angles and heights is a problem that needs to be addressed. As well as scale for the geo. Many things do not seem to have been thought out in terms of good scale. Additionally, the current geo needs a very thorough clipping pass. There are a huge amount of hangups in the level to get caught on. In regards to the layout: The layout is largely unconducive for varied CTF play. Many of the spaces share the same characteristics in terms of space and height variation. This does not support a large amount of player preference. Also, the layout is not optimized. It's sort of baffling unless you sit there and attempt to memorize the map for a large period of time. A good layout should teach the players within the first 5 minutes. There are too many confusing twists and turns that don't seem to have a great deal of thought towards gameplay. Conclusion: Reads more like a blockout that needs to go through more stages of iteration for the layout. Work with reference at hand. Reference images for lighting, for geometry, and overall texturing. Look at other levels, both included samples and well made community maps to get a handle on scale. Work more towards accommodating various styles of prefered gameplay if you are going to claim to support CTF on the map. Gameplay, gameplay, gameplay. Everything else(lighting, art, etc...) should be built AROUND the gameplay. "Move your rifle around your head, not your head around your rifle."

Check your messages.

Well, it's definitely an error defined in light trace. I think you've got some complex objects that need to be split up into multiple brushes/meshes

Do you have brushes that you've clipped a lot of faces onto?

You could sort of cheese it with some Icarus scripting, heavy and numerous entity mods, and a scorelimit set for an Icarus loop.

You are very sensitive, and seem to be reacting based on a misconception. I was speaking in generalities to voice an opinion about design. I have not looked at any WIP threads here as of late, because mostly people like you going on tirades, such as you just did, when receiving actual criticism or an opinion counter to their own. I'm not sure what part of anything I said you misunderstood as any sort of personal attack at your work, but I have not even looked at it. Nor would I, given your little outburst. It discourages me from believing you'd be capable of holding any sort of meaningful discussion regarding design if I gave you real criticism. Unprofessional, counter-productive.

You can alter the dynamic glow part of the shader as freely as you like, testing different images, blends and values to your hearts content without recompiling. The surfacelight, however will require a recompile. They are baked directly into the lightmap, and therefor need to be recreated to see the results of an adjustment on that argument. JKA doesn't have any sort of true primary dynamic lighting.

I doubt you have anything to worry about. That is a small handful of entities. I entity modded the plugin version of my FFA3 mod up to nearly 1,000 entities safely. I left a small cushion for projectiles and other gameplay entities, and never had any issues. As for the other things you said, part of the reason I hate community made maps that "support ctf", is because the person who designed it thought CTF would work as an afterthought as long as the flags are placed linearly in fashion; with supporting logical spawns. It's simply not the case, and is a good deal more complicated than that.

info_player_start functions in MP as well, and can be used. A teamdeathmatch spawn will handle both tffa and ffa