Jump to content


  • Content Count

  • Joined

  • Last visited

About Freeptop

  • Rank

Recent Profile Visitors

609 profile views
  1. I'm probably wrong about this, but it would be interesting if those Y-Wings weren't actually "Resistance" Y-Wings, but were actually old BTL-A4 Y-Wings brought out of moth balls, because the Resistance is just as rag-tag as the old Rebellion was at this point. For one, it would explain why it doesn't really look any different, down to having been stripped-down. It would also fit with their not having the resources to build new ships, but instead have to scavenge what they can find.
  2. A dewback that threw off its rider and is holding the shock probe in its mouth! (Technically, a dewback with a rider would have 6 legs... )
  3. Note the full circle engine nacelles on the new version as well. The T-85 shares the half-circle nacelles of the T-70.
  4. The pilot is so talented, they don't need an existing weapon, they just make it work with whatever they have!
  5. Enjoy: https://www.fantasyflightgames.com/en/news/2019/8/13/pulling-the-strings/
  6. As it so happens, I'm a software engineer that works in robotics. We already see it 😆
  7. I took a look at the source code, and I think I realize what the problem is - it's a perception problem. In the real world, dice are randomized by causing them to roll - usually by rolling them across the palm of the hand, or throwing them, or by the use of tumbling dice towers or the use of cups to induce a rolling motion. That's not how Fly Casual does it. It randomizes the orientation of the dice, then simply drops them. There may or may not be rolling that occurs when they hit the surface. In the real world, if someone simply picked up the dice and dropped them, they would be asked to roll the dice properly, as simply dropping dice is not sufficient to randomize the results - it heavily favors orientations that are already at the top of the die when it is dropped. In Fly Casual, that's not really an issue - the orientation of the dice was already randomly selected prior to dropping them, so if they don't roll when they hit, they aren't any less random. But here's the thing - people are watching the dice roll or not roll, so they expect it to work the same way as it would in real life. When a die just drops and doesn't roll (which happens a lot on re-rolls, as the code drops the additional die right above the dice already on the table, which doesn't leave them room to actually roll), it appears to not be random. Combine this with some confirmation bias (we usually only check the stats when we're rolling lots of blanks), and that's why we see so many complaints about the bias of the dice. I can think of two ways to deal with the perception issue (which won't entirely eliminate the complaints, but it would at least reduce the appearance of a lack of randomness; I'm also not sure how easy or possible they are to do in Unity - I work in robotics, not game development!): 1. Turn off the animation of the dice, so you only show the final results. 2. Introduce a lateral motion to the dice when letting them go instead of just dropping them. This should cause them to roll across the table, especially when re-rolling. As a software engineer, I understand that this is likely to get a low priority, though. Functionally, there is no change, so why add something that could introduce new bugs? As an experienced software engineer, I'll point out that User Experience is important, even though it's frequently annoying for us non-UX folks
  8. Yeah, apparently the coffee didn't help today.
  9. In 1.0, the Raider had 8/6 Fore, and 8/4 Aft, so the total amount was 16 Hull, 10 Shields. This version is 20 Hull, 8 Shields, which is slightly more, but with the usual 2.0 policy of moving some shields to hull. That said, combining them is a bit significant, since it requires chewing through the total number of shields, and the shield auto-recover (x2!) is going to make a big difference in how hard they are to kill. For that matter, 2x actions makes it pretty easy to both focus and reinforce, if desired... I'm really curious to see how energy works with these things now... given everything else, I'm pretty much assuming that energy will allow additional attacks per turn, at the very least.
  10. I would assume that's what the "Turbolaser Battery" is for on the quick build card. I may be wrong, but I suspect that's a turret hardpoint.
  11. On the contrary, the moment the opponent said they needed to win to make the cut, any decision to concede is the result of collusion. Ethically, this is very dubious, at best. It's using the letter of the rules (and possibly not even that) in order to manipulate the system to your benefit, or to the benefit of friends. That's generally where ethics start looking side-eyed at decisions.
  12. They didn't join the Resistance, though. They just all banded together because they were all fleeing the First Order, and then ended up lost. Temporary alliances should not dictate factions. If they did, the Mandalorians would be part of the Rebel faction. If the Colossus pirates enter the game, they'll most likely be S&V.
  13. Neither Ion Cannon Turret nor Proton Torpedoes have a "Requires" box on them, though. Those are both cases of ignoring slots. They've never put the configuration for one ship on to another ship on a quick build card. Given that the other S-Foil ships already have s-foil configurations, and they put this one on at least two B-Wing quick builds, it's really stretching things to doubt that these new s-foils are for B-Wings.
  14. Quick builds ignore the slots on a ship (which can and sometimes do get changed), but they've never ignored the "Requires" portion of a card. It's not like any quick build ever put Servomotor S-Foils on a U-Wing, for instance. I suspect at least some of the quick builds were the result of slots being changed after it was too late to change printing, for example (Autothrusters being included in the Fang Fighter expansion comes to mind for this one).
  • Create New...