treecannon niveus Good job with them both!
Thanks :)
Also, we have means of stopping the jettard camping with our new alien. So, if at all possible with future releases, could you continue creating an alternate one so that jetpacks are enabled?
Interesting problem. Version 004 of skybox is being rendered since Thursday evening, and I hope to see a good result tomorrow when I am back at that computer.
Now, if I wanted to make a 2nd version with jetpack enabled, I'd have to render the whole thing again. But I'll try to just invalidate the '"disabledequipment" "jetpack"' in the BSP with a hex editor and release it as 004jp if it works.
...
EDIT after 32 hours:
Ok, new version of Skybox will be released this evening. But I will make no extra jetpack-release even though the editing of the BSP file with hex editor easily worked. And the reason for that is simple:
If someone makes a modded server, they are responsible to adapt to special map situations. I had a 300+ buildpoints map on [W]onderland, but the server just stupidly painted its 200 buildpoints over it. And in this situation here, where there is a server that features flying aliens, it is the server maintainer's responsibility to look for something like a prohibited jetpack and either override it or disable the flying aliens just as well.
On another note:
This new release of skybox will have texture problems if you have an older version of skybox in one of your base folders. The short-sighted reason is that I changed the gmotw_skybox.shader file without renaming it. In the future, I intend to rename the subfolder in all asset folders for new releases. Apparently, this is necessary. Conveniently, this and other things (e.g. wtf an arena file is good for in the first place) are not mentioned in the mapping tutorials.
The far-sighted reason for this problem is the stupid way the programmers have dealt with the file handling. On client start, the content list of all PK3 files in the game's base folders is read into a big file list. If there's a file that exists several times with the same filename and filepath (which is effectively encouraged by the PK3 approach), just one of the entries is kept. It would have made more sense to keep
all entries and then in case of doubt access the file that lies within the PK3 that the actual map BSP comes from. But no. We all have to jump through hoops. So, I'll be hoop-jumping some more in next releases. But this time, we'll have to live with the problem. I'm not only fed up with revising this release again and again, I'm also not gonna invest another 112 hours rendering time.
This file problem, by the way, allows one map maker to fuck up all maps that you have with his file (as long as it is present). I and another user didn't have any more transparencies in all maps once the map "noobcannon" was present. After we removed the file, everything was fine again. We both use very old clients. I use TJW backport, and I think he does, too. This problem might not be present with newer clients. But as long as every webserver in the Trem universe serves the original Trem 1.1.0 setup (which does not feature player GUIDs, every deconned or otherwise violated player and every admin says "THANK YOU!"/s), we have to assume that this problem that I am describing here is the standard. Also, it makes sense to develop maps using old clients as long as the Trem world is widely using them.