Jump to content

moppers

Members
  • Content Count

    164
  • Joined

  • Last visited

About moppers

  • Rank
    Member

Recent Profile Visitors

454 profile views
  1. When I sign out of the forum, even if I close and restart the browser, when I click Sign In, it automatically signs me in with the previous credentials. This is a problem for any sort of shared or public computer. I'm using Chrome.
  2. If you have alpha strike (triple Defender or better firepower) or you cannot catch Manaroo, kill Dengar first. If you do not have alpha strike, or if you can easily catch Manaroo (Dash + Engine), kill Manaroo first. Try to avoid shooting Dengar when he has arc, as that just gives him an extra shot. This means sometimes you do NOT attack.
  3. In your article, you don't rate seismic torpedo highly. The current world champion said seismic torpedoes were involved in at least 2 of his wins. They aren't completely terrible, and you sometimes do get short on points.
  4. Pfft if I can stay behind brobots I can stay behind u-wings. FCS brobots I assume? It's difficult to do that against a good advanced sensor brobot player. In the days when 4 unmodified red dice was actually good, that list was a good match against imperial aces. Four bases is considerably different to pass through than two brobots as it takes up much more space and it's something people don't really appreciate unless they were playing long ago and remember Lambda shuttle spam. Two Adv Sensor brobots will probably try to bump each other to park in front of you, thus it's only half the depth of a lambda diamond.
  5. The rule you quoted applies to upgrade card usage but the question was about Youngster's pilot ability. There's no written rule that defines how Youngster's ability works with the TIE/SF. Your answer is correct, but for the wrong reason. We know it does, but that's because of unwritten "tribal knowledge" commonly agreed by the player base. (FFG FAQed it for the TIE/FO and we therefore assume it's the same for the TIE/SF but it's not printed).
  6. The game isn't defined by its rules, but how the community (and FFG event judges) interpret them. People who play events are telling you that Youngster works with the Tie/SF because that's the way it's played. In your own game, you can do whatever you want, but in OP and almost everywhere else, the Tie/SF is a TIE for Youngster, and this not debatable. Sure, you're actually right in that the rules as written do not define it, but those bits of paper aren't the referee that's going to tell you that it's a Tie for Youngster, and eject you from the event if you keep telling him it isn't. They should FAQ it just for the sake of completeness.
  7. I'm happy so long as the pros and cons are properly explained. Sure, it's easier to write non-performance critical desktop applications in Java, C# or Node.js than it is in C++, but you lose a lot of control and performance, which means C# cannot replace C++ in certain domains. Hence I'd rather people list the pros and cons and let individuals figure out for themselves whether it suits their needs. If I wanted a cross-platform (desktop and mobile) app with a rich GUI, I might also consider using Unity Game Engine (which uses Mono) but you're not required to use C# for that. From my point of view dealing with developers in tech (as opposed to traditional computing environments like enterprise, industry or gamedev), the majority seem to use Mac OS as it has better compatibility with linux servers and developer tools than Windows does, and Ubuntu desktop occasionally throws weird problems with hardware. From my perspective in western Europe, the traditional computer is being replaced by the tablet. I have a friend who lives in a block of flats. Of the 6 flats in the block, 5 households have tablets and only 1 has a computer (in addition to tablets), which is used professionally for spreadsheets. This is a very small and specialised sample size so you should not read too much into it. Geeks and hobby game TOs are probably more likely than average to have a traditional computer.
  8. I really don't want to get into this but you wouldn't get away with that comment on a programmers forum, and I don't want OP, who claims to be a student, picking up opinion instead of knowledge. I believe you meant to say "alternative to" instead of "upgrade from" given that it's really hard to compare apples to oranges?
  9. There's no objective right way, but you've made a sensible choice using standard tools and you can't really be faulted for that.
  10. I don't think you're doing anything wrong. My philosophy is that if I compute a tournament result like this, I will save it. It's just more versatile and robust. It allows manual edits, and it's more able to resist breakage if the pairing system changes in some future version of the rules, it allows tools to process it more easily, etc. It's debatable what penalties should be associated with (the player, the round, both?) but they're still part of his database (I saw SQL queries in his code). I hope it's sqlite but I didn't check.
  11. You probably don't want to re-calculate ranking when you reload. Ranking is the sort of thing a TO might have to change manually, and then the changes won't be persisted across a reload. I would store it in the database. In all the years I've been doing this, I've had one local TO ask about manual modification. If you're going to do it, I think a database is excessive. Just add an MOVOffset value to the player if you need to manually change MOV. If you're trying to manually change anything else then you've made a much bigger mistake. So where is the player data stored, if not in the database? And how do you tell at which round the player was penalised? Using only a player adjust, you could not regenerate the event from the data.
  12. I can't tell exactly what you're saying, but you probably don't want to re-calculate ranking when you reload. Ranking is the sort of thing a TO might have to change manually, and then the changes won't be persisted across a reload. I would store it in the database. Apologies if I misunderstood your comment.
  13. Can you briefly talk about robustness? For example what would happen if players accidentally played the wrong opponent, or handed in the wrong results? Could the software handle the re-pairing, etc? Is the source code available? Cryodex is open source, while means I can at least check that it works and isn't doing anything naughty, or modify it for a custom event.
  14. Flamespeak's strategy post is correct. Trade runs for gold is the best strategy and has little variance. I'm not sure I agree on the fix, but I don't know how to fix it.
  15. 1) Larger hero pool. 2) PVP
×
×
  • Create New...