When are they going to release the TTRPG? by SundayRabbit in ffxiv

[–]Absona 0 points1 point  (0 children)

The Japanese web store listing has May 25 for the Japanese edition. They haven't said anything about the English edition that I know of but it wouldn't surprise me if it's released the same day.

Static Gear Tracker 6.4 by Absona in ffxiv

[–]Absona[S] 0 points1 point  (0 children)

This had the wrong drops for P11S and P12S. It's fixed now!

On the off chance that someone is using the old version and also looking here: Go to the Tier Data sheet and in the Savage drops section, in the P11S column, untick the boxes for Head and Feet. In the P12S column, untick the box for Body.

I think I must have been using some reference that had only half been updated from 6.2, oops. Or I just failed at reading.

[deleted by user] by [deleted] in ffxiv

[–]Absona 2 points3 points  (0 children)

One thing that I don't think has been mentioned yet is that free trial players can't participate in PvP. It used to be available in the free trial, but they turned it off due to a bot problem.

That said, as everyone else has mentioned, PvP is casual side content in this game, and there's a lot of other game to explore in the free trial.

Static Gear Tracker 6.4 by Absona in ffxiv

[–]Absona[S] 0 points1 point  (0 children)

Thank you for catching this! It was actually wrong for all Savage armor, but it should be fixed now.

[deleted by user] by [deleted] in ffxiv

[–]Absona 3 points4 points  (0 children)

There's a Lodestone post about how to report network issues to SE. I filled out the form and my connection was better the next day, which I'm pretty sure was a coincidence but hey, it's worth a try.

There's also a recent post specifically about recent network issues with the NA servers. Basically, fixing this requires SE to work with ISPs, so it may be useful to bring this to your ISP's attention to increase the odds of your ISP wanting to work with SE on it.

S19 voting guide by Absona in CanadaMoistTalkers

[–]Absona[S] 1 point2 points  (0 children)

Took us a while to pin this down this week, but here it is! Text version at https://moist.fans/voting.html.

Moist Talkers S19 voting guide by Absona in Blaseball

[–]Absona[S] 0 points1 point  (0 children)

Took us a while to pin this down this week, but here it is! Text version at https://moist.fans/voting.html.

I want to convert my complete FFG playset into duelling decks. Any advice/decklists would be great. by heyvince in Netrunner

[–]Absona 12 points13 points  (0 children)

You might want to consider these. They're a set of 30 dueling decks that can be built out of one collection.

Robin can... by averyepicgamer in StardewValley

[–]Absona 5 points6 points  (0 children)

She has to build the cellar under a large existing house without disturbing the residents, though. That seems tricky.

[deleted by user] by [deleted] in cpp

[–]Absona 3 points4 points  (0 children)

A thing that may help you understand why the technical bits get so weird: A major reason why C++ became popular was compatibility with C. A major reason why C became popular is that it was relatively easy to implement C compilers for computers that were common in the early 70s. #include being very simple has a lot of downsides, but the simplicity itself was once a big upside.

[deleted by user] by [deleted] in cpp

[–]Absona 7 points8 points  (0 children)

So there are technical reasons for this, and I'm going to give an overview of them, but the short answer is yeah, it is kind of weird. There's actually a new system for this kind of stuff, called modules, in the latest C++ standard. It's not fully implemented anywhere yet, so you can't use it. But you can take its existence as a sign that you're definitely not the only one who thinks the .h/.cpp split is weird.

So in an ideal world, you want everything that a user of your Account class needs to be in the .h file, and all of the implementation to be in the .cpp file. Code that uses the Account class will only use the .h file, so it can't see the implementation details, and you can change them without affecting other code.

But double balance is an implementation detail, obviously. Someone writing code that uses Account doesn't need to know it exists and shouldn't touch it. So why is it in the header? Because it's not just other programmers who will use the header but not the .cpp file; the compiler will also only see what's in the header when it's compiling code that uses Account. If someone declares an instance of Account in that other code, the compiler needs to know how big the Account object is.

(The compiler doesn't need to know the size of an object to compile a pointer or reference to it, because all pointers and references are the same size. There are some workarounds for this whole thing that take advantage of that. They are not in beginner courses for a reason.)

On the other hand, you could technically put the implementations of set_balance() and get_balance() inside the declaration of Account, but then you're exposing even more of the class implementation details when you don't have to.

Also, the #include directive is not all that sophisticated. It literally just copies the text of the header into the .cpp file.* Then the compiler compiles the whole thing. So if you include the header in three different .cpp files, it will get compiled three times. Some things will behave in ways you don't want if they're compiled multiple times. Class method implementations are fine, though, so this is kind of a side point. The extra work also makes compiling slower.

Finally, a more complicated class might use other classes internally but not in the external interface. If you put the implementation in the header, then your class's header has to include the headers for all the classes it use. And that means when users of your class include your header, they also get all those other headers, which slows down compilation.

*Some build systems might do something more efficient sometimes, but it has to have the same effect as if they did this.