I think that most people that are "scientific" are unable (because of our education) to _try_ to think about the validity of this way of _understanding_.
I like to think that societies in Latin America (and, importantly, all around the world) survived thousands of years not because of luck, but because the cultures (language, traditions) they developed had ingrained the "scientific knowledge" necessary to survive in the conditions that lived in. An important part of it was that they did not see only as rulers and owners of the world, but only as one part of it. That is one of the basis of what people call magical thinking, but it is sound once you stop disqualifying it just because the word "magical" is in it.
And, I mean, literally, only those who could adapt and understand their world to survive, survived. The knowledge maybe was not as fast evolving as the scientific methods allows to be, but it is, ultimately, the same method. Try, fail, and repeat. Those who were successful survived.
The knowledge ingrained in the culture, traditions and understanding accompanying it was, and _is_, a fundamental part of the solutions that allowed them not to only survive, but to thrive in their environments.
The first comment in this post says that you do not need the culture to carry out the solutions. That may be true, but it does miss that our culture is the strongest (after "basic necessities") incentives we have to choose some things over others. Or understanding of the world is our culture, and our understanding of the world is what makes us take some actions instead of others. You might be able to mimic technical solutions, but to fully understand them, you need the culture that developed them, as it is _literally_ the understanding of the world that allowed the solutions to exist.
The project started, as you stated, as a clone of Cube World (the name CloneWorld was thrown a few times, did not stick). But it was rapidly decided that the direction we wanted was different. Veloren is a look-similar (and I would argue that not that much) of Cube Wolrd, but it is headed in a completely independent direction.
If I remember correctly it actually is a typo. Someone typed "verloren" wrong and thought it was a good name for the game. The story behind names is often not so glamorous.
I kinda hate many current game names, I prefer this. Otherwise, making a current_year name is easy: noun adjective: noun. How about "Dark Kingdom: Multitude"?
The launcher was there to make it easier to pull the latest build without needing to check if a new version was available. A couple of years back the updates were irregular (sometimes a few days, other more than a week). We regularized the new builds once a week, but, still, the launcher now serves as a way to explore different unofficial or experimental servers that are being available (via registering in the GitLab project).
Most launchers I see aren't necessary for any technical reason. Most don't even bother to enable any functionality at all to the end user's benefit. They're instead used to exert some form of control in a way that's usually palatable enough to not cause a huge PR backlash. As a default stance, being anti-launcher as an end user seems reasonable.
To me launchers are / can be another pattern of dark-ui. Why is a launcher required?
Is the launcher spying on my system, sending information back to HQ?
Can't you tell me the game needs updating when I play the game and then update the game in-game?
Are you going to throw me advertisement banners when you're not making or being greedy?
What if the update fails?
It's one thing I have to wait upon to play the game but launchers come bloated. A carousel of graphics taking a gig of space then requiring an additional 10GB download for the actual game.
Because Veloren's update cadence for most servers is substantially more frequent than most package repositories are willing to handle (trust us, we've tried!). You can install the game without the launcher, but don't expect it to be compatible with most servers.
> Is the launcher spying on my system, sending information back to HQ?
> Can't you tell me the game needs updating when I play the game and then update the game in-game?
That's exactly what the launcher is doing.
> Are you going to throw me advertisement banners when you're not making or being greedy?
Categorically, no. Veloren is open-source (GPL 3), and developed by a close-knit and dedicated community of volunteers. It's a hobby project and will always be free-as-in-liberty as well as free-as-in-beer.
> What if the update fails?
I'm not sure why it would (bar an iffy connection), but the launcher works in offline mode just fine too.
> but launchers come bloated.
Ours doesn't.
> then requiring an additional 10GB download for the actual game
I think we're up at a few hundred MB right now. Most of that is music. It's worth it :)
Yes, just that server and client are very much tied, and we have a release cadence of one new version per week. So, you would need to track the release of each week and compile it, to be able to connect to the official server.
> Is the launcher spying on my system, sending information back to HQ?
The game and the launcher is published by the same people. If they wanted to spy on you, there's no reason not to do that in the game as well.
> Can't you tell me the game needs updating when I play the game and then update the game in-game?
While not impossible, this is way more difficult to do safely and reliably in-game. There's a reason most updaters live outside of the main app process.
> What if the update fails?
Then it's a lot easier to recover from this in a separate, dedicated, minimal app, than as part of the game itself.
Launchers have their place. For example Minecraft needs a launcher: different servers run on different versions (because of heavy customization that doesn't instantly update on a new game release), so being able to select an arbitrary version and launching it is essential. And the snapshot/beta channel works best if you make it easy for people to play the current, stable version, then quickly check out the latest release, then switch back to stable.
Many early-access games do the same via Steam's "beta" feature. If you don't use Steam, you have to replicate the same in a launcher. Or you do it like Adobe and have an entire separate "not a launcher" program to manage which versions are installed.
Verloren currently doesn't seem to actually offer much version management in the launcher, but it seems like a likely future requirement.
It's not clear to me how these are dark. You aren't being tricked, and all of these traits might be in the game client itself as well (game could phone home, auto update, fail to auto update, be slow, etc)
But I expect to play the game, when clicking the game icon. Not being thrown in to a launcher waiting for me while I then thrown advertisements for their next game.
Take a look at EA Origin, it's horrific. It updates then the whole launcher implodes with some alien error code like as one of a printer.
> Can't you tell me the game needs updating when I play the game and then update the game in-game?
Can you explain this a little? Do you have any examples? Unless you're installing a completely new copy of the game, you're not going to be able to play while you update, making this look an awful lot like a launcher. I'm not aware of any games that are hot-updatable.
Q3 was from times without trivially available persistent internet connections. You had to hunt down the patches and mods yourself manually, hoping not to get malware instead. It was a different time. The updates also were much more spread out - last 3 were from 2001, 2002, 2006.
It's just not comparable to how things work today.
Don't you think this is too short an argument to dismiss an as complex topic as this is?
What, aside from this argument (which I'd like to found an study providing evidence of what you wrote, and one providing evidence of exactly the contrary), you think explains _better_ the observations than their arguments?
You need not to use something expensive, only things that you think _looks_ expensive. But, what looks expensive, if not, obviously, the things that are expensive.
The thing with purchasing power is that it doesn't apply to everything. In particular foreign goods.
So while low cost of living countries offset their low wages with cheaper housing, food and local services, imported stuff still costs the same and is relatively expensive as a result. Basically in those countries it really sucks to buy a computer, camera, even cars.
I spent two weeks in Juarez a few years ago for my wife's visa stuff. The hotel was pretty cheap, the food was pretty cheap (and delicious!), but I was surprised to see that an Xbox was actually more expensive than it was in NYC.
It makes enough sense, Microsoft isn't a charity, they're selling the console at a fairly competitive price already in the US, it's not going going to magically get cheaper just because it crossed a border, but it was still surprising to see that.
That makes sense, and not really theoretical; it's pretty easy to buy Blu-rays and DVDs from foreign markets, and they're often considerably cheaper than their American versions.
They of course are region encoded, but I suspect nearly anyone who frequents Hacker News knows how to get around that.
In Mexico you cannot have that, as the constitution says that no right that you had can be taken from you retroactively.
The problem is the Mexico is the most strict country (by law) in copyright terms, which is dead of last author plus 150 years and there is no fair use.
It can explain it. Better training and better equipment are (at least) two variables that improve people timings. Maybe a century ago there was an Usain Bolt, just didn't had neither the proper training, nor equipment, and those low factors avoided better timings.
Except the model was fitted on people from the same period in the same region.
Also, Ethiopian runners would be a counterargument. It's just reading way too much in a model that probably was there before the data. Seeing how everybody defends it as "learning", the example was sought to be described by the model.