BleakBluets @ BleakBluets @lemmy.world

Posts

1

Comments

69

Joined

2 yr. ago

If they didn't meet their quotas they get cherry-bombed.

I enjoy A Link to the Past Randomizer, but primarily because it adds replayability to a game I'm already so familiar with. ALttPR becomes a puzzle of which chests/dungeons have the highest probability of containing progression items. Calculating that optimized routing in realtime while racing against a clock is fun. Also figuring out the best way to deal with a boss that you already know well, but now you have an unexpected equipment loadout is fun to me.

However. If I were to play a new game I didn't have any familiarity with and its item placement and/or map layout was procedurally generated, I don't think I would enjoy a first playthrough. I don't enjoy variety just for the sake of variety. The proc-gen would have to have some known parameters that allow me to strategize in how I approach it in order to not seem arbitrary. If I didn't enjoy the first playthrough of such a game, I might not be motivated to learn enough to enjoy future runs.

That's why I think I don't love Spelunky or Slay the Spire despite loving games that play similarly like Cave Story and Magic the Gathering respectively. I think I could love these games if I could reasonably plan ahead, but I feel those games have too much variance and the outcomes feel arbitrary as a result. Though that could just be my lack of dedication to understanding the bounds of the generated content.

126Saying "over" is the old radio protocol. The new radio protocol is starting by saying the number of characters in the message.

She must be lactose intolerant

Edit: I just now realized that the graphic is more privacy-focused rather than consumer-rights-focused. I don't know what privacy issues Steam has specifically, so its inclusion on this list may not be justified regardless of any anti-consumer practices.

I'm not ditching my 20yo steam account on behalf of this graphic

I think that's why they were included in this graphic. They provide DRM games that are vendor-locked to their platform. They require that you buy a game from them to download mods from the workshop, even if that game doesn't use a Steam-specific modding framework (Slay the Spire and Black Ops 3 for example). They tie that account to many services in order to make it difficult to leave their platform. Services such as: per-game community forums, friend lists with direct messaging and multiplayer integration, VAC anti-cheat, and achievement tracking.

I like Valve, they contribute a lot to open source. But be honest, if Epic Games did 1/10 of this, they would be accused of trying to build a walled garden like Apple.

It will be absolute hell if Steam ever gets enshitified. It would be better if these services could follow an interoperable and open standard or were run independently. Vendor-lock from "good" corporations is still anti consumer.

Arctic Fox, It's a Setup!

Had a beard. He clean shaved a couple weeks ago.

Just according to kakapo. I mean kereru. I mean keikaku.

(Translator's note: keikaku means plan)

Not a film, but he was a playable character (as himself) in the "Call of the Dead" map for Call of Duty Zombies. But even as a good guy, that mode is endless survival, so he inevitability dies in the end.

Edit: I guess he technically doesn't die if you survive long enough that the game resets at the ~70 hour 'killscreen'.

The gibs and blood from enemies is very bright when it stains the ground; I wonder if that ties into a new gameplay mechanic somehow. I think this is also hinted at by the last scene with the psycho in the rain and giant pool of blood. It could also just be a new visual effect.

It's only an ecchi, so no numbers that I could find.

myanimelist

knowyourmeme

This sounds like the Linux vs GNU/Linux meme.

insult to flurries

Good thing you have your fursuit to keep you warm

It looks like a Jakobs pistol from Borderlands.

Don't pick a house with a dog next time.

Now the worm has two ships but they can choose to double it and give it to the next person.

I know it's anecdotal and perhaps can't be blamed entirely on this medication, but I've been taking singulair since I was 12 and I dropped out of school at 17 with a 3.8+ gpa. I did three psych holds and two years of therapy and I didn't feel better until a few years ago at age 26, which was when I was booted off my parent's insurance and no longer able to get my prescription singulair.

I did get a high school equivalent degree and an associates degree in my early 20s, but even then it was very difficult for me to hold a job with how often I would burn out and suffer extended depressive episodes. I'm doing better now, but it was definitely a major set back socially and career-wise.

The claim wasn't that a code refactor is always a change in public interface, but that it could constitute a new major version. I listed two examples of when a major version should be incremented, the first being a change in a public interface, the second (erroneously) was a change in a private interface which I then clarified could only apply in the case of a more substantial code refactor, because as you pointed out (and I reiterated and agreed with), private interface changes don't necessitate breaking changes. It isn't an exclusive requirement that a public interface has breaking changes in order for the major version to be incremented, only that there be a new major version when that interface breaks introduces breaking changes.

I had to explain userchrome thoroughly in order to demonstrate that it is a public interface amd differentiate it from the gui. I assumed it wasn't intuitive because you missed it when I provided it as an example initially and was accused of avoiding that point.

The first sentence of each paragraph addresses which point it argues other than the userchrome demonstration which follows from the prior paragraph and only addresses your userflow vs interface question in its conclusion.

You are correct about private interfaces. When I wrote that I was imagining something more significant like a code refactor, but yes, obviously, changing something like an internal function definition would not require a new major version if it doesn't change a public interface. Similarly, implementing a bugfix or new feature wouldn't necessarily mean that an existing public interface was broken, or that the major version should be incremented. I didn't intend to imply that.

I am using public interfaces in my examples because the original point was how SemVer can communicate at a glance to the end user the kinds of changes that were made (compatibility-breaking, bugfix, etc.) and I had the offhand idea to also communicate when the update was released by including the date in the patch number. I am not confused about what semantic versioning is or whether it can only apply to public interfaces or libraries. If I knew it was going to start an argument, I wouldn't have mentioned backwards compatibility; it was an offhand comment tangential to the idea I was explaining. I could have just as easily said:

"I prefer the SemVer Major.Minor.Patch approach so I can tell at a glance if the update is a new feature release or is just bug fixes".

I don't think I skipped the question about Firefox interfaces. An interface I was looking at for backwards compatibility was in the example I provided with the UserChrome interface and I provided a specific example of a third party tool using that interface, the FireFox-UI-Fix project. Admittedly, this isn't a strong example because the UserChrome customization doesn't expose any functions to be called and doesn't define any kind of protocol in a traditional sense. But that doesn't make it any less of an interface in my opinion.

The UserChromeCSS customization feature is provided to the user by Mozilla for the purpose of modifying the browser's chrome i.e. graphical user interface (note I'm not confusing a gui with a programming interface, they just happen to be the same thing in this example). In order to make these customizations, the user must be aware of how the browser's gui is layed out, i.e. the user must know the structure of the HTML that makes up the browser's chrome. If the user writes a gui customization which depends on that structure for one version of the web browser but then the browser changes that HTML structure in the next update, that constitutes a breaking change. In this example the interface is defined by the chrome's HTML itself. The CSS written in the UserChrome.css references/selects that HTML and is thus dependent on the stability of that HTML in order to produce the same effects across different versions of the web browser. Third-party tools that distribute custom UserChrome.css files should therefore expect that their customizations be compatible across minor and patch versions of the same major version release. It's not necessarily that the major version must increment every time this gui is changed, but when the interface for customizing this gui has introduced a breaking change (which in this case is usually synonymous). I think this is what you mean when you say "userflow". If so, then no, I don't think "userflow" is an interface. The userflow/gui happens to be an interface in this example because of the UserChrome feature that exposes the gui to modification through its own HTML/CSS interface, the stability of which is depended upon by both users and third-party developers such as the Firefox-UI-Fix project I mentioned.

As for other Firefox interfaces which would call for a major version increment upon being changed, there is the WebExtensions API for browser extensions, and the cli arguments that you mentioned. I don't think providing an exhaustive list supports or invalidates any point or opinion I've stated. The major version number is incremented if any public interface changes, it doesn't have to be representative of a single interface exclusively. An application can provide multiple public interfaces, where a library tends to be more singularly focused (maybe this is the source of our disagreement/misunderstanding?). An incremented major version just means that there is some breaking change(s) in some interface(s). Conversely, an incremented major version number doesn't imply that every provided interface contains a breaking change.

If it's your opinion that SemVer is better suited to a narrow API or library where a new major version exclusively indicates a breaking change in its singular public interface. Ok. That doesn't indicate a lack of understanding SemVer on my part, and that's not a requirement of SemVer. There exist applications using SemVer that expose multiple interfaces.

My suggestion is in compliance with standard SemVer as far as I can tell, but yes it is frustrating when apps use versioning that looks like SemVer, but make interface changes in Minor versions and don't really adhere to SemVer.