It feels like it's been a lot longer than a month since I last wrote one of these! Working from home has dragged into it's 6th month now for me. Maybe it's that, maybe it's looking back over the list of things I did and it appearing long. Spoiler Alert: It was pretty epic.

Recap

The things that I wanted to accomplish over the last month:

• Apply text injection to the active projects widgets display name.
• Move starship construction costs from the project data to the starship data.
• Allow transaction inputs to contribute to a project's duration.
• Write a couple console command utilities to help with iteration.
• Get started on a new starship config UI as a super-stretch goal.

Results

Like I spoiled above, it was pretty epic. I got a ton of stuff done in addition to the stuff that I planned and that feels great (especially after “falling behind” in May/June). However it's a little mixed because I wonder if I underestimated the tasks, underestimated how much time I'd have to devote, or spent time I just have spent doing something else. I suppose I'm not really worried that I could have been doing something else, there still aren't a lot of “out” options due to Covid. The estimation problems bother me a little more, but I think I underestimated available time and not the tasks and I'm more okay with that then the reverse.

Text Injection

Done, but nothing particularly interesting to report. My July update covers how text injection works if you didn't see that already.

Construction Costs

Here you can see the starship class definition with with construction costs. The interesting part here was the addition of a new strategy pattern to the resource parameter to allow adjusting a resource cost in some way. The first strategy I added was one that could add construction costs from any definition that was “construct-able” (as defined by a new interface).

Project Duration

You may notice in the those construction resources that a “Time” resource is one of the costs. This was part of the goal to allow transaction parameters (in this case a resource input) could contribute to a projects duration. That involved creating a specifically type of new resource type for “Time”. That one above is “Time_Day”, but I also made ones for hours, months and years. I also created a structure that combines a float with one of those resource definitions to define a duration. Then the cool part is that what I ended up with is a conversion system that can take any duration and convert it from one time resource (say months) into another (say days). It's currently limited to a single chain of conversions: hours <> days <> months <> years. It doesn't support multiple conversion sources like weeks <> years without sticking it directly into the chain (say between days and months). It's also pretty specific to the new time type. I'd have to replicate it all if I wanted to do the same thing for distances or some other unit of measure. A part of me thinks that could be cool, even to the point of relational types (like velocity or pressure), but I don't actually need it so I shouldn't really build it (yet).

I also updated the repair action to contribute to the project duration. I also updated the project selection widget so that it can show the range of possible durations that may be possible.

Console Commands

Done, but again there's nothing that's all that interesting to report

Starship Config

Here's the new screen for updating the configuration of the starships. To the left, is the schematic of the ship with buttons for all the slot locations that are available for placing weapons. The right side starts with a drop-down for selecting when ship to modify and a text box if the player would like to rename it. Next down the left side is a preview of the firing arc for the weapon slot when one of the slots is moused over or was the last one clicked. Next are some spaces to show information about the weapon slot and the current equipment in the slot (or that is currently being equipped). The right side will be the available weapons that could be equipped.

It took me a little while to get the widget for the schematic of the ship showing up correctly. UE4's UI designer is pretty neat, but it's not particularly convenient when dealing with dynamically created widgets. It took me even longer to get the arc preview widget working. Actually, the widget I got working pretty quickly it was the using the widget from this screen that was a problem. Eventually I got a little be of help from a UI expert at work.

Epic Stretch Accomplishments

• Blueprint Filenames
  • I hadn't been very diligent with names for my blueprints. Well, more accurately the names were fine, but they didn't have appropriate suffixes. Generally _BP is the established suffix for blueprints and _WBP is the suffix used for blueprints of UI widgets. I've also added _SBP for the blueprints that derive from my specialized widget I use as the base for all my screens.
• Utility for Interface casting arrays
  • Unreal has a really interesting utility for allow casting between arrays (templated containers) which is normally prevented by the C++ type system. It functions similarly to a reinterpret cast and is super handy when dealing with arrays of UObject pointers. It's generally come in handy acting as a const_cast to get information back and forth to blueprint ('cause blueprint isn't great with const pointers). Unfortunately it isn't a good idea at all to use it with interfaces which are a tool I'm coming to rely more and more on. So I wrote my own utility that can do that casting safely.
• Convert resource transactions from derived types to strategies
  • I already covered with construction costs the new strategy I created for resource parameters to be able to modify the resource amount referred to by the parameter. I already had a couple of other parameters that derived from the resource parameter so I removed those and re-implemented them as strategies instead.
• Damage Modifier strategies
  • The strategies worked out so well for the resource parameters that I decided to modify the damage effect to use the same pattern for some of it's calculation. Previously the damage effect had two members that could 1) scale the damage by the amount of ammunition available and 2) scale the damage based on the distance between the source and target.
• Main Menu
  • Created a new map and various UE bits and bobs for a new game mode meant to support a main menu.

• Pause Menu
  • I also created the a screen and framework for a pause menu. This included a system for my UI screens to deal with input. I wired it all up in strategy and tactical so that a pause menu UI can come up and be dismissed with the “Esc” button.

• Redscreens
  • Another UI element. This one related to error detection and handling. Not every problem can be handled as an assert or as a log message. Both my previous job and my current one have the notion of a “redscreen” which allow for the display of configuration problems as they are encountered. These are more serious than just a log message, but less serious than an assert (or in UE4, ensure). They show up (with a fairly annoying overlay) and then go away after a time. They also get written to the log for posterity so that it's easy to get them again at the end of the play session. Come to think of it, I should add it to the MapCheck output too so that it pops up after PIE as well.

• User Settings
  • Unsurprisingly UE4 has a data structure designed for saving user configuration data. While working on the pause menu I started thinking about user configuration. I don't really have any options yet, but at least I've got the place to put them when I do.

September '20 Goals

• Starship Config UI Implementation
  • Since I was able to put together the layout for the new config UI, the main goal for this sprint will be the functional implementation. I've already started on some of that functionality.
• Dialog Boxes
  • In addition to screens which are intended for self-contained functionality, another bit UI element feature are dialog boxes to bring up more temporary elements to affect whatever process invoked it.
• Refactor project queue
  • I'd like to pull out the queue that is managing the active projects and turning it into its own data structure. The goal would be that research would also be projects and they shouldn't be processed in the same queue that is used by projects like ship construction, repair and (eventually) refitting.

This should be an interesting month though. On the one hand I'm expecting work to be a little more busy this month, so there might be some longer hours. On the other hand the last week of September I'm taking off as a vacation. Can't really go anywhere, but I won't be working so I'll have a good chunk of time then to work on my project.

Some cool news is that I've ordered myself a new laptop. The one I'm currently using is almost five years old and while it does a pretty good job, it's time for an upgrade. The last time I upgraded I was racing a clock and pending hard-drive failure so I'm looking forward to a more… sedate transfer process.