nornware AB is happy to announce a new update to Space Beast Terror Fright.
(PROBABLY) PENULTIMATE EARLY ACCESS UPDATE Much to my chagrin SBTF is now in its sixth year of development. That's way too long.
The past year or so hasn't really seen a huge number of updates, and much of my time has been spent on researching yet another potential re-write of the network code (I've talked about it as a "hybrid" system). Progress has been made in that direction, but ultimately I've come to realize that even though that system has the potential to increase perceived quality of the networking experience it won't actually add any new functionality.
I've also spent quite a bit of time on a SBTF Discord server (https://discord.gg/GepWN2V) talking to some of my users, and this has really improved my objective sense of where this game is at and as such I think it's time to draw the line.
The list of things that COULD be done is infinite, but I feel that SBTF has been in a pretty good place for quite a long time now. There is by this point quite a bit of resistence to change in the codebase, and also I'm much more motivated by the thought of working on a potential sequel product; I've already done quite a bit of research and prototyping along those lines.
Subsequently I'm hoping that Update 58 will be the next-to-last update for SBTF before it finally leaves Early Access. I'm expecting Update 59 to be necessary as I've been doing some pretty extensive changes to the code and as such expect bugs in Update 58, but I also plan for Update 59 to include all the absolutely-must-have polish changes as well.
Of course I will be monitoring the state of SBTF even beyond release, and will fix any critical bugs that may come up. Don't hesitate to report issues in the forums or via email.
NEW OPTION - BEASTS LURK I have implemented a new option for Beast "lurk" behaviour. Since the ability for Beasts to hide / lurk in the infestation was implemented it has been observed that this can be exploited in conjunction with total infestation and map saturation (when the number of live Beasts reaches the game limit), resulting in a situation where all Beasts are lurking and will remain that way unless you shoot them or get too close.
This new option defaults to on (legacy behaviour) but with it turned off Beasts will never lurk in infestation, and this results in a generally more hectic gameplay experience (reminiscent of old). Note that in Randomize All / MotD this is among the options that will mutate on the fly, and I think this leads to even more dynamism in the overall experience; whole rooms of lurking Beasts may suddenly awake all at once. Also in Campaign of the Week this options starts on but will turn off over time as options randomly "get harder" over the course of the campaign.
NEW OPTION - REACTOR SAFETY PROTOCOL Also new is the option for "reactor safety protocol" which is the relatively new behaviour of all barriers opening during a reactor overload (defaults to on). This addition has proven to be somewhat contentious in the community and that (along with the fact that I really wanted the Beast lurk option) led me to implement this as an option as well. Note however that this option does NOT mutate on the fly, but in Randomize All / MotD this will be randomized at map generation time. In CotW this will start off (legacy behaviour) and eventually change to on (all barriers open during overload).
Note also that you might want to adjust your user plan options, as the new options are new bits that will default to 0 / off.
INSTANT ACTION PIPELINE It has been speculated that a rather common behaviour among players is a reluctance to actually host network parties while much preferring to join parties that are in progress. This has rather a detrimental affect on the health of the multiplayer community, and it got me thinking about ways to improve the general situation.
What I've come up with is an extra screen that precedes both the local game setup screen as well as entering the network pub, which allows access to the "Instant Action" pipeline. This is a much simplified screen which allows you to choose the number of players (in local mode) and your weapon loadout(s) and then simply jump straight into the action without any further setup required. This is technically equivalent to Randomize All, and all character progression is to those character slots, but you won't be exposed to any setup nor statistics before or after missions when in the Instant Action screen.
For network play things are a bit more complex under the hood, but everything is streamlined in order to get you into the action as fast and as painlessly as possible. When you press Launch Mission on the networked Instant Action screen you will automatically be placed in the first free slot of the first available party (in the interest of filling up all parties). If there are eligable parties you will simply become the host of your own new party (in Randomize All mode), and incoming players can / will join you as they come along.
Note also that this is 100% compatible with the legacy pub system which still exists and functions the same way as before. Regardless of how a party was started (Instant Action or via the pub) they are technically the same thing, with the only difference being that when Instant Action parties are initially hosted they will run in Randomize All mode with all default party options (friendly fire on, reinforcements 2, and public). The ideas here are to not fragment the user base at all, retain all deep legacy options, while also allowing for a fast-path into the game for those who are uninitiated or may simply be uninterested in messing with the options.
I hope that this addition will further ease players into the networked aspects of SBTF.
CHARACTERS / STATISTICS REWRITE For the longest time I've wanted to properly support character statistics for all characters in a mission. With the implementation of reinforcements long ago this kind of broke, with the outcome screen showing only the last characters in each slot. I thought this would be pretty simple to fix, but it quickly ballooned in complexity and is the main reason this update has taken so long to complete.
The technical details are messy and lengthy and ultimately not really interesting, but finally I've (hopefully) managed to repair all of the damage caused by this change (among others), and now you can view statistics for all characters in the outcome screen using the scroll wheel while hovering with the mouse cursor above each of the "slots" (red, green, blue, gold). Because of the need to track the mouse cursor position both the outcome and the team statistics are now modal as opposed to previously being "mouse over" only - I realized that the problem of displaying all this information really becomes three-dimensional.
This might seem like a minor or even insignificant improvement to the game as a whole, and indeed had I known how difficult the implementation would prove to be I most likely would have skipped it. However it was all mixed up with numerous other improvements (not least being the new options) so I was reluctant to throw away the development branch entirely and as a result continued to push through. Technically there have been a number of other changes made under the hood that were intended to facilitate the hybrid network implementation, but again I've decided against doing that prior to release. That stuff will however most likely find its way into future products.
MISCELLANEOUS
"SURVIVED" instead of "SUCCESS" in outcome table.
User Plans are now robust for no internet connection / unavailable backend.
Better user interface / incremental decoding of User Plans.
Increase the number of vfx / sfx events from 32 to 64 per tick after identifying certain things being missed / dropped.
Space Beast variants no longer have easily identfiable stripes on their tails, making them better camouflaged in infestation.
LAN network mode now uses computer name instead of trying resolve a host name from ip adress (faster and more reliable).
Networking is in general more robust, with all recoverable / non-fatal errors being silently ignored.
The "rapid fire" bug in network mode has been addressed by fudging timestamps.
Better replay restocking, showing currently parsed lines while still restocking.
During reactor overload all barrier frames now alternate between evacuation prompt and time remaining until overload.
During reactor overload fence frames now properly show evacuation prompt.
During reactor overload all barrier control boxes are disabled if reactor safety protocol is on.
As always, thank you for your support and patience. /nornware AB c/o johno
nornware AB is happy to announce a new update to Space Beast Terror Fright.
NETWORKED MODE CHANGES With the help of the gracious players over at the Space Beast Terror Fright Discord Server I have managed to reproduce and find the cause of what we believe to be the main recurring crash in networked mode. It was being caused by a number of collaborating factors (and bugs) that resulted in the game literally "running out of bullets".
I have plugged that hole by simply not allowing that many bullets to exist, which practically means that no sentries nor players will fire when the bullet pool is exhausted. Note however that via extensive testing I have found that this doesn't happen during normal play, and the crashes that have been happening are more a result of erroneous simulation (i.e. "the rapid fire bug") that occurs on the host during networked play. Rest assured that this is also a high priority bug for me to fix.
Furthermore network data has been somewhat compressed (bullets use fewer bytes), and also I'm experimenting with having the host / server push twice as much state to the client per network packet. While this will increase bandwidth usage somewhat it will not do so in a linear (2x) manner due to each packet being compressed (as before). This change is experimental, and I will be monitoring closely to see if it improves or degrades the overall network experience.
FURTHER REACTOR OVERLOAD SAFETY Early Access Update 56 introduced a new twist to the reactor overload sequence, namely that Doors and Fences open (conceptually in my mind as a "safety feature") and may not be closed during the reactor overload. While this has been contentious in the community, I'm still not fully convinced if it should stay or go. For the time being I have continued along this line of reasoning and now Panic Room doors will also open in the same manner as Doors and Fences during reactor overload.
SENTRY AMMO BUFF Sentries will now use the same ammo tier as players, meaning that increasing Science will upgrade sentry bullets as well - previously Sentries would always fire light ammo (albiet with different audio than player fire). Note that ammo tier fire rate variance will also affect Sentry fire rates (as with player bullets).
Note that this effectively means that Sentries become more deadly vs Space Beasts and Astro-Creeps as Science increases, while damage vs players is still the same (one upgrade or system knocked out per bullet striking a player).
MISCELLANEOUS
BUGFIX: Network chat was missing for non-hosts when a User Plan was selected.
BUGFIX: It is now no longer possible to wake Beasts inside Panic Rooms by firing at the Panic Room door.
BUGFIX: The "friendly" check (for players and scientists) will no longer penetrate walls.
As always, thank you for your support and patience. /nornware AB c/o johno
nornware AB is happy to announce a new update to Space Beast Terror Fright.
MAINTENANCE / COMPATIBILITY RELEASE This update is mainly to align the deployed version of the game with the current nornware codebase / toolset, which has progressed quite significantly since Early Access Update 55. This will allow me to find and fix any errors in a more expedient manner.
Although I've done extensive internal testing, it has always been the case that deploying a build to the general public is implicitly superior in terms of test coverage. A it's been over 6 months since the last update, please report any problems in the forums.
POTENTIAL 4K / DPI-SCALING / MULTI-MONITOR FIX An experimental / potential fix for the recursive hang on startup has been implemented (disabled checks for window size matching backbuffer size). If you see strange window sizes / resolutions, try switching between windowed mode and fullscreen using ALT+ENTER.
I have reproduced the issue with DPI-scaling on Windows 10, and at least on my system this fix solves the issue. It would be helpful to know if this fix also solves issues related to 4k resolutions and / or multi-monitor setups; please report your findings in the forums.
REACTOR OVERLOAD CHANGES With this build, immobile ("lurking") Beasts awake immediately when the reactor overload sequence begins, and no beasts will lurk again until the end of the mission (escape or overload).
Also, all Doors and Fences will now automatically and gradually open in a cascade during reactor overload (including the airlock door). During the overload you may open any yet to be automatically opened Doors and Fences (as the cascade takes a bit of time), but you may not close open ones again during the overload sequence (interaction is denied).
Note that these changes have the potential of making the game both easier (no barriers obstructing your path to the airlock) and harder (less obstructed line of sight for Beasts, as well as no lurking Beasts) during the reactor overload sequence. Feel free to discuss in the forums.
MISCELLANEOUS
BUGFIX: Fixed swapped upgrade announce position of Infravision and Battery Life.
The menu background world fly-thru scene is now also dimmed properly in networked mode, the same is in the local party setup screen.
The HUD will now warn you that Scientists are friendly if you aim at them, in the same manner as teammates.
Mission of the Day now uses legacy characters and science in order to simplify things internally. This means you can now play MotD with an upgraded character if you like.
Ammo "Rate" is now "Re-Arm" in HUD text.
The visualization code can now handle more events (event max from 16 -> 32 per tick). I found that a full shotgun blast to a player was overflowing the buffer. It is possible but unknown if this was the source of crashes in networked mode when using the shotgun.
Replays have been further compressed.
Lore / Databank unlocks will no longer occur during networked play.
Stan Brown Studios has been credited in the About screen.
As always, thank you for your support and patience. /nornware AB c/o johno
Space Beast Terror Fright : live stream with Timpedia
What?
Timpedia will be doing a live stream of Space Beast Terror Fright on Saturday July 11th 2020 at 10:30 am EST (16:30 CET). I (johno / nornware / the developer) will be joining via voice chat to discuss the game as well as answer any questions the community might ask during the event.
Hope to see you all there! /johno
When?
Saturday July 11th 2020 at 10:30 am EST (16:30 CET)
Where?
https://www.youtube.com/c/Timpedia/live
Early Access Update Femtiofem (55)
Early Access Update Femtiofem (55)
build id: 5EA16C27
nornware AB is happy to announce a new update to Space Beast Terror Fright.
COMMUNITY RESPONSE TO USER PLANS First of all I would like to express my extreme joy and satisfaction at the level of community engagement in regards to the ability to share user plans since Early Access Update 54. The sheer number of plans as well as the fantastic creativity you all have shown is fantastic, and it really gives me a great sense of accomplishment and that all the work put into the editor and the new back-end has been well worth it.
Thank you all! XD
USER PLAN SIGNATURES As some of you may have noticed in the last update, any user plans that weren't created by yourself or one of your Steam Friends would simply display [unknown] as the author. The reason for this is the fact that I'm storing user plans in a third-party back-end (not via Steam's systems), and hence I'm not allowed to do look-ups to get user information via the steam id of the user who created the map. This is by design and really a good security feature on their part.
In order to play nice with GDPR I've opted to not try to hack around this but rather change the user plan format to store a signature field where the user can optionally sign and / or describe their creation. It is of course completely optional to do this - signing a map is a post-creation step just like flagging it as public (via "my plans"), so there is no requirement to do this if you prefer not to.
As part of the technical work to achieve this change the existing user plans needed to be moved to new storage, and this achieved via a batch conversion process. I will be doing the final conversion just prior to rolling out this update in an effort to catch all the latest user plans and modifications.
The legacy storage is still intact however, so if you feel that the conversion process managed to miss something that you created at the eleventh hour before the update please email me (contact@nornware.com) with the name of the user plan and I'll sort out the conversion.
The new storage format is technically much more robust to changes in the data formats, so I don't anticipate the need for any more large scale conversions like this.
NEW USER PLAN SELECTION SCREEN Due to the great influx of user plans I've invested in a new selection screen for user plans that is more reminiscent of the "my plans" screen available via the editor. It uses most of the screen, shows plan previews in the large / pretty format, and also displays more informative tool-tips. I've also implemented a number of sorting / filtering options that should help with managing the large number of user plans that are already in the system.
I anticipate that it might be a good thing to have a free-text search field as well, not least if users start signing their maps in a consistent manner.
I've also seen at least one instance of maps being named in a way that suggests the desire for "user campaigns" - I assume the intent is to create maps that are meant to be played sequentially, with the requirement to finish them in order. I'm definitely interested in supporting something like this if there is demand for it.
UNLOCKABLES / LORE / DATABANK Coming out of some of the technical work with the new user plan storage format I had the idea of some of the Datacores including "secret information" that you could randomly roll as the result of a download. This led in turn to the implementation of "unlockable lore" in the game, which at this point is mainly all the history / development information pertaining to S.B.T.F. that I could find, some of which is quite ancient by this point. I don't know how interesting this will be to the average user, but it certainly amounts to a lot of stuff, so I chose to use that as a "lore" component to the game.
There is now a Databank button in the main menu which will take you to a screen that shows a large number of unlockable pieces of "lore". Initially none of it viewable, but as a result of playing the game in a normal manner there is always a chance that you will unlock a piece of lore / databank entry with each Datacore download. There is an accompanying audio cue as well as a text notification that flashes at the top-center of the screen when this occurs, and after that once out of mission you can peruse this information via the Databank interface (use the scroll wheel + shift).
I would optimally have liked to have more game-relevant / in-universe lore / story stuff to unlock, but that would certainly be a lot of work to write - just collecting and formatting all the stuff that I "had already produced" was a massive undertaking of several full workdays.
In any case I hope that at the least the simple act of unlocking this stuff will add a sense of progression to the game, and even if you have no interest in reading it all simply the goal of unlocking all of it will cater to the (possible) completionist inside you.
The Databank is a completely local feature, and as such functions in all modes as well as in both local and multiplayer. If you ever want to reset your progress, simply delete this file:
C:\Users\\AppData\Roaming\nornware\sbtf\lore.txt
KNOWN ISSUES
In multiplayer mode, user plan signatures (if present) are only displayed for the party host, not for other party members. Signatures however work properly in local mode.
Surrounding the airlock with alt-walls in a user plan will cause erroneous geometry to be generated.
MISCELLANEOUS
BUGFIX: Enabling chat input when in-mission could cause input lock-ups when playing user plans.
BUGFIX: Potential crashes when quickly switching leaderboard weeks on the CotW Leaderboard screen.
BUGFIX: Hosting a party with non-empty chat input could crash in multiplayer.
BUGFIX: Random breaches could spawn in airlock.
BUGFIX: Slush memory increased from 1MB to 2MB - certain maps with large numbers of active sentries / simultaneous Beast deaths could cause overflow crashes in particle systems.
BUGFIX: The game is now robust for the user plan back-end being unavailable.
Navigation of linebroken text is much improved - this applies to both multiplayer chat as well as user plan signatures.
The holotable map display has been tweaked to be closer to the surface of the underlying geometry / no more floating.
Sparks for fences now have better / matching colors.
The replay library now shows progress in percent while parsing the replay files on disk.
The menu background world is now faded in at startup.
The menu background world is now slightly darkened in relevant screens to improve readability (Mission Setup and Databank).
There is something strange going on in panic rooms these days...
As always, thank you for your support and patience. /nornware AB c/o johno
nornware AB is happy to announce a new update to Space Beast Terror Fright.
SHARING USER PLANS Building on the previously deployed user plan editor, this update features online storage of all user plans (as opposed to the previous local storage). This means that it is now possible to share your creations with the entire community.
You can set your maps to public or private (they are initially private upon first save), and this is intended to facilitate private iteration on your work until you feel you are ready to share it publicly. Note that it is still possible as multiplayer party host to play one of your private user plans with your party; this is analogous to playing a locally saved user plan in multiplayer in previous updates.
User plans are color-coded in all lists as follows:
BLUE = other users' plans which are public (otherwise you wouldn't see them)
WHITE = your plans which are set to public (other users will see these as blue)
ORANGE = your plans which are set to private (othere users will not see these)
It is now also possible to like other users' plans. This interface is to the left of each plan name in the mission setup screen (when in user plan mode), and the number of total likes per plan are displayed to the right of the corresponding plan name.
For those of you who have invested in user plans prior to this update (which are saved locally), there is an interface to import these plans to the new backend; from the main menu go to the editor, click "my plans", then click "import". If any previously saved user plans exist on disk they will be listed here, and can be loaded into the editor as usual. After that you can save the plan to any unique name (per user) in the new backend, and after that you can set them to public when you are ready to share via "my plans".
MISCELLANEOUS
A new test for sentry object limit has been added to the editor.
Widget / button backgrounds are now solid and hopefully more readable.
As always, thank you for your support and patience. /nornware AB c/o johno
nornware AB is happy to announce a new update to Space Beast Terror Fright.
NEW STYLE : Oracle A new style has been added (Oracle), designed in collaboration with Stan Brown.
NEW WEAPON TEXTURES Since the first person weapons are so visible in the game (cover so much of the screen), Stan Brown and I thought they would be a good candidate for a VPBR paint-over.
MISCELLANEOUS
Fixed some weird back-lighting artifacts on first person weapons.
Proper persistence check (unsaved changes) when exiting user plan editor.
Slightly transparent walls in user plan editor, which allows the menu background to show through slightly.
As always, thank you for your support and patience. /nornware AB c/o johno
nornware AB is happy to announce a new update to Space Beast Terror Fright.
BUGFIX FOR MISSING GEOMETRY TLDR: If you are experiencing missing geometry, set "shader model" to "2.0" in the graphics settings.
The previous update (50) introduced an updated set of shaders in order to support what I call Vaguely Physically Based Rendering (VPBR) materials. Technically this requires the use of shader model 3 (specifically pixel shader 3.0), but as this is part of the DirectX9.0c specification that I've always been using for SBTF I neither mentioned it nor expected it cause any problems (DirectX9.0c is at least 15 years old).
As we have seen however it seems that things aren't that simple. As far as I can see from my own research, as well as from diagnostics kindly supplied by the community, current AMD drivers do not properly support pixel shader 3.0 and / or all features of DirectX9.0c. Strangely no errors are forthcoming but rather the shaders simply silently fail to render anything at all, resulting in the "missing geometry" problems some users have been having.
The solution that I'm rolling out here is a bit of a tradeoff, but is in the interest of getting the game working again for everyone. There is now a graphical setting where the user may manually select shader model (2.0 or 3.0), where 2.0 is a simplified shader that approximates the VPBR materials very similarly to how the legacy materials are rendered, and 3.0 is the intended new VPBR shader.
As far as I can see in tests users who do not have AMD Radeon chipsets can run both shader models, while users with AMD Radeon chipsets will most likely experience missing geometry for all VPBR materials when shader model 3.0 is selected. Note that the renderer has been optimized since update 50 to only require ps3.0 for new VPBR materials; all legacy materials are rendered exactly as they have been prior to update 50 (using ps2.0) regardless of what shader model you have set.
Also, you may choose to run shader model 2.0 regardless as the approximation shader is cheaper in terms of instructions, and you might experience better performance. Trivia: The limit for ps2.0 is 64 instructions, and my approximation shader ended up being exactly 64 instructions!
It's important to note that nothing has "gotten worse" graphically compared to previous incarnations of SBTF, it's simply the case that approximations / trade-offs are necessary to get the new VPBR materials to render at all on AMD Radeon chipsets.
To be completely fair even the ps2.0 "approximation shader" is more advanced than the legacy renderer in that it differentiates between conductors and dielectrics; the main trade-off is that roughness is not modeled as it is in the VPBR ps3.0 shader and as such the reflection model is simplified. For those interested in PBR theory, Marmoset has a good primer here, and Allegorithmic has published an in-depth guide.
Hopefully this solution will get the game back to a functioning state for everyone, regardless of GPU. If this proves to be solid I have some ideas about possible extensions to the ps2.0 approximation shader in order to get the roughness part of VPBR in there; it's really a big part of the artistic expression.
As always, thank you for your support and patience. /nornware AB c/o johno
nornware AB is happy to announce a new update to Space Beast Terror Fright.
NEW MENU BACKGROUND It's really amazing (as an indie developer) to be able to add any kind of crazy / silly thing you want to your game, on a whim. Space photo-copiers, panic room toilets, friends' faces making silly expressions on player models, things like that. That's why you've all been staring at myself in the guise of a frightened space marine in the background of all the front-end menus of the game for a long time now.
However, I wasn't completely happy with that (menu background), and had for a long time been thinking about something more animated. I recalled how in the end of Portal (I think) there was a kind of fly-thru of the complex, down into the basement to see the place where they stored all the personality spheres (or whatever they were called). Since SBTF is basically all about basements (so to speak) I was thinking that it would be appropriate to have some kind of slow crawl through a map of the game with an appropriate muted / suggestive / mysterious shader.
This led to a pretty big refactoring of assets / loading / map generation and such, with the goal being to re-use as much as possible. Now the game takes a little bit longer to start up as I've chosen to keep as many things as possible in memory at all times, and also because on startup the initial background world is being generated. However after that all subsequent mission startup times have been sped up, and after each mission that same map is used for the following menu fly-thru background.
I really like how this new menu background turned out, and that in turn inspired me to iterate once again (this is the fifth time) on the main menu music theme.
NEW LEVEL STYLES (textures and geometry) SBTF has always been based around computer generated maps / levels / missions. The actual logical data is very simple; walls and floors on a grid in a single plan, with gameplay elements like datacores, sentries, armories, etc placed where there are floors according to certain rules. The visual side of things is completely separate from that, and a big goal is to make things feel engaging and complex and compelling by having visuals that "amplify" the actuality of what is happening.
To this end I create what I call "styles" which are the geometric and textural elements that are used to generate what you see in a level, basically a relatively small number of interlocking parts that fit together to create a cohesive whole. This was obviously a big part of the initial investment in the early development of the game, and as I've been working now for many years without a dedicated artist I wasn't able to iterate on any of that or introduce new "styles" for your viewing pleasure. This was disappointing to me personally, as I knew that there was more potential to be leveraged from the system.
I had been mocking up some new styles that I really really liked, but as I had done initially (pre-2015) I'd been doing design mock-ups using placeholder textures that I cannot legally ship, so I was (as before) facing the task of creating a large amount of textures with bespoke designs but this time without support from any kind of artist. I can certainly do some basic stuff in Photoshop, but I'm not a professional artist by any stretch, and I was severely questioning my abilities to create textures that I would be happy with from an art direction perspective.
I'd been observing (with some envy) the proliferation of Physically Based Rendering (PBR) throughout the game industry for some time, and that the popularity of this "standard" had given rise to a number of very interesting tools (Allegorithmic / Quixel) that I realized could potentially amplify my abilities to get the job done; things like semi-automatic texture-mapping, realistic materials, etc. PBR was also especially intresting in the context of SBTF due to the inherent ability of the shading model to more accurately portray the differences between metals and plastics.
I had always been keenly aware that my renderer wasn't in any way theoretically grounded, and it was initially immediately apparent that it was hard to try to create shiny metals without it looking like they were shiny plastic, as well as not being able to represent microscopic surface roughness in any readable way. Looking at PBR theory I realized that the ability to 1) differentiate between conductors (metals) and dielectrics (non-metals) as well as 2) more properly model roughness were at the core of being able to better represent the kinds of materials that SBTF is full of (metals and plastics composed in what I affectionately call "rymdpaneler", or in English: "space panels").
In all of this hemming and hawing I did quite a bit of research into various production methods, even to the point of writing a custom decal-based normal map creation tool, and almost settling on using that along with Allegorithmic Substance Painter to create all the textures that I would need. The initial tests weren't terrible (from an aesthetic perspective), but they weren't very amazing either. Added to that was the realization that either I would have to manipulate the output from the PBR-based tools to fit my renderer (not very compelling), or more realistically upgrade my renderer to accept and properly render PBR materials. Even worse; what if the new PBR renderer made all of the old materials incompatible and thereby absolutely REQUIRED me to update every single existing material in the game?
Happily around that time industry contacts led me to the eminent Stan Brown, and it turned out that he was getting into specializing in the field of tiling PBR materials for my exact use case. After some initial talk and tests it was obvious to me that Stan would blow anything that I could produce out of the water, so I contracted with him to do all the new material work.
As a result, this update features 3 new level styles (Adamant, Bastion, and Disciple) designed in collaboration with Stan Brown, all featuring what I like to call Vaguely Physically Based Rendering materials. You will be able to see more clearly what is meant to be metal and what is meant to be plastic (Fresnel-Schlick approximation baby!) in these new styles, and happily I ended up being able to write a renderer that lets the VPBR materials exist side by side with the legacy materials quite well (bullet dodged!).
At least 2 more styles are included in the current batch of work, and will be released in subsequent updates as they are completed.
Oh yes; during all of the style work I've updated my geometry tools to support procedural pipes and bends. This enables a lot of new cool geometry that you will see in the new styles.
MISCELLANEOUS
Fixed some instances of erroneous door / fence rotations.
Fixed a valid breach location that wasn't properly spawning breaches.
