Pardon my complete ignorance. Do they try to extort the owner of the video game? If not, how does the target get so uncomfortable with the situation they would consider paying?
I think the rise of streamers and Internet personalities has incentivized many present day cheaters. You're more likely to strike it big—become popular, get paid—if you're good at these games. There is no shortage of YouTube videos showing streamers getting caught on stream cheating.
In team fortress 2, players can receive loot boxes/in game items during normal gameplay. The loot boxes can be unlocked by purchasing a "key" for ~$2.50, to receive cosmetic items. Many of the cosmetic items can sell for a lot, on the scale of hundreds or even thousands of dollars.
The cosmetic items from loot boxes (as well as those attained from normal play) can then be sold in online markets (such as scrap.tf or marketplace.tf) for real-world currency.
This is probably what the primary goal of the bots is. Ironically, the source of TF2's profit for Valve (microtransactions for cosmetics) is also a partial cause for the bot crisis.
I did it very briefly as a teenager. It was fun to spend hundreds of hours struggle bussing at a game, trying super hard, still being mediocre, to suddenly having god-like powers and mowing everyone down. It wasn't about my ego or feeling superior, it was just mechanically fun in the same way it's fun in battlefield to be in a tank hunting down people on feet.
Many people enjoy feeling superior to others, and have zero qualms about behaving immorally or against the rules. Some even get off on it and enjoy the challenge.
We see this behavior everywhere in real life as well, but it's much easier to achieve in a virtual setting. Whether that's by harassing someone verbally, or winning in a game by cheating, it triggers the same pleasure receptors for these people.
A psychologist could explain this better, and I'm sure this has been studied thoroughly.
I understand the ones that stay on cheated servers. There have been CS servers in the past that made it unequivocally clear you only belong there for cheating, and it was a literal duel against cheat client configs - I've heard it was a lot of fun.
Back in my youth I used to write farm bots for f2p asia MMORPGS with a friend. And it was basically just one more programming problem to solve. We just did it for the sake of the challenge.
While I lost interest after leveling up a few characters over night and letting the bot farm, my friend kept on working on them to make them better and sell them for little money. After all we were still in school and he made some good money with it. I'd assume that's the point for most cheat devs. Just doing it to show it could be done. Those people that annoyingly use the bots are just laughing their asses off while using them. Schadenfreude is a thing, you know?
Really? I don’t think it’s substantially different to the psychology of cheating in any other field, whether that’s drugs in sport or tax fraud.
In gaming, cheating is an opportunity to LARP as a better player. Gaming identities are often anonymous, cheat tools are widely available, and the prevalence of anti-cheat implies that “lots of other people are doing it” which gives some personality types sufficient moral cover.
I don't know. There are some benefits to be sure, but I figure that above some threshold (and 3B is definitely above that threshold) it becomes difficult to make new friends without worrying about their ulterior motives.
The threshold depends where you live; a former partner of mine moved around the world a lot, and in when she was in Nairobi… well, her anecdotes suggest you got that effect from what Americans would consider a middle-class income.
I'm sure any billionaire has that issue. The biggest plus to $3B vs $100B is you can sell stock and buy all your fun toys without risking loss of control of your company.
IMO, people get way too caught up in the formal specification of grammars. Writing an unambiguous parser by hand is not that difficult. It can be done without a lexer using recursive descent and a switch statement at each byte in the input stream where a decision needs to be made.
"Inspiration is for amateurs. The rest of us just show up and get to work. If you wait around for the clouds to part and a bolt of lightening to strike you in the brain, you are not going to make an awful lot of work. All the best ideas come out of the process; they come out of the work itself." ― Chuck Close
Close is a complicated person but the quote holds up.
Showing up and getting to work is a great mantra for people who already have traction. For people that aren't, that's a recipe for burnout, as you need space and time to keep pushing in the face of uncertain returns.
This is sensible, but I don't fully understand why there is such pressure to support inherently ambiguous infix operations. I get that 1 + 2 * 3 might be marginally nicer to type out but 1 + (2 * 3) is completely unambiguous no matter what language I'm using. This, for me, improves readability, especially because I don't have to guess what the intention was if I'm ever confused by the result. Also, it's one thing in a math or science paper where the reader can correct the result if there is an ambiguity, but if a compiler handles ambiguity wrong, that can throw the entire program off quite significantly.
The ratio of time spent on precedence parsing in compilers to utility feels very low to me. That being said, I do appreciate the satisfaction of being able to implement it declaratively as the author does here.
Lisps, Smalltalks, and APLs are among the language families that haven't bothered with precedence.
(that said, I think it's worth it: an afternoon spent providing precedence is easily paid back —in an expression-oriented language, anyway— in avoiding myriad pairs of parens)
Smalltalk does have precedence, just not among infix operators. It has keyword, infix, and postfix expressions and needs to specify the relative precedence between those. In other words, the language has to decide if:
a b: c - d e
Is parsed like:
a b: (c - (d e))
a b: ((c - d) e)
(a b: c) - (d e)
(a b: (c - d)) e
((a b: c) - d) e
I spend far more time reading code than typing it, so the time to type () is in the noise compared to the time to remember precedence rules while reading.
If there were only a couple of operators, maybe precedence would be manageable, but there aren't.
Please explain how certain players having more or less unlimited capital advantage that allows them to snuff out any potential competition leads to more aggregate freedom.
This is a flawed analogy and I think there is a false dichotomy by framing skepticism around building more highways as inherently anti-car. I'm going to go out on a limb and say most drivers do not enjoy traffic and most residents near busy roadways do not enjoy the effects of traffic on their neighborhood. The question is what is the best policy approach that manages all people's concerns. For me, the question is how can we get people to live and work in areas where it isn't necessary to inefficiently, and very expensively, move people to and from work.
Since the 1950s, we have optimized for essentially the least efficient form of transit available. It seems completely bonkers to me that in the bay and other high density areas, you have many, many workers, particularly at the low end of the income scale, driving over an hour each way to work. It is an understandable and rational decision for the driver, but crazy to me for society.
> For me, the question is how can we get people to live and work in areas where it isn't necessary to inefficiently, and very expensively, move people to and from work.
I cannot comprehend why more firms aren’t embracing remote work more than they do. It helps alleviate a lot of these traffic challenges and can result in reduced carbon footprints as well as more happy employees. I hope we start considering remote work as a solution to some of these problems more in the future.
> However, when it comes to separating code into modules or packages, Python is more convenient.
Kind of curious about this. I find packaging in Lua quite convenient. I make a file and return either a value or a table full of values and then I require that file in the dependent file that uses the package.
Also, wrt to the missing features like an increment operator. It is possible in at most a few thousand lines of lua to implement a lua' -> lua transpiler where lua' adds some missing features, such as increment operators, in an idiomatic way. In other words, the generated code looks almost exactly the same as the input code except in places where say `x++` gets translated to `x = x + 1`. As long as your file is less than a few thousand lines of code, the transpiler can run in < ~200ms (and obviously much less for shorter files or much faster if the transpiler is implemented in a faster language). Of course the tradeoff is that the original source code may break existing tooling for lua, though the generated code will work fine.
makes me think that they haven't used python in a production environment. It's a mess, pip, poetry, stupid eggs.... that's just deployments then there's personal dev environments.
Guess you never had to fight luarocks then. Everything’s easy when you don’t need to pull in any dependency (which is the case for the most common Lua use cases: host application provides helpers the best they can, you write your own code for everything else). Hell, C’s package management is great if you have nothing to manage.
The first and foremost reason for the complexity of Python’s dependency story is that it’s powerful and people use it a lot.
> Kind of curious about this. I find packaging in Lua quite convenient. I make a file and return either a value or a table full of values and then I require that file in the dependent file that uses the package.
While that aspect of it is nice, I think the way paths are handled by default can get annoying.
Since everything has to be relative from the current directory, it's not very convenient to move files around or make a contained module that depend on its own module.
If you're in charge of your own environment, sure, you can roll your own thing, but then you deviate from the norm and your code becomes less portable.
There is also the LuaRocks package manager, which I believe is decent, but it's largely ignored by a big portion of the Lua community.
> Since everything has to be relative from the current directory, it's not very convenient to move files around or make a contained module that depend on its own module.
What? Not in my experience. For instance, I have lpeg install ~/.luarocks/lib/lua/5.4 and LuaXML in /usr/local/share/lua/5.4 (just to name two modules I use). To use them, it's just
local lpeg = require "lpeg"
local xml = require "LuaXml"
Yeah so this is both the "in charge of your own environment" and using luarocks, which is ignored by a big portion of the lua community.
A common situation is wanting to distribute a script that can be loaded and run by a lua-using environment, say a game client or something along those lines. What can you depend on? Can you expect or demand that users of your script have luarocks installed? If not then what is the path? On windows too? Do you maybe need to vendor that? Can you even? If the module is pure lua then fine, but lpeg isn't. Is the OS going to allow the host program to dlopen an unsigned C bin?
Lua is used for so many different things you could possibly never run into any of this stuff. But in my experience it's a major headache for a lot of uses. Partly this is a consequence of lua succeeding on its own terms, and being embedded in a lot of highly variable situations. But it still sucks in practice.
This is very interesting data. I believe that it is generally considered common knowledge that it's very difficult to increase youth turnout so most campaigns don't even really try. But given how entrenched polarization is, increasing youth turnout in a few key states could be enough to sway the election. Of course decreasing retiree turnout is another (not mutually exclusive) approach. The nice thing about trying to increase turnout though is that it is a positive and inclusive approach rather than a negative and exclusive approach (though the implementation could still be negative: come out and vote for our guy to get rid of that other guy we don't like).
reply