Didz

Do you want more control over how your weather behaves in your map, and bored of fx_rain, fx_snow, and fx_spacedust?

This tutorial details a little secret unintentional "feature" of fx_runner that allows you to expose non-default weather effects.

How does it work?

Fx_runners with fxFiles beginning with '*' are treated as weather commands. (Most of these work in SP and MP!)

Having acid rain for your multiplayer map is as easy as making an fx_runner anywhere on the map with the fxfile "*acidrain". It will rain acid upon your outside zones (or global if the map doesn't have zones) (Pain effects not included).

Here's the list of all possible values you can use for weather:

• *acidrain // Adds a layer of acidic rain to the world (doesn't have pain effect in MP!)
• *clear // Clears current weather effects
• *constantwind ( VelX VelY VelZ ) // Adds constant wind to the world with the given XYZ velocity
• *die // Restarts the weather system
• *fog // Adds a layer of medium fog to the world
• *freeze // Freezes the weather particles on-screen
• *gustingwind // Adds gusting wind to the world
• *heavyrain // Adds a layer of heavy rain to the world
• *heavyrainfog // Adds a layer of heavy fog to the world
• *light_fog // Adds a layer of light fog to the world
• *lightrain // Adds a layer of light rain to the world
• *outsidepain // Toggles pain effect on (No effect in MP)
• *outsideshake // Toggles camera shake on (No effect in MP)
• *rain // Adds a layer of medium rain to the world
• *sand // Adds a layer of sandy fog to the world (looks ugly!)
• *snow // Adds a layer of falling snow to the world
• *spacedust AMOUNT // Adds a layer of immobile "space dust" to the world, AMOUNT specifies how dense it is (1000+ is best. Add wind effects if you want it to move!)
• *wind // Adds generic wind to the world
• *windzone ( MinX MinY MinZ ) ( MaxX MaxY MaxZ ) ( VelX VelY VelZ ) // Defines a cuboid wind zone with the given XYZ velocity (Doesn't exist in MP!)
• *zone ( MinX MinY MinZ ) ( MaxX MaxY MaxZ ) // Defines a cuboid weather zone (doesn't really make sense without inside/outside zones already compiled into the map)

• Utility - These commands exist mostly for testing and utility purposes. It doesn't make sense to use these in fx_runner because they don't do anything noticable when the map is loaded.
• Layers - These commands add particle effects to the world, up to 5 weather "layers" can be used in a map
• Wind - These commands add wind effects, they will move weather "layers" around, and up to 10 wind effects can be used in a map

These commands can be tested in-game directly in the console when cheats are enabled. Example: /r_we heavyrainfog.

Here are some examples: (Each of the lines are different fx_runner entities in a map showing the value of the fxFile field)

• Typical Rainy Weather

  *rain
  *fog
  *constantwind ( 100 100 -100 )

• Floating Snow

  *constantwind ( 0 0 350 )
  *snow
  *light_fog

• Hydrochloric Acid

  *acidrain
  *acidrain
  *acidrain
  *acidrain
  *acidrain

• Typical Outside-Voyaging-Space-Station Weather

  *spacedust 10000
  *constantwind ( 500 0 0 )
  *light_fog

• Poopstorm

  *sand
  *gustingwind

- Didz

TODO: Screenshots of example entities in Radiant, and in-game result.

Have you tried it with jampded.exe instead of jamp.exe? I don't know if Makermod runs in jamp.exe by default because it has engine hooks built in that require the dedicated server exe instead (though I don't know if these are now automatically disabled when not running in the dedicated server).

I'm also going to join the unanimous disagreement here to say that this sounds like a solution looking for a problem. I don't think it's wise to have a launcher compiling code for the end-user as an excuse for the developer not to have tested their code on their target platforms. Compilation is always tricky, so spreading the requirement of compilation over multitudes of end users seems quite silly when you know that the package the developer builds will always be proper.

I believe it'll be the same packages and command line as for CentOS: https://github.com/JACoders/OpenJK/wiki/Compilation-guide#centos-7-for-dedicated-server-and-mp-libraries

$ sudo yum install libjpeg-devel libpng-devel zlib-devel

Or possibly it could be libjpeg-turbo-devel? https://www.rpmfind.net/linux/rpm2html/search.php?query=libjpeg-devel(x86-64)

I can remember the small stuff I pushed:

• Raw mouse input support (maybe SDL handles this now, I'm not sure)
• Game window without border
• Game window centering
• Improved some multi-monitor issues on Windows (where vid_restart would cause the game to jump to another screen)
• MP configurable console transparency to match SP
• Console version number now 8 pixels to the left 

Pretty sure I made some minor engine changes too. @@Didz poked it a bit in JA getting portals to render correctly, he may have something to say.

I got portals rendering on quads and that's about as far as I think I got:

It had trouble rendering multiple portals at once and recursive portals, so it was basically with the same limitations as basejka misc_portal entities. The engine source code wasn't out at this point but in the Q3 source code I believe there's a single if statement that limits how many portals can be rendered at once to 1 (which also prevents recursion). This rendering experiment wasn't done with the portalmod source code, so there was no moving through portals here.

Also I wasn't sure how I'd fix issues like this, where the result of one portal renders through another:

In the 21st century, you'd probably do this with stencil buffers to limit the rendering of each portal to within their "viewport". Maybe this already happens and there needs to be multiple "levels" of stencil to handle distinct portals.

One year without downtime is not bad I guess

You do not need to open port 29060 on your server. The master server listens on that port, but it communicates with your server on whichever port your server is listening on (sending heartbeats from). If players can connect, your ports are all fine and the master server should be able to contact it. For anyone else finding this post by searching, make sure you have opened UDP port 29070 (or whatever you've set your net_port cvar to) incoming. TCP is not required.

If your server is not sending heartbeats, then you haven't set the 'dedicated' cvar to '2' or your sv_masterX cvars are not set. These are the only reasons that heartbeats wouldn't be sent.

So I've done a little playtesting. For some reason the clip brushes are behaving normally now.... However there are three specific "shaders" that cause my character to freak out and it appears to be on obsidian walkways, office_supports & a vader floor. I can't seem to figure out the science behind it. While the two issues are linked to the same shader perhaps, the icy surface is still inconsistent.

 

EDIT:

The issue at hand is very inconsistent. They seem to switch between different brushes each restart?

 

EDIT2:

Seems like this is a normal glitch with importing bspmodels, never experienced it with earlier builds. Probably because I'm using a lot of brushes or something? Restarting it over and over as the guide written on steam says ends up consolidating the issue but there is still a random selection of surfaces that experience this "slickness". Did I exceed a limit of some sort? Should I not be using water or lava shaders? *Scratches chin*

It's been a while since doing BSP modding, but I remember having this issue sometimes too. I think all that I had to do was move the sub BSP instance to somewhere else in the level. Try adding or removing zeroes to the end of the BSP's origin.

This may actually be an issue that relates to the size of the sub BSP too. I vaguely remember the derpiness in larger maps when you're relatively far away from their origin, whereas simple ones like t1_inter would work fine.

You're backwards - misc_model gets converted to brushes, misc_model_static is an entity.

What I mean was convert misc_model_breakable to misc_model_static. misc_model are indeed converted directly to brushes and so won't count against the entity count. misc_model_static are client-side entities that get loaded at runtime and won't contribute to the server's entity count either.

This simply means you have too many entities in your map. There's a limit of 1024.

If this is because you have loads of misc_model_breakable entities, you'll need to change them to misc_model or misc_model_static since those don't count towards the entity count. These would require clipping brushes made for them for collision, since they're not entities on the server-side.

You may also be using dynamic lights in your map instead of the normal light entities. Make sure you only use 'light' entities where the lights are just static - the others will take up entity space.

Awesome

The weirdest thing here is that it works at all for any other player. All assets need to have relative paths that are shorter than 64 characters. This isn't a Mac-specific thing - MAX_QPATH has always been 64 in JKA and files that have longer paths will simply not be loaded (models missing in-game, textures showing the default image, etc.) or stop the game.

The build slaves seem to be fine @@Caelum, though @@ensiform's latest changes don't compile so there's a lot of red on the waterfall display. If you have an OSX build server to volunteer, that'd be great; that one's not up all the time.

@@Cat's build master has somehow lost the 'rsync' command though . This is the cause of the lack of uploads of builds to builds.openjk.org.

I thought the plan was to migrate all the deployment over to Appveyor anyway, so it might be worth looking into doing that sooner rather than later.

There have been some major changes in SP recently relating to the parser engine that's used for EFX files: https://github.com/JACoders/OpenJK/pull/748

This problem could be caused by those changes. Have you noticed any other effects that are missing in SP? These would include torches, smoke, explosions, etc.

cc @@mrwonko

Occasionally when I navigate to pages after idling for a while, I just get a Connection Reset message in Firefox (latest). Sometimes I get a JKHub 500 Error page screen. Refreshing usually fixes it.

I believe @@ouned's JK2MV fixes this, but I could be wrong.

It's a known exploit in JK2 and JKA that requires a client-side patch to fix it.

EDIT: Having looked at the code, yes JK2MV does fix this problem.

So for a room with light value 0.5 everywhere, JKA just multiplies the raw RGB value from the texture with 0.5 and puts that on the screen? I guess it's only noticeable when you know the problem exists!

Are those light values in linear-space but being outputted as gamma 2.2 RGB values? It looks a bit darker than I expected

You want to buy a graphics card for a Dell Inspiron Zino HD 410 like this?

It's not going to happen; there's no room to fit a graphics card into one of these little things.

Unintuitively, shaders earlier in the alphabet are preferred over ones later (so gfx.shader would override new_water.shader). There's no guarantee that this will be the same with different engines like OpenJK though, it's pretty much just an internal quirk.

What's the exact warning you get in the console after you removed the base water image? It could be that it's a warning about the JPG format of your new image. The images must be saved as interlaced JPGs, not progressive.

Be sure to test your changes by putting them in a .pk3 archive. It should be alphabetically after all the base assets, and many people use a convention like z_animatedwater.pk3 when testing. (You might know this already and it might be patronising)

EDIT: This is the code that draws the water wake shader, in case another coder can spot something I've missed that would prevent an animated shader being used: https://github.com/JACoders/OpenJK/blob/master/codemp/cgame/cg_players.c#L4791

Close VS and try running CMake again to re-generate the project files. Make sure the lines involved in the errors here aren't different to the upstream OpenJK code.

I'm quite happy with the Microsoft Sidewinder X4 keyboard, I feel it's good for programming and gaming. Pressing the keys is not like a mechanical "click" or the soft "squidge" of other keyboards, it's more like a soft "clunk". You have the positive tactile feedback of knowing exactly when the keys are down, but without the frills/noise/price of a mechanical keyboard. Other reasons I got it was: full-length (with number pad), programmable keys, proper F1-F12 keys (not replaced with buttons), lit keys, affordable price.

Uuuuuunfortunately, it's been discontinued now so you'd need to find one on eBay. NewEgg and Amazon have it, but their prices have jumped to exorbitant levels because of the rarity.

A brush with the weatherzone shader should encompass any inside or outside brushes you have. Make this a misc_weatherzone entity brush. Make sure there's some padding of at least 16 units between the edges of the weatherzone and any inside/outside brushes inside it.

You can only use EITHER Inside brushes OR Outside brushes. You can't use both! Either place Inside brushes in area you want to shelter from weather, or place Outside brushes in areas you want weather to affect. The weather engine snaps inside/outside areas to a grid of 64, so make sure you align these brushes to the 64 grid in the map.