Thursday, 4 January 2018

Five Years of the TSN & Back in to Blogging...

This year, the TSN will celebrate five years since first starting. Over that five years, the TSN RP Community has run a duty shift almost every Saturday - quite an impressive feat! The other evening, I was discussing it with a couple of the officers and looking back through old blog posts. It occurred to me that it has been more than a year since I last posted about the TSN and other developments like the TSN Sandbox, so an aim for this year is to start up this blog again.

Originally, this blog was about documenting my character in the TSN RP Community, and adding in out-of-character posts about the group itself. With the website providing a place to post personal logs in-character, it seems that posting here in-character (unless I create some kind of link across) is fairly redundant. As a result, I think this blog is going to change to being more about the group and what we are up to. That way, anyone reading gets a view of what is going on and how active we are. There has been a lot happen in the group over the past year, and to try and recap it would take time. Instead then, I am going to start fresh and focus on this year. As we are starting a new season in the TSN as well, it makes great sense to cover that and dip back into some key things from the past year or so as they occur.

After standing down for two shifts over the Christmas period, the TSN RP Community is all set to get back to active shifts on the 6th Jan. The two weeks without a shift has given time to be able to tie up all the lose ends for the new Season 9 story arc. This is set to be one of the most well prepared and organised seasons run, with a new mod, updates to the TSN Sandbox and extensive planning of the story arc. Matsiyan, now head of the GM team, has been chief in bringing everything together. He's worked tirelessly and brought together different skills from different officers across the group in order to get everything set for the new season. Matsiyan and I have also worked closely together to plan out the story for the season and the key events. As part of the planning, we have broken down the season into "Episodes", drawing the idea from the way a story is covered in a TV series. Each episode will span a couple of shifts, with all the missions linked to the key events within the episode. By doing this, the aim is to give a clearer path through the season in terms of the story, with the ideas sketched out and key events planned. The episodes still leave a lot of flexibility to adapt and change the story as it progresses, with each episode being tweaked and finalised before it begins, based on new ideas or changes to current ideas. The whole story itself has spun out of ideas proposed by the GM team - a mirror universe story arc which sees the 4th Light Division flung into a parallel universe and trying to figure out how to get home.

Having this approached has really helped to focus building in some key features to the TSN Sandbox too, which is now on version 7. I'll have to do a whole different post about the Sandbox as there has been so many developments with it, particularly over the past month or so. Setting things up for the season has been much easier having an overall plan though. Again, Matsiyan and I spent time looking through the maps and adding or adapting them to link with the story.

Season 9 is set to be brilliant though. At the end of Season 8, the 4th Light Division was tasked with joining ONI (Office of Navel Intelligence) ships on a top secret mission to activate artefacts that had been located throughout Season 8. After they were activated, the Division transited back, but what should have been a routine jump back to USFP space went completely wrong and the Division was thrown across space into a parallel universe.

Now the Division is completely lost. Sensors are offline, navigational systems unavailable, and the ships are severely damaged. During the transit, not only did the space outside change, but everything changed - from the ships themselves to the uniforms the officers are wearing. Adrift and lost, the officers are now working tirelessly to figure out what went wrong, where they are and how to get back.

Friday, 5 August 2016

Bug Fixing: TSN Sandbox V4

Today has been a day of bug fixing. After taking some time off tinkering with the Sandbox, I decided today to get back to work with it and take a look at fixing some of the bugs. The two on the list today - the Progress Indicator and supply ships.

The first has been relatively easy to fix. A couple of variables added and some code enabled and the timers and progress indicators seem to work fine. The GM now has the ability to set a timer from 1s all the way to 5 minutes and 59 seconds. When they start the timer, a small indicator appears in the top right of the map and shows a percentage that increases gradually, reaching 100% when the timer is finished. It is something the GMs have wanted in the TSN RP Community to show the progress of mission events like data uploads or downloads or marine boarding actions, as well as other ideas.

The much trickier problem to solve has been the supply ship code. Within the Sandbox, GMs can spawn two "Auxiliary" ships which can resupply player ships with ordnance. One is a light supply ship with stocks of ECMs and homing torpedoes, whereas the other is a normal supply ship with all ordnance bar P-Shock torpedoes. The problem though was they never seemed to resupply a ship that came within range. After combing through the code numerous times, as well as refining it further, I have finally managed to get it working! Now, when a player ship comes within 600 units of a supply ship and slows to less than 80% impulse speed, the supply ship beings transfer torpedoes up to the player ship's maximum limit. It all links in with some changes I made about a month ago to measure the maximum load of torpedoes on a player ship and it seems to be working.... FINALLY! I am yet to give it a full and thorough testing (the shift on Saturday will be when it can be really tested), but I am pretty certain now I have managed to fix the issue. It all boiled down to this: <. The one little sign that was the wrong way around. There were a couple of other bits that needed fixing, but ultimately it was a simple mathematical symbol!

Now that those bugs are corrected and things seem to be functioning properly again, I think I am going to return to creating systems and new features. The "Fighter" mode for the script still needs some work on it. I am still figuring out the details about how to implement it. For example, how should the players select the system and sector to start in? Should the carrier be stationary or move around with comms orders, like a comms officer directing an ally? Should it be a fully GM controlled mode? 

There are a couple of other modes I want to work on too. The "Patrol" mode is working fine, but can easily be expanded upon and improved further. I also have the "Pirate" mode, perhaps one of the more exciting developments. The Pirate mode puts the player in the role of a pirate or mercenary crew from the Euphini expanse, rather than a TSN crew. It is still possible to explore all the systems in the Sandbox, but all the TSN and USFP bases are enemies. I wanted to add some kind of "plunder" system too, so that the crew could receive some kind of money or reward when attacking ships and I have a couple of ideas how to do this. I was thinking that several 'trackers' on the science screen would work to give crews an idea of how many resources that they have stolen. What I need to figure out is how best to code stealing the resource. There needs to be some kind of random spawn when an enemy ship is wrecked, like anomalies. The Pirate mode links in with the Patrol mode as they both use the "Random spawn" code to spawn in enemies and allies so I can probably work on both at the same time. 

Anyway, that is all for now. Hopefully I can get an update released soon. The last release included a "Vanilla" version which didn't require a mod. It took time to create and I doubt I will release another vanilla version. Instead, I am going to focus on the TSN RP version, with a quick change to the ship names for the normal release. To really get the full effect of the Sandbox, it needs to be played with the mod. Without it, there are so many functions lost!

Sunday, 1 May 2016

New Release: TSN Sandbox V4 with GUI and Vanilla version

Well, the other night I went ahead and made a public release of the TSN Sandbox V4. Over the past couple of weeks, I have been finishing up the GM menus and giving the Sandbox a test. I have taken the opportunity to GM a couple of missions for the TSN RP Community due to a twist in the story that saw me "presumed dead" for a short period. This freed me up to really try out the Sandbox and the new menus. 

The addition of the GM GUI is, frankly, awesome. It is a complete game changer (pardon the pun) when it comes to being GM. They've been incredibly easy to add in to the Sandbox mission script, and really do make GMing possible for virtually anyone with an idea for a mission. Before, trying to GM a mission meant having to read through a key reference guide and then almost memorise the different key presses. I had tried making it easier using some generic meshes in the top corner as a reference of which menu was selected, but it never was particularly easy to use. Now, with menus in plain English, it is a simple matter of point and click! 

There are a few more things I need to finish up for the GM controls, but the majority are finished and give a huge range of things that GMs can do, from spawning new terrain, some of the creatures, to spawning enemy fleets, and special "pick-ups" like lifepods and black boxes. Most of the code was simply used from the previous Sandbox version, with the main difference being the addition of the menu buttons. The final part of the main menu system I am working on is the "Interactions" menu. This will give GMs different options to directly affect the player's ship. So far I have added in options to; repair or damage all the different ship systems, like primary beams, sensors and maneuvering; add or remove 100 units of energy at a time; add or remove one piece of ordnance at a time; add or remove damcon teams; and send pre-scripted messages. I am still finalising how the sub-menus are set up - I am thinking of using the same set up as the "Enemy" menus where a drop down select is enabled and disabled.  

With this release of the TSN Sandbox, it was also suggested releasing a "Vanilla" version, that worked without the TSN Expansion mod. With a couple of hours work, I was able to change or remove the code linked with the expansion, and so release a version that will work with the standard Artemis 2.4.0 game. I haven't removed the menus linked with the Expansion, instead I have just deactived the events linked to the button presses. Hopefully, with the ability to access the TSN Sandbox on the standard Artemis game and see all the additional options for alien races, it will inspire people to try out the TSN Expansion. I have packaged the whole thing together into one zip file so it is all there and ready to go in case players try it. The work that has gone in to the TSN Expansion is awesome. It really does enhance the game massively and I think it is something that players would love. 

Anyway, that is all for now. After finishing the "Interations" menu, the next main focus is expanding on the systems within the sandbox. USFP space is now quite extensive - Krisenda system was recently added - so I am going to focus on creating several neutral systems around Hjorden and expanding the enemy systems. The Stellar Cartography maps are all completely up to date and show how extensive the space is already! Feel free to check them out:




Wednesday, 30 March 2016

TSN Sandbox and new GM GUI

Over the past couple of days, I have had chance to add more systems to the TSN Sandbox. After talking with Evans, I decided to focus on creating the Volantis system and Waypoint 52. Both were straightforward to add in, and only took a couple of hours work. No doubt there will be some bug I have missed, but after a little testing, I managed to iron out a few issues - mainly transition problems where I had missed renaming a variable.

With these two new systems added, it completes a loop though USFP controlled space. Now crews can set out on a patrol flight and visit several sectors in turn in a complete circuit. This was the main reason for focusing on these two systems. Next, I want to add in some more things to encounter in the patrol mode so that ships can set out on patrol with a GM and have to handle various enemies or situations. I was thinking of adding in some "suspicious" ships - cargo vessels behaving strangely or with strange readings when scanned. These would have to be then intercepted and dealt with by crews on their patrol. I was also thinking of increasing the presence of pirates across all systems so that players are bound to come in to contact with something as they transit USFP space. A patrol may only see one or two contacts, but potentially could come across many more if out for a longer period of time. Combined with the suspect vessels, it should add enough variety for patrols.

There have been a couple of suggestions on the Artemis forums about functions to add to the GM keys. One I am definitely going to look in to is the ability to switch between GM mode and Patrol mode during the mission. There are a few more keys to add in with new enemies from the TSN Expansion too. I was also thinking of something else I could do with the GM console, but don't want to go into that at the moment; it is just an idea, but one that could really be an exciting and engaging addition for crews. 

All this is plans for the future however. I am holding off on doing anything with the GM keys until the release of the new GM GUI that is being added. When it is available, I am going to overhaul all the GM keys so that they use the new menus. I know the changes are really going to make a massive difference to the Sandbox in terms of its usability and personally I cannot wait until I can get started upgrading the sandbox code. 

Other new mission script code that will make a difference and be added when available will be the ship name code. It will allow me to set the ship names in the script, no longer requiring the player to change the names. Both of the additions to the mission script code will make the sandbox much more user friendly and easy to access.

That's all for now!

Sunday, 22 November 2015

Personal Log - 231115-2236

The Cerberus campaign is finally over, and we've returned to the Promethean system. Its good to be home.

My quarters are just as I had left them. There was no need to take much with me, though it is not like I have a lot to move; a couple of dress uniforms, stationary, this place is pretty spartan. Its how I like it though.

The sight of shuttles and transports buzzing back and forth through the view screen is comforting. I can almost forget the last few months... so many good officers and crew lost... All told, we lost 137 personnel from our division. Looking through those lists of names, sending letters of condolence to relatives, it never becomes routine.

Now that we're back, the engineers are giving all the division ships a complete overhaul and repair. We can finally fix the combat damage properly, rather than the temporary patches we've had to make. The hulls of the Raven is pretty battered and the number of patches and bypasses to systems is pretty high. I am glad I've got the chance to get her to space dock and fixed up.

There has been some talk from engineering about trial runs with new energy systems too. Something about refinement of the denabite crystals or fusion power exchange manifolds or some such. If everything works as it does in the sims, the power plants on the division ships will be significantly more effective. Of course, there's a big jump between controlled sims in the lab and actual live test runs.

Were back to a fairly normal routine now. Command wants the division to pick up the patrols in the Cronus system again. According to intel reports, the hegemony presence across their border regions has been slowly building. There are reports of several resupply bases being constructed in Erebus system and few of the hegemony patrols have been sighted in the Cronus system. At the moment, we are getting more bother from pirates in Cronus, with hegemony forces not straying far from their own gate. Right now, its not too much to be concerned about though, just a situation to monitor.

Anyway, that's all for now. There is a stack of inspection reports to get through and repairs to authorise. Time to get back to work.

--End Personal Log--

Updates on the TSN Sandbox

I've picked up work on the TSN Sandbox again. I am trying to get into a routine of adding features, though finding the time is the main barrier to working on it. Yesterday, I was able to work on it for several hours, and fixed some issues that needed addressing. 

The patrol mode has been tested a couple of times by the crew of the TSN Raven now and is working as expected. There was a major issue with pirates just not attacking, which I've now managed to fix. It took some work, and required stripping back and rebuilding each pirate's AI commands, but now they will hunt a player down when you enter the sector. 

I'm not sure that I have posted an update here about the patrol mode. I had tried something similar in a previous version of the Sandbox, but found it too cumbersome to build in. After letting the idea stew for a period, I finally thought up of a way to integrate it within the new Sandbox. Basically, the code for spawning and setting AI is all isolated from the rest of the sandbox code, and then triggers in a particular sector activate it. I used a couple of variables cycling to randomly pick numbers and drew on them to set up coordinates as well as spawn chance. I have tweaked the spawn chance to get a decent balance, and think I have managed to get something that is acceptable. 

Within the Sandbox, there are the pirates, kraliens, mixed hegemony fleets, heavier carrier fleets and command fleets. Different enemies can be encountered in different systems and sectors, and where those enemies spawn can be tailored. For example, enemies might spawn nearer a particular sector edge, such a pirates raiding into Cerberus sector 1 & 5, or might spawn at any random location in the sector, such as enemies in their own system. The next phase will be adding in more badlands and then adding in the Unakalhai and N'Tani to roam through them. There was also a request to add in some allied ships too, so I will look into that. I'd like to create some that have small missions built in, for example some with distress calls similar to what would be found in a normal solo or coop game, or some transport missions, picking up supplies. 

Now that it is part of the Sandbox, in testing the TSN Raven has been running patrol simulations (we are still testing so don't want to make them 'proper missions' in case the script breaks) and search and destroy simulations into the Cronus and Erebus systems. Last night in our shift, we entered Erebus to hunt down and destroy enemy command fleets in order to disrupt their operations. The command fleets are small fleets of 3 or 4 ships, one of which is a special command ship (3000+ shields front and back) guarded by two or three other heavy ships (e.g leviathans, goliaths or carriers). For a single ship, they are pretty tough nuts to crack, and usually by the end of the combat, a lot of ordnance has been expended. 

With these kinds of missions though, there has been an issue with the amount of time it takes to get places. Travelling at warp 1 all the way to the Erebus system takes ages, and often a ship has to stop and refuel multiple times on the way, particularly if the engage any enemies along the way. As a result, I've started exploring options on how to address the problem. There were a few different ideas that I was looking in to. One very simple idea was to give ships an infinite amount of energy, but in testing it just didn't feel right. Another option was to increase the energy gained from the FCS to reduce the amount of time refueling, but I felt this wouldn't combat the problem of having to stop frequently or travelling at warp 1. I opened up the discussion on the TSN forums and got a couple of ideas - advanced refuel point to gather supplies, a supply ship, special short cuts to systems, increasing ship's energy reserves - all were ideas suggested. One though was changing the efficiency of systems, something I think someone had mentioned a few months ago. So, I've started experimenting.

In the first trial, we just changed all system's efficiency to 1. In that test, the ships could move around at war 3 & 4 with little issue. At warp 1, no power was used at all, at warp 2, it was used 1 unit over several seconds. Warp 3 & 4 used energy at a much slower rate, but one that was noticeable.  The next change lowered warp, impulse and maneouvre, but increased sensors, primary beams and torpedo systems. Shield were kept the same. In the trails with the TSN Raven, we could use warp 3 to get to Erebus system, crossing 7 or 8 sectors and using about 1/2 our energy reserves, and then attack a couple of enemy fleets before needing to stop to collect more fuel. We found that rather than having to manage energy, we were having to manage ordnance, heat on systems, damage, much more. The engineer reported that without the "downtime" provided by the fuel collection mode, they had to work harder to actually cool and manage systems, and in one of the first simulations, we actually had to abandon ship as we had taken damage to maneouvre systems and lost all damcon teams. 

That is all for now. It has been quite a while since I updated this blog. For the most up-to-date information about the Sandbox, I post regularly on the Artemis forums, so check out the thread. You can download it there too! Oh, and I almost forgot, check out the Stellar Cartography too. It is an interactive map for the sandbox which can be used on any device. It makes for a pretty cool map tool to help navigate around the systems and sectors.


Wednesday, 7 October 2015

Battle Doctrine

Recently, I have been thinking about some of the strategies and tactics we utilise during GM mission. After a simulation or mission, crews usually debrief then the commanding officers meet briefly to review how the mission went. This often generates discussion and ideas about new tactics and strategies and there is a lot of reflection on the performance of the Division. There is also generally at lot of discussion before and after the shift between the senior officers. As a result, we are constantly tweaking and adapting how we play and making changes and improvements.

A couple of recent discussions and some reading of documents highlighted to me that, though we have developed pretty clear ways of dealing with different situations, tackling enemies and deployments of ships, we have very little reference material or records. Though we have combat orders and fleet attack patterns, there is no guide on when to use them, how they might be adapted, and no guidance either on how to coordinate battle groups and adapt to different situations. We have no document outlining our Battle Doctrine.

Battles doctrine is a term I've heard of before a long time ago, but reading a document recently brought it back to the forefront of my mind. A quick bit of research into the actual definition and usage of the term convinced me it was the thing I have been looking for. Rather than defining what to do in detail, battle doctrine are the guidelines of how to conduct actions, however are not hard and fast rules. As a result,  they don't restrict you to a course of actions,  rather they outline current thinking and approaches to provide ideas on what to do in certain situations. With this in mind, I have started a document to record our current battle doctrines.

The first part I have been recording is our use of scout ships acting as part of a battle group. Over the past few weeks, our campaign has prompted us to establish a new doctrine of using scouts to break up a particular type of enemy formation. This has been what I will describe as a 'Command formation'. In basic term, it has been a group of 3 Torgoth heavies, with massively boosted shields (3000+ in strength) escorted by up to 4 heavy Skaraan vessels,  equipped with anti-torp/mine abilities (as well as several other elite abilities) and again, massively boosted shield (3000+). A single ship would find it impossible to tackle the formation, and it has takes the combined strength and coordination of all ships. The approach, although not new in game terms, had to be more clearly outlined, with the scouts carefully coordinating to lure the Skaraans away, and keep them distracted,  whilst a battle group attacked the Torgoths with repeated bombardments and firing passes until they were destroyed. With the Torgoths destroyed, the Skaraans often leave the battle space.

There are a whole host of other things I want to include, such as when it would be more advantageous to divide ships and when to keep them together. We've also started deploying other ship types, namely a missile cruiser (a modded 'mk2' varient with a close range beam with just enough power to destroy a drone), and this is likely to spark a lot of new doctrine.

Personal Reflections
Whilst writing our new doctrines, I thought about how we do not follow certain ways of thinking. The main one that always used to cause debate was dragging monsters to enemy formations to more effectively destroy them. There are a couple of other things we don't utilise too, or things we do, like providing close escort, that make it more challenging or some may say, makes us less effective in combat. One such situation would be having a ship escort an ally by remaining within 8K rather than combating nearby enemies.

Justifying this to some has always been difficult. A simple thought occurred to me though. There are many who play the game. By that, I mean they search out all the best ways to defeat the hardest levels. All the tactics, tricks and quirks that mean you can defeat co-op and solo games on the highest difficulty settings. I have nothing against people or groups that want to do this. I'm impressed at the research and effort that people put in to this, now and in the past. I've never looked or intended to do this with the TSN RP Community though. The group's aims have never been to play at the highest possible level (level 11 at 300%). We aim instead to create stories, roleplay, to act and behave as TSN officers. It's not about playing the game, but taking part in the story. As a result, our battle doctrine is going to reflect that.

Often, when we've created stuff, we've shared it with the wider Artemis community. Some has been taken and used by others, which is always rewarding to see as we feel like we've made a contribution. There have been times when we have been met with critisism, and sometimes open hostility. I've been caught up with this in the past, trying to defend my position, and fending off insults and critisism seemingly designed to portray us in a particularly bad way. Its only been a vocal few, but it is still damaging to us as a group and personally too. I realise now though, that what we do is for us. If others adopt it, or think it's good, than that is great. But we never force our content on others, and if people don't like it, well who cares, it was made for us.

From a personal point of view, I am starting to share less and less with the wider community. The newest Sandbox is an example. I'm writing it for the TSN RP, and we've been using it for a while now but I've not shared it with the wider community because I've realised, I don't need to (I put out a poll as to who wanted it, felt stung at getting one response, and now realise I shouldn't be and don't really care!) It is all for us; our group; the TSN RP Community players!

For me, it's been quite liberating to feel like I am doing things for the group of people I play with. I know people in our group all appreciate the effort that everyone goes to: in creating a mod; designing and running missions; creating medals and awards; organising the night; running the teamspeak; having a website.... I feel like a weight has been lifted; I no longer feel like I have to compete with others or justify ideas, or see someone take them and critisise and 'improve' them. This is going to enable me to write this battle doctrine without feeling any anxiety over how it might be accepted by others outside the TSN.

I think it also highlights to me how cohesive and cooperative the leadership team of the TSN is as well. I feel confident that we have a shared vision and understanding of the direction we are taking and I respect the opinions and feedback of those in the leadership team.