In my games I explicitly ask people not to drag & drop cards around the table. This is because doing so would not run any scripts these cards would require for installation or trashing, scripting such as updating MU totals, adding credits tokens and so on. So people insisting on manually dragging cards around ended up with false MUs, unfinished installations and so on.
However with some latest functionality of OCTGN, I’ve now managed to add code that can gracefully handle drag & drops. It works as following
Dragging your ID from your hand to the table, will initiate the game setup. This should be easier to remember than pressing ctrl+shift+s.
Dragging any card from hand to table, will attempt to install it. If you’re dragging corp cards, you have to keep shift pressed to place them face-down. Don’t complain to me if you forget!
Dragging any card out of the table will either trash it (if you place it in trash) or uninstall it (if you place it in hand or R&D/stack). This will take care of MU totals and attached cards as well
Dragging any card from Archives/R&D to the table, will check with you, if you want to play it at no cost. Pressing ‘No’ will just place the card on the table without triggering any scripts.
That said, even though drag & drop is now non-game breaking, I still strongly suggest you keep using the app the same way you’ve done until now. That is, just double-click (or press ‘del’ to trash). It’s both faster and less mistake-prone. Particularly because when manually dragging, the card first moves to its end location, and then all scripts fire, so if you do it by mistake (say you don’t have enough credits to play it), then you’ve just revealed the card to your opponent anyway. Using double-click would have prevented it before that.
Still, that should hopefully be more intuitive for many people and should certainly cut down on mistakes done when dragging cards around on the quick.
Alrighty, I’ve done another hefty update to the striking mechanism with 2.4.5.x
Now game will ask if you want to use Tactics or Unit Damage first if you have both and will announce the order they were used.
Game will now take into account if a unit has targeted strike, and will ignore non-participating targeted units if it doesn’t.
Game will now confirm with the player if they want to allow it to auto-target, in case they forgot to target units before they strike. This will attempt to figure out which units are valid targets and provide a selection window.
Pressing cancel on selecting units (or not using automatic discovery), will not put the tokens anywhere, allowing for manual placement.
Here’s how a strike from Yoda with 2 enhancements will appear on the log, after selecting to use unit damage first.
db0 strikes with Yoda for 4 Unit Damage on [‘Jedi in Hiding’: 1, ‘Secret Informant’: 2, “Twi’lek Loyalist”: 1], then 1 Tactics on [‘Luke Skywalker’: 1] and 4 Blast Damage on The Secret of Yavin 4.
Here’s how the same strike (but with tactics first this time) will appear if you didn’t select any targets and declined to auto-find them.
db0 strikes with Yoda for 1 Tactics, then 4 Unit Damage and 4 Blast Damage on The Secret of Yavin 4.
As you can see, you can use the latter as a more manual method, informing the amount but then manually placing the icons.
Also now that targeted strike has been implemented, targeting non-participating units with strikes which are not ‘Targeted’, will ignore them when placing damage tokens. This makes it easier to strike with units which have non-targeted Unit Damage & Tactics, but no opponent in the battle. In the past the damage token ended up on your targets outside of combat which was a bit annoying. Now it’s properly ignored.
I’ve just pushed live a new version that significantly improves the way strikes of units with a lot of combat icons work. Until now, when a unit had Unit Damage and Tactics icons, or more than 1 Tactics, the game couldn’t figure out where you wanted to assign the tokens. With the new system, the game will instead ask you which of the units you’ve targeted should take the unit damage and which ones the tactics, and you can even split the tactics as much as you want.
I’ve made short video to quickly show how this works.
Basically, just remember to always target the units you want to affect before you strike and everything should be easy enough after that. The only tricky situation might be when a unit has shields and you want to know if they’ll use their shield token from your damage before your tactics. I’m working on a system to automate shield using as well, but until that’s ready, just clarify things manually with your opponent before you strike as you would do anyway.
I don’t know if you’ve noticed lately that there’s far less annoying pop-ups appearing when you start the game or while you play. This is because I have now coded the game to only display such pop-ups only once, in the case you haven’t seen them before, not just in the current session, but in general.
For most of you, this means that you no longer have to press “OK” when you start your setup, unless there’s a new Message of the Day waiting for your attention. So don’t immediately dismiss the MOTD window when it appears now, read it because it will only appear once 😉
Another thing that was added is confirmation of league or tournament games based on the known running events. This works by checking if one of known league or tournament tags (e.g. “[BGG-L01]”) exist in your game name. If it finds it, then it will announce that this is going to be recorded as a league game. If you don’t see such a notification after setup, it means the game hasn’t recognised your match for a league. No worries, you can manually set this through the Game > (Un)Set as League match menu option. Simply select the League your match will belong and it will recorded accordingly in the stats.
In the same vein, if you hosted a league match but your opponent is not participating or you changed your mind, you can simply use the same option to set the game as a casual match, and it will be excluded from the aggregated league results.
Finally, one new change you’ll notice is that, as corp, your hand will now be shuffled just before each HQ access. This serves no functional difference but to serve as a sort of “placebo” for those who see patterns where none exist. Specifically I’m referring to the somewhat common impression many have that cards on the rightmost position of your hand tend to be picked more during HQ accesses.
If you’re under this impression yourself, I just ran a simulation of 500 random hand pulls and noted how many times each position was picked:
First run: [92, 106, 107, 111, 84]
Second Run: [126, 89, 90, 92, 103]
With 8 cards in hand: [59, 65, 63, 56, 64, 64, 68, 61]
OK, maybe it’s only a problem in actual multiplayer. Let’s try it in online
Corp: [102, 110, 85, 107, 96]
Runner: [98, 97, 100, 103, 102]
As you can see, the results are quite random over a significant range.
So why did I add the HQ randomizing? Well people keep seeing this pattern and as long as it happens, people are just going to keep bringing it up, so I felt like a harmless extra randomization should nip this in the bud, and look more authentic 🙂
There’s also a more subtle change about HQ accesses. Due to the way OCTGN works, there’s a small delay when a new card appears on the table, as your client fetches the card details from the server. This can sometimes take seconds. So what happened is that when the runner accessed a new card from HQ, it would have a slow but noticeable delay while it was fetching the card properties, whereas if the runner was grabbing a card they had seen before in HQ or R&D, they knew it was the same card.
This allowed a smart runner to tell if the corp was holding two copies of the same card, or if they were unlucky enough to be seeing the same card all the time. May not seem like much but in Netrunner information like this can be very, very valuable. It makes a difference for example if one can tell if the corp is holding 1 or 2 Scorched Earths, to give just the most obvious example.
I tried to combat in this in the past, but it seems it was still quite obvious, so what I’ve done now is introduce a very hard pause effect before every access (your OCTGN will appear literally frozen) for 1 second. Because these delays are concurrent, it seems that in my tests, this is enough to mask whether an accessed card is new or seen-before.
Of course if you notice you can still see a difference, let me know and I’ll try to tweak the delay to hide it better.
Due to the latest changes in the way that default actions for pile views behave, I was now able to implement something that should make shootouts proceed faster. From v3.2.5 onwards, you can now double click on a card while looking in the Draw Hand and the game will automatically discard it. If however you’ve targeted that card with shift-click, then double-clicking the card will also discard all other cards you’ve targeted in your draw hand and re-draw the same amount of cards from your deck.
This way you can quickly perform the draw bullet part of the shootout in a few clicks instead of having to drag each card to the discard pile and draw again. Simply target the cards you want to re-draw in ytour draw hand with shift+click and double click one of them, then simply double click (or press del) each card you want to discard until you go down to 5 cards and you’re ready to reveal.
People have been asking for a way to avoid using Stealth credits for other icebreakers, in order to reserve them for use by Dagger (and other future stealth-credits-only cards I guess). So now I’ve added a new menu in a card’s context menu which will mark a card as being “Reserved for Stealth”.
When a card is marked as such, it will receive a black highlight and from then on, its credits won’t be used for any normal cost reduction. It will only be used by Dagger (For now. It will also be used with card which work like Dagger when they come out in the future.)
And yes, I also fixed the bug where Dagger would use all Cloaks together 🙂
I’ve also fixed a nasty bug with Escher which allowed the Runner to silently peek at all the unrezzed ICE after jacking out from an Escher run.