[VERSION 1.01] Prime Directive (aka Space Station Omega 2)
Forum rules
The Projects forums are only for projects. If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.
Got a cool project idea but nothing else? Put it in the project ideas thread instead!
Projects for any Doom-based engine (especially 3DGE) are perfectly acceptable here too.
Please read the full rules for more details.
The Projects forums are only for projects. If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.
Got a cool project idea but nothing else? Put it in the project ideas thread instead!
Projects for any Doom-based engine (especially 3DGE) are perfectly acceptable here too.
Please read the full rules for more details.
Re: [WIP] Prime Directive (aka Space Station Omega 2)
Yep. And I found it too limiting/clashing with the real time conversations I have going. I'm not really happy that I had to freeze the player with my new scripted implementation either, but cycling without the bound forward and back keys these days seems like a capital offense.
Re: [WIP] Prime Directive (aka Space Station Omega 2)
Also, a bit of an update on how Prime Directive itself is going.
I've just about whiteboxed out the first section, which takes place over four different maps. Got a few more things that need doing, then I'll work on putting some monsters about, and then I might seek out some testers. Just to give me an idea of how the flow is going.
In flagrant disregard for public perceptions, I'll also be taking a page from how product builds are actually done. This project will go through four stages:
Pre-Alpha - This is what most people call a "beta". It's in progress, there's a few things there, and it's absolutely nowhere near final.
Alpha - Feature complete. What it means in practice is that you can successfully run from start to finish. Nothing new should be added after this point, but everything needs to be polished.
Beta - Content complete. A beta product is at a stage where it can be released. Final testing to make sure there's no critical errors happens at this point.
Gold - Finished. Released. Time to get reviews etc.
Right now? Absolutely in pre-alpha. So if anyone does put their hand up to try it, don't expect miracles.
I've just about whiteboxed out the first section, which takes place over four different maps. Got a few more things that need doing, then I'll work on putting some monsters about, and then I might seek out some testers. Just to give me an idea of how the flow is going.
In flagrant disregard for public perceptions, I'll also be taking a page from how product builds are actually done. This project will go through four stages:
Pre-Alpha - This is what most people call a "beta". It's in progress, there's a few things there, and it's absolutely nowhere near final.
Alpha - Feature complete. What it means in practice is that you can successfully run from start to finish. Nothing new should be added after this point, but everything needs to be polished.
Beta - Content complete. A beta product is at a stage where it can be released. Final testing to make sure there's no critical errors happens at this point.
Gold - Finished. Released. Time to get reviews etc.
Right now? Absolutely in pre-alpha. So if anyone does put their hand up to try it, don't expect miracles.
Re: [WIP] Prime Directive - seeking willing testers
In a day or two, I'll have a nice PK3 ready for some testing. It will be the first pre-alpha build. The flow up till you get the Yellow Key is in, and I've been putting some battles in, tweaking existing battles, and incorporating the actor dialogue in to the setup. And to that effect, I'll be seeking bug reports and gameplay suggestions (mainly to do with the new "enemies" I've put in).
This first section has turned out a bit more linear than I originally anticipated, but it does show the scope of the project and sets the rest of Prime Directive up quite nicely. The mission statement is to create the greatest story-based ZDoom map/mod ever. The story script is hitting the right notes, and I'm really quite happy with what I'm doing with the dynamic dialogue system (it's incorporating ideas I've had for eight years, and Space Station Omega does impact how it plays out).
Testers can send me their email address via my private message inbox, but do keep in mind that I'll be biased towards the more senior members around here. It's only because I've known them much longer (and some of them have tested my old maps previously so I know what kind of feedback I can expect) so don't take it personally if you registered in the last six months and don't hear back.
This first section has turned out a bit more linear than I originally anticipated, but it does show the scope of the project and sets the rest of Prime Directive up quite nicely. The mission statement is to create the greatest story-based ZDoom map/mod ever. The story script is hitting the right notes, and I'm really quite happy with what I'm doing with the dynamic dialogue system (it's incorporating ideas I've had for eight years, and Space Station Omega does impact how it plays out).
Testers can send me their email address via my private message inbox, but do keep in mind that I'll be biased towards the more senior members around here. It's only because I've known them much longer (and some of them have tested my old maps previously so I know what kind of feedback I can expect) so don't take it personally if you registered in the last six months and don't hear back.
Re: [WIP] Prime Directive - seeking willing testers
And the first pre-alpha build is up! If anyone else is interested, now is the time to message me.
Re: [WIP] Prime Directive - seeking willing testers
This post is just a bit of a "development diary" so to speak.
Being a sequel to Space Station Omega, there's three design principles that I need to stick by:
The second point - it must have a strong intrinsic story - is coming along excellently. I've learnt a lot about storytelling over the last ten years. Taking my original outline for The Gateway Experiments, I've skipped a few chapters and am working on the one that I was looking forward to working on the most. A few things have happened in the interim - most significantly for the characters, Russell and Elaine's ship was boarded as they made their escape from Space Station Omega and Elaine was captured. The driving force for Russell's motivation in the latter half of episode 2 and in episodes 3 and 4 was to rescue Elaine. That was a success. Elaine didn't come out unscathed though, as the interrogation/torture she went through has left her with Post Traumatic Stress. Elaine needs Russell as a means of holding on to normality, and despite the fact that she killed her interrogator she still doesn't have the closure she needs on the Gateway Experiments. But, as always, player choice is a large part of how she deals with it.
And that ties in to the last point. In the early stages of Prime Directive, the only real choice you have is how to deal with Elaine. Through necessity (and as a result of atmosphere/tension building), the first section of the base assault is a bit of a linear trek through the base. You're constantly on the back foot, and you have no choice but to push in a safer direction than the way you'd rather go. But then there's a point where that all changes, and you start to get the upper hand. And that's where the SSO choice comes back to the forefront. Once you realistically have a choice, that's when I'm letting the player have one.
The current development choices I'm facing though is how to keep a non-linear Metroid/Dark Souls approach to the larger part of the campaign without spiralling the map design out of control. There's story beats I need to hit, there's choices I need to leave the player, and there's the fact that I don't want to spend all my spare time up till November getting this WAD in order. Hitting that initial flow up to the yellow keycard was easy. The rest of it is not as easy. But it is a great design challenge.
Being a sequel to Space Station Omega, there's three design principles that I need to stick by:
- It needs to feel like Doom
- It must have a strong intrinsic story
- It must have user choice
The second point - it must have a strong intrinsic story - is coming along excellently. I've learnt a lot about storytelling over the last ten years. Taking my original outline for The Gateway Experiments, I've skipped a few chapters and am working on the one that I was looking forward to working on the most. A few things have happened in the interim - most significantly for the characters, Russell and Elaine's ship was boarded as they made their escape from Space Station Omega and Elaine was captured. The driving force for Russell's motivation in the latter half of episode 2 and in episodes 3 and 4 was to rescue Elaine. That was a success. Elaine didn't come out unscathed though, as the interrogation/torture she went through has left her with Post Traumatic Stress. Elaine needs Russell as a means of holding on to normality, and despite the fact that she killed her interrogator she still doesn't have the closure she needs on the Gateway Experiments. But, as always, player choice is a large part of how she deals with it.
And that ties in to the last point. In the early stages of Prime Directive, the only real choice you have is how to deal with Elaine. Through necessity (and as a result of atmosphere/tension building), the first section of the base assault is a bit of a linear trek through the base. You're constantly on the back foot, and you have no choice but to push in a safer direction than the way you'd rather go. But then there's a point where that all changes, and you start to get the upper hand. And that's where the SSO choice comes back to the forefront. Once you realistically have a choice, that's when I'm letting the player have one.
The current development choices I'm facing though is how to keep a non-linear Metroid/Dark Souls approach to the larger part of the campaign without spiralling the map design out of control. There's story beats I need to hit, there's choices I need to leave the player, and there's the fact that I don't want to spend all my spare time up till November getting this WAD in order. Hitting that initial flow up to the yellow keycard was easy. The rest of it is not as easy. But it is a great design challenge.
Re: [WIP] Prime Directive - seeking willing testers
Development Diary #2
Today, I did something I've always wanted to do in Doom. I always thought it would be cool to ride an elevator down a cliff side to a base you were about to enter. Just for scene setting purposes. Now, I didn't do exactly that, but I did make an elevator ride up. It works fairly well in the story context, as it adds to a sense of anxiety for what is about to happen. With that section in, that pretty much has the flow for one of the quests you have to do whiteboxed. Once I script it, fixed the levels up, and incorporate dialogue and whatnot, that section will actually provide a welcome change of pace from the rest of the mapset. The first section is all about being on the back foot. This one's more an exploration and puzzle solving section. The section I'm working on next is more of an action section.
I think development is going slower than I want. I want to get the rest of the mapset whiteboxed by the end of the month. Then it'll be implementing the complete flow. At that point, I'll have hit alpha. Then it'll be all polish.
There's one massive scripting feature that I'm pondering. I won't detail it too much right now, but needless to say it adds even more to the choice I keep talking about. It'll certainly be one of the more unique features ever added to a Doom mod. The potential to break it is quite high, especially since while ACS is powerful it doesn't have nearly enough world querying functionality exposed for the purposes I'll be using it for.
I still really need someone to modify those sprites for me. I can code like a boss, but I can only art like a downs syndrome kid.
Today, I did something I've always wanted to do in Doom. I always thought it would be cool to ride an elevator down a cliff side to a base you were about to enter. Just for scene setting purposes. Now, I didn't do exactly that, but I did make an elevator ride up. It works fairly well in the story context, as it adds to a sense of anxiety for what is about to happen. With that section in, that pretty much has the flow for one of the quests you have to do whiteboxed. Once I script it, fixed the levels up, and incorporate dialogue and whatnot, that section will actually provide a welcome change of pace from the rest of the mapset. The first section is all about being on the back foot. This one's more an exploration and puzzle solving section. The section I'm working on next is more of an action section.
I think development is going slower than I want. I want to get the rest of the mapset whiteboxed by the end of the month. Then it'll be implementing the complete flow. At that point, I'll have hit alpha. Then it'll be all polish.
There's one massive scripting feature that I'm pondering. I won't detail it too much right now, but needless to say it adds even more to the choice I keep talking about. It'll certainly be one of the more unique features ever added to a Doom mod. The potential to break it is quite high, especially since while ACS is powerful it doesn't have nearly enough world querying functionality exposed for the purposes I'll be using it for.
I still really need someone to modify those sprites for me. I can code like a boss, but I can only art like a downs syndrome kid.
Re: [WIP] Prime Directive - seeking willing testers
Development Diary #3
I wasted tonight on a level transition to one of the last two levels I need to whitebox.
To get to the new level, you need to take a flight of stairs down. This meant I needed to go nuts with some 3D floors to complete the illusion. Fair enough. 3D floors are easy enough to work with, especially if you use GZDoom Builder (Which, by the way, is buggy and unstable. But so was DEU/DETH/ZETH. It's just a shock after Doom Builder being very stable in comparison). That took about ten or fifteen minutes to set up properly. But then it came time to incorporate the Half Life level transition in between the stair well.
It is at this point where things started to go wrong.
Despite setting it up correctly, the SetActorPosition call was failing. This had me scratching my head. Debug output was printed, and a few other things were tried. Until I realised that my scripts had only been setting X and Y. It was plugging a value of 0.0 in for the Z component. I was going in with my mapping knowledge - an actor's Z position is relative to the sector's floor unless explicitly told to be an absolute Z position. The documentation page for SetActorPosition didn't alert me that it was in absolute coordinates. I know, I should have realised, X and Y is in absolute after all, and querying GetActorZ gives you the absolute Z position, etc etc etc. It just didn't link up in my mind because the page was busy telling me how fixed math works rather than being clear what kind of coordinates it expects. I think I need to go through and clean up some of those wiki pages to be a bit clearer. So that other people don't do idiot noob mistakes like I do.
On the plus side, I was forced to extend my script to handle Z so I also forced it to handle velocity. Unfortunately, the way it's implemented is not clean:
I have to execute three separate scripts just to make this one effect work. This is part of where I come from when I describe the fragile nature of ACS scripts. I have a script called ge_globals_halflifetransition_begin that handles all this, and it basically takes in the source and destination anchors like I propsed with my Teleport_NewMap extension request. But I have to make the ChangeLevel call outside of that script. And if the order of execution of scripts changes on the next map for whatever reason, the entire effect will fail. I'll also have to get in and set up a proper example WAD for my feature request and attach it to the thread for a reference implementation. As it stands, I don't want to write a tutorial for this method as I find it easily prone for error if not used in the exact way I've set it up.
Oh well. Tomorrow night, I can get to whiteboxing the damned level finally. After that, I need to finish whiteboxing the sewers and put in a warehouse "secret" section (although I might keep that until after whiteboxing everything else). And then I'll release another build to testers. It'll be all about making the gameplay complete once I've laid down the bare bones geometry.
I wasted tonight on a level transition to one of the last two levels I need to whitebox.
To get to the new level, you need to take a flight of stairs down. This meant I needed to go nuts with some 3D floors to complete the illusion. Fair enough. 3D floors are easy enough to work with, especially if you use GZDoom Builder (Which, by the way, is buggy and unstable. But so was DEU/DETH/ZETH. It's just a shock after Doom Builder being very stable in comparison). That took about ten or fifteen minutes to set up properly. But then it came time to incorporate the Half Life level transition in between the stair well.
It is at this point where things started to go wrong.
Despite setting it up correctly, the SetActorPosition call was failing. This had me scratching my head. Debug output was printed, and a few other things were tried. Until I realised that my scripts had only been setting X and Y. It was plugging a value of 0.0 in for the Z component. I was going in with my mapping knowledge - an actor's Z position is relative to the sector's floor unless explicitly told to be an absolute Z position. The documentation page for SetActorPosition didn't alert me that it was in absolute coordinates. I know, I should have realised, X and Y is in absolute after all, and querying GetActorZ gives you the absolute Z position, etc etc etc. It just didn't link up in my mind because the page was busy telling me how fixed math works rather than being clear what kind of coordinates it expects. I think I need to go through and clean up some of those wiki pages to be a bit clearer. So that other people don't do idiot noob mistakes like I do.
On the plus side, I was forced to extend my script to handle Z so I also forced it to handle velocity. Unfortunately, the way it's implemented is not clean:
Code: Select all
ACS_NamedExecute("ge_globals_halflifetransition_setoffsets", mapNum, offsetX, offsetY, offsetZ);
ACS_NamedExecute("ge_globals_halflifetransition_setvelocity", mapNum, GetActorVelX(GE_PLAYERTAG), GetActorVelY(GE_PLAYERTAG), GetActorVelZ(GE_PLAYERTAG));
ACS_NamedExecute("ge_globals_halflifetransition_end", mapNum, destAnchor);
Oh well. Tomorrow night, I can get to whiteboxing the damned level finally. After that, I need to finish whiteboxing the sewers and put in a warehouse "secret" section (although I might keep that until after whiteboxing everything else). And then I'll release another build to testers. It'll be all about making the gameplay complete once I've laid down the bare bones geometry.
Re: [WIP] Prime Directive - seeking willing testers
lolGooberMan wrote:especially if you use GZDoom Builder (Which, by the way, is buggy and unstable. But so was DEU/DETH/ZETH. It's just a shock after Doom Builder being very stable in comparison)
Re: [WIP] Prime Directive - seeking willing testers
Sure, I haven't come across any critical DB bugs yet, but I have to constantly fight to get GZDB to behave. From it's inability to realise when I've let go of keys in 3D mode and failure to realise when zdoom has quit, to just plain random crashes, it isn't filling me with a lot of confidence in it. But it does 3D floors, so I stick with it.
Re: [WIP] Prime Directive - seeking willing testers
Development Diary #4
Tonight, we stayed back at work playing board games. Board games! I know, right? That shit's done with cardboard and paper and shit! But it did mean I finally got to play the copy of Munchkin Quest I bought after salivating over it for four years. So there's that. Other games running were Agricola and Eclipse. Eclipse is actually quite cool. It's almost what you'd get if you made an RTS board game. And it's always sold out whenever I go to get my own copy. Well worth a look if you're in to board games.
I got home after that... and realised I have a bit of mapper's block for one of the remaining maps. So I started work on expanding the sewers with one of the mission goals. And then I decided to rewrite the documentation for custom hardware shaders in GZDoom because I didn't like how it was written. I find it far more informative for the average user now - and it means I don't have to have the GZDoom code base open for reference.
I most likely won't write my own shaders for Prime Directive though. But hey. It should be easier for whoever else decides to take the plunge in to modern graphics programming now.
The soundtrack of this week has been Pink Floyd's The Division Bell. I'm conflicted by that album. On one hand, it sounds more like Pink Floyd than their output from the 80's. On the other, a large chunk of the songwriting is decidedly average.
Tonight, we stayed back at work playing board games. Board games! I know, right? That shit's done with cardboard and paper and shit! But it did mean I finally got to play the copy of Munchkin Quest I bought after salivating over it for four years. So there's that. Other games running were Agricola and Eclipse. Eclipse is actually quite cool. It's almost what you'd get if you made an RTS board game. And it's always sold out whenever I go to get my own copy. Well worth a look if you're in to board games.
I got home after that... and realised I have a bit of mapper's block for one of the remaining maps. So I started work on expanding the sewers with one of the mission goals. And then I decided to rewrite the documentation for custom hardware shaders in GZDoom because I didn't like how it was written. I find it far more informative for the average user now - and it means I don't have to have the GZDoom code base open for reference.
I most likely won't write my own shaders for Prime Directive though. But hey. It should be easier for whoever else decides to take the plunge in to modern graphics programming now.
The soundtrack of this week has been Pink Floyd's The Division Bell. I'm conflicted by that album. On one hand, it sounds more like Pink Floyd than their output from the 80's. On the other, a large chunk of the songwriting is decidedly average.
Re: [WIP] Prime Directive - seeking willing testers
Thanks for that.GooberMan wrote:I got home after that... and realised I have a bit of mapper's block for one of the remaining maps. So I started work on expanding the sewers with one of the mission goals. And then I decided to rewrite the documentation for custom hardware shaders in GZDoom because I didn't like how it was written. I find it far more informative for the average user now - and it means I don't have to have the GZDoom code base open for reference.

The documentation was pretty bare-bones here because I didn't felt knowledgeable enough about the topic to go in-depth, and nobody else stepped up until you did.
Wait, can we get the texture's texel dimensions with this function and sampler2D tex?
Re: [WIP] Prime Directive - seeking willing testers
Correct.
I should also be able to fudge with LODs and force my star textures to sample the lowest level mip with some tomfoolery. The effect of a starfield is destroyed in Space Station Omega when any of the mipmapping filters are turned on (none with nearest/linear mipmap; trilinear; anisotropic). So if I can be arsed, I'll whip up a shader for that. Be aware that you'll need to reimplement GZDoom's getTexel function if you want to try that yourself:
EDIT: In fact, I can disable filtering altogether for my star textures:
I think I might be arsed doing that shader after all.
EDIT 2: Alright. Scratch that. You can't have some of those functions because you need to have a greater shader version than the one GZDoom compiles with out of the box. Specifically, the textureSize and texelFetch functions require 1.30 and I believe GZDoom's shaders compile with version 1.10.
I should also be able to fudge with LODs and force my star textures to sample the lowest level mip with some tomfoolery. The effect of a starfield is destroyed in Space Station Omega when any of the mipmapping filters are turned on (none with nearest/linear mipmap; trilinear; anisotropic). So if I can be arsed, I'll whip up a shader for that. Be aware that you'll need to reimplement GZDoom's getTexel function if you want to try that yourself:
Code: Select all
vec4 getTexel(vec2 st)
{
vec4 texel = texture2D(tex, st);
#ifndef NO_TEXTUREMODE
//
// Apply texture modes
//
if (texturemode == 2)
{
texel.a = 1.0;
}
else if (texturemode == 1)
{
texel.rgb = vec3(1.0,1.0,1.0);
}
#endif
return desaturate(texel);
}
Code: Select all
vec4 unalteredSample = texelFetch2D(tex, texCoord, 0);
EDIT 2: Alright. Scratch that. You can't have some of those functions because you need to have a greater shader version than the one GZDoom compiles with out of the box. Specifically, the textureSize and texelFetch functions require 1.30 and I believe GZDoom's shaders compile with version 1.10.
Re: [WIP] Prime Directive - seeking willing testers
Actually, looking even more at the shaders... they make me cry. There's if branches EVERYWHERE. And if there's one thing you do to slow down your shaders, it's implement an if.
GPU hardware isn't as clever as you think it is. It goes through and executes a program. There is no branching logic in this pipeline. But how do if statements work? It's simple - the shader executes once for every possible permutation of your shader's execution flow and merges the results afterwards. A shader with one if statement will execute twice. A shader with two if statements will execute four times. A shader with three if statements will execute eight times. And so on and so on in power-of-two increments.
I'd almost rather no one used some of those uniforms that I exposed until someone goes through and rewrites the shader system. Because once someone starts checking those boolean values in a released mod, any change to the shaders break backwards compatability.
GPU hardware isn't as clever as you think it is. It goes through and executes a program. There is no branching logic in this pipeline. But how do if statements work? It's simple - the shader executes once for every possible permutation of your shader's execution flow and merges the results afterwards. A shader with one if statement will execute twice. A shader with two if statements will execute four times. A shader with three if statements will execute eight times. And so on and so on in power-of-two increments.
I'd almost rather no one used some of those uniforms that I exposed until someone goes through and rewrites the shader system. Because once someone starts checking those boolean values in a released mod, any change to the shaders break backwards compatability.
Re: [WIP] Prime Directive - seeking willing testers
Development Diary #5
Well. Rather than working on Prime Directive yesterday, I went and got tri-directional 3D floors working on a tech demo WAD (with the exception of being unable to walk under them). And then today, faced with two days at home thanks to a chest virus, I experimented on it some more after a realisation or two and expanded the tech demo to have tri-directional floors you could walk under as well as ride. I'm still not happy with it, as it can be desynchronised. But it's a very solid start for a long-standing problem in the Doom community.
Tomorrow I'll be doing some work from home while sick. I have a lot of work to do. Masochist? Maybe. But the stuff I'm doing has been of deep interest to me for a number of years.
I did whitebox out one of the last remaining objectives for Prime Directive though. It involved going a bit silly with 3D floors, but it's in there and the end goal is working now. Once I get the barracks and administration out, I can put in the flow for the entire hub and have it completable. It won't be at an alpha stage at that point, as the "feature complete" part won't be anywhere near fulfilled. But it'll be ripe for testers to look at.
I worked on one of the first truly winnable battles as a bit of a reward tonight. Dem marines. It forces you to play Doom differently. A few bits of geometry here and there turn an unwinnable/unfair battle in to something that's challenging and taxes your brain out of its Doom-y comfort zone. I don't think this project will be quite like anything else out there.
Well. Rather than working on Prime Directive yesterday, I went and got tri-directional 3D floors working on a tech demo WAD (with the exception of being unable to walk under them). And then today, faced with two days at home thanks to a chest virus, I experimented on it some more after a realisation or two and expanded the tech demo to have tri-directional floors you could walk under as well as ride. I'm still not happy with it, as it can be desynchronised. But it's a very solid start for a long-standing problem in the Doom community.
Tomorrow I'll be doing some work from home while sick. I have a lot of work to do. Masochist? Maybe. But the stuff I'm doing has been of deep interest to me for a number of years.
I did whitebox out one of the last remaining objectives for Prime Directive though. It involved going a bit silly with 3D floors, but it's in there and the end goal is working now. Once I get the barracks and administration out, I can put in the flow for the entire hub and have it completable. It won't be at an alpha stage at that point, as the "feature complete" part won't be anywhere near fulfilled. But it'll be ripe for testers to look at.
I worked on one of the first truly winnable battles as a bit of a reward tonight. Dem marines. It forces you to play Doom differently. A few bits of geometry here and there turn an unwinnable/unfair battle in to something that's challenging and taxes your brain out of its Doom-y comfort zone. I don't think this project will be quite like anything else out there.
Re: [WIP] Prime Directive - SECOND ROUND PRE-ALPHA TESTING
SECOND ROUND OF PRE-ALPHA TESTING IS READY

The development schedule is slipping slightly. I haven't quite finished whiteboxing everything, and frankly it's because I just couldn't get inspiration for the marine barracks section. Which has held me up somewhat. I've done something with it now, and it's not a complete waste of space. So there's that.
The flow up to obtaining the red key is finally in. This only leaves two critical sections before the final part of the mod - namely, administration and the power generators. I still haven't started on the warehouse level, but it's going to be a side mission and probably the best marine battle in the mapset.
I've sent out information for the new test package to the current testers. But hey, fear not. If you find this mapset interesting (which, being the sequel to Space Station Omega, should make it of interest to a few of you) then drop me a line and I'll include you in on the testing.

The development schedule is slipping slightly. I haven't quite finished whiteboxing everything, and frankly it's because I just couldn't get inspiration for the marine barracks section. Which has held me up somewhat. I've done something with it now, and it's not a complete waste of space. So there's that.
The flow up to obtaining the red key is finally in. This only leaves two critical sections before the final part of the mod - namely, administration and the power generators. I still haven't started on the warehouse level, but it's going to be a side mission and probably the best marine battle in the mapset.
I've sent out information for the new test package to the current testers. But hey, fear not. If you find this mapset interesting (which, being the sequel to Space Station Omega, should make it of interest to a few of you) then drop me a line and I'll include you in on the testing.