FMod - Foreground highlight

Yesterday, I made little headway in implementing a "front" highlight mode for the Tile Properties view. I realized today that the best approach - in terms of ease of implementation now and of maintainability later - is to have a per-tile overlay system in addition to the existing per-property system.

Every foreground tile now has a per-tile overlay computed for it when called for. Currently the only kind of markup that can go on those images is the foreground highlight. That highlight is a translucent silhouette that only covers the area covered by the foreground tile itself.

The highlight in action

FMod - Attempts at foreground highlight

Somebody mentioned that it would be helpful to have a mode that highlights "front" foreground tiles, i.e. those that always appear in front of Keen and sprites. It's extremely easy to put a constant overlay on such tiles, but that's not very helpful in visualizing what parts will definitely appear in front. The obvious approach would be to get the image of the tile being marked up and make a translucent constant-color version of it, but in the current architecture, the function that creates the overlay image doesn't know which tile it's working with, only its Abiathar Tile Property ID. Multiple tiles can have the same properties, so the cache and the code paths will need to be reworked for this to happen. I do think it's worthwhile, so I'll need to figure something out.

Constructing generic-typed objects in PowerShell

Suppose you wanted to use an object of a generic .NET type in PowerShell, e.g. Dictionary. You might look for an extra switch on New-Object to specify the generic type's specialization, but there isn't one. The correct way to do it in modern PowerShell versions is this:

New-Object 'System.Collections.Generic.Dictionary[string,int]'

You can use either the full .NET names or the short PowerShell type names for the type parameters. The square bracketed part here is equivalent to the angle-bracketed part in C#. Also note that the quotes around the type name are required; if they're missing, PowerShell will interpret the parameter as the value of the -ComObject switch.

Volunteering at an FTC League Championship

I spent today volunteering at the local FIRST Tech Challenge league's championship meet. My first role was Robot Inspector. Previously, I had been a Field Inspector, making sure the robots could operate on the field and connect wirelessly. My new job entailed making sure the robots were physically acceptable, e.g. sized appropriately and made out of allowed components. That was very easy given the checklist. We completed inspections ahead of schedule, except for one team that needed to adjust their robot a bit to pass.

Then, I worked as a Scorekeeper, which was completely new to me. I expected that I would be sitting by the field and keeping track of the scoring events, but Scorekeepers actually manage the computer systems in the play areas. My job was to operate the timer on one of the two fields. When the emcee counted down to the start of the match, I pushed the button to make the big timer display start ticking. That was also very easy to do once I learned to navigate the special software they have.

We finished the matches almost on schedule without any major mishaps.

Copying only directories in PowerShell

Suppose you wanted to copy only a directory structure, without the files inside. In PowerShell, you might try to use Get-ChildItem with the -Directory switch to get only directories, then pipe them into some script block that copies them. The trouble with that is that you need to compute the resulting path by replacing the source path component with the destination one, which is doable, but a little messy.

Unfortunately, Copy-Item has no -Directory switch. It does, however, have -Filter, which technically takes a string, but you can almost think of it as receiving a script block. In this case, -Filter {PSIsContainer -eq $true} solves the task, as does simply -Filter PSIsContainer. That variable is only true for containers: directories, in the case of file system objects.

Registry redirection and the WOW6432Node key

Like IO operations from 32-bit applications on System32 are redirected to SysWOW64, 32-bit programs accessing certain parts of the Registry are redirected to a different location. For example, operations on HKLM\Software will go to the equivalent path under HKLM\Software\WOW6432Node. There are some exceptions, where structures are shared between the two Registry views. MSDN has a list of affected locations.

If a Registry change in the normal parts only seems to affect some applications, you probably need to make it in the 32-bit section as well.

PowerShell's $ConfirmPreference

Some PowerShell cmdlets ask for confirmation before doing their work. (You can always ask for them to confirm by passing the -Confirm switch.) Clearly, different operations have different levels of possible damage, so it makes sense that PowerShell allows each cmdlet to declare a "confirm impact": None, Low, Medium, or High.

You can choose how impactful an operation should be before PowerShell prompts them for confirmation. The $ConfirmPreference variable can be set to one of those four values; confirmation will only be required for cmdlets with an impact higher than the preference.

To override the confirm preference to say "do not confirm this one action", pass -Confirm:$false.

Based on my Super User answer.