The only reason people will continue using Unity is because they’ve already made )or are in the process of making) a game using it and switching to something else would waste massive amounts of time and effort. Unity is depending on this - this is basically them squeezing everything out of existing customers without regard for long term growth.
Remember, the whole idea here is that Unity is demanding payments for already existing games. They clearly don’t care about whether people keep using Unity for new games in the future; the executives who made this decision will have cashed out and will be long gone by the time all the existing Unity games in the pipeline are done and things dry up.
They will try to sell based on future payments owed, or projected earnings. Then they will be sued by a big guy for breach of contract, having changed the terms without consent.
Then the money will disappear. Already, the engine will be abandoned. Unity is dead now.
Foss is available and with the programming community now incentivised to use it, it should do well. That might be their play. They knew the end was nigh.
Nah, unity is/was a good engine. The reason why it has a bad reputation is for the same reason that Game maker used to have a bad reputation. Almost everyone who’s learning how to make games uses Unity because it’s easy to use, is extremely well documented, and has a massive store full of add-on scripts, programs, model sets, etc. As such, all the poorly optimized games and 0-effort asset flips end up being made in unity (though I’ve seen some unreal games that make even the most poorly optimized Unity game look good). The result? Even though there are a number of high-quality, highly-regarded games that use unity, it has a reputation for being a shitty engine.
Don’t believe me? Keep an eye on Godot or Unreal. If unity sticks to their new license, then it’s highly likely that one of those engines will become the new “newbie engine” and gain a reputation for being shitty.
I disagree. I’ve been/am working on several pretty large projects in Unity (some of them sold hundreds of thousands copies), and especially once you start porting to consoles, the experience goes to shit. Their support is vague, documentation is plainly wrong in some places - I’ve once spent few days figuring out how to use a documented and explained feature, only to find out later that there’s a closed few years old bug on their issue tracker that it’s actually not supported, and the documentation only does not explains it very well. (The feature was multiple hits per single Raycast in jobs, here are the docs. According to the bug resolution, only one hit per ray is supported, and the docs only don’t explain it very well. The docs are still the same.)
You also inevitably run into issues that you simply don’t have in other engines - it’s closed source. You have no idea how is something implemented, or whether something isn’t working because you are doing it wrong, or if it’s Unity bug/fault. In Unreal, if something doesn’t work, you can always just check the engine code, and either fix it yourself, or better understand why it’s not working. If you need to slightly modify some engine behavior, you’re out of luck with Unity - you have to resort to ugly hacks that sometimes work, but usually at a cost. In Unreal, you just modify the engine code and be done with it.
Trusting Unity with any feature is also a gamble. Have you started developing a multiplayer game on Unet? Tough, we don’t want to support that anymore. But, we will create a better multiplayer system, just wait for it! Then they removed Unet, and the new networking relacement is widely regarded as pretty much unusable - or at lest it was last time I checked. Thankfully, there are a few amazing open source networking addons.
In general, while Unity is an ok-ish game engine for smaller hobby projects (but for that, Godot is better), it’s really an awful and frustrating experience once your project size grows and you need to build bigger games, or if you start porting your games to consoles.
And it’s also really apparent from the way they communicate and threat you company that they don’t give a fuck and only want your money.
It would mean every Unity game was not-so-secretly shipped with code that phones home to the Unity company upon install.
Either they’ve been egregiously spying on gamers for years (and by extension, game developers using Unity have just been fine with that), or they’re lying through their teeth.
Probably the opposite actually. The devs who utilize the feature probably enjoy having some numbers to look at and analyze. They’re trying to make a game that people enjoy after all; the more info they have on how you’re playing the game, the better. The devs who don’t use it probably aren’t even aware that it exists. Additionally, I’m not sure if it requires a subscription to view the telemetry (the page suggests you have to sign up for it in some capacity), but if it does then it makes sense that devs might believe that it’s something that’s disabled until you manually enable it.
Personally, I know if I was a dev I’d be checking that shit every day. I like watching the funny numbers go up and down.
When crackers don’t patch out the phone line, they can.
Edit: Only in some cases, though. They can detect popular ways to crack games, like Steam DRM stubs. If the game has zero identifiable information about the buyer and no or an unsupported DRM, they’re SOL.
and how exactly is unity going to know whether it was gotten legitimately or not? the only way the developers wouldn’t get charged is if crackers patched it out
They can’t detect everything, but let’s look at Steam as an example. If the game detects Steam DRM, then the game knows that they should’ve bought the game on Steam. They can check whether the Steam DRM is a stub and therefore a crack, or get your local Steam account ID and cross-check whether you bought the game with a Steam API.
The thing is that most Unity games don’t even have DRM in the first place. At most most will have the Steam DRM which is trivial to bypass. And Unity Games released on GOG will be especially at risk.
Doesn’t matter. Regardless of what Unity said their “Enterprise” plan was, it doesn’t matter.
B2B deals just work differently since both companies have more at stake. If a company like EA used Unity, there is no way Unity would want to lose that contract and EA couldn’t afford to drop Unity. Large companies will likely go through a few short renegotiation meetings, if that.
Plus, lawyers. If Unity even tries to force this on its larger customers, they are going to be hauled into court and most likely lose. When they lose, Unity will likely be liable for court costs as well.
You can check justwatch.com to see if it’s available anywhere for streaming or purchase. I dunno how they do it but they’re amazing at tracking this sort of thing.
That’s what I read as well. You would think they would’ve gotten some leeway since it was done during an event comparable to war and they were following the footsteps of other digital libraries. They had a pretty stellar reputation and system in place for nearly a decade already, so I can only assume that they were simply waiting for an opportunity to target them.
According to what Unity reps said elsewhere, they have no way of knowing what’s a bought install, what’s a demo, what’s a charity bundle, what’s a pirated install, and what is someone loading a webpage with a WebGL program integrated (every page view = 1 install).
Instead, they want to estimate how much people owe them. Using secret methods with no accountability.
Exactly. To me, this explanation sounds like they’ll just magically estimate the numbers without really being able to prove it. And that sucks.
However, we can be sure that developers will have their own analytics, that are probably way more accurate and they know exactly how many people have played or installed their game. And I’m betting that this number will be a lot smaller than the Unity “estimation”, and people will get even more angry.
Depending on your client, there may be different directories for complete and incomplete torrents, so you may have to put the downloaded files in the incomplete folder. If your client only checks the incomplete folder when starting a torrent.
Lmao I’m so sorry! I realised afterwards what was happening, but have no idea how to fix it since I’m still fairly new to Lemmy. I hope it didn’t inconvenience you too much!
perfectmediaserver.com can give you some inspiration on system architecture/layout. There’s a lot of right answers here depending on your situation, so you’ll likely want to research the various options and trade-offs.
Some common base architecture layouts that I know of:
Any Linux + no parity: Just throw Debian on a box, put Docker on it, and away we go. No data integrity, and data loss will be permanent, but it’s an option if you set up backups for your important data and assume the rest is expendable. If you want to start setting up parity on raw Linux you’ll probably want to move down to a more dedicated architecture below for less headaches.
OpenMediaVault + SnapRAID + MergerFS + backed by BTRFS disks: my personal choice for ad-hoc/budget setups. Great for having really flexible storage that lets you make use of all HDD space that you have laying around without fuss. You’ll need to sacrifice your largest drive to hold RAID parity and the storage architecture is not especially performant but that’s not a big deal for a media server. OpenMediaVault can run Docker for you on the host without needing to run it in a VM (and you should be using Docker for your software stack).
Unraid: Similar in storage architecture to the OpenMediaVault combo, but it’s not free. I don’t have personal experience with this one but a lot of people like it. IMO this option would only make sense if you want a turn-key system and don’t want to think about anything on the software side. It has turn-key “apps” that are just Docker behind the scenes (to my knowledge).
TrueNAS Scale: This will be running ZFS for storage, but ZFS has a lot of problems with storage flexibility. You need to really know what you’re doing when designing your storage layout, and you probably won’t get full usage out of the HDDs you have laying around. In exchange, ZFS is bulletproof for data integrity and makes full use of your drives’ combined speed. You’ll likely be giving up 50% of your total HDD capacity to run ZFS - either explicitly by running mirrored drives or by running mismatched RAIDZ1/2 (which makes all drives become the size of the smallest disk). I would recommend a mirrored setup for home use due to its flexibility - it gives up more space than RAIDZ but it’s able to be upgraded easier in the future, so you can throw random drives that are on sale into your system when needed. You could write a book on ZFS’s complexities and trade-offs and I’m sure many have. TrueNAS itself is basically just a turn-key appliance to run a ZFS storage server, but the “Scale” version also comes with the ability to install apps via some Kubernetes+Docker thing. It’s still in beta and I hear a lot of people have problems with how the app system is designed, so if you go this route I’d recommend installing Debian/Alpine Linux under TrueNAS Scale in a VM with something like this method, and running normal Docker on that VM. TrueNAS is otherwise very locked down and if your usecase is not supported by them you’ll probably need to bail out to a VM anyway.
Proxmox + TrueNAS + Docker Host: This has all the caveats of ZFS from before. Proxmox is just a virtualization hypervisor that you can put other operating systems on, via VMs and LXCs. The easiest way to use it in a NAS configuration is to install Proxmox on the bare metal, then spin up a TrueNAS Core/Scale VM and pass through your HDDs to that (may require special hardware consideration). You’ll probably want to run a minimal Debian/Alpine Linux VM under Proxmox to hold your Docker stack. Then you can use an NFS/SMB mount to get access to your ZFS storage from your Docker VM. You can also run ZFS raw on Proxmox without the GUI of TrueNAS, but you’ll have to manage it by CLI. Proxmox can be more difficult to understand than the other architectures, but personally I think it’s easier to use once you do. It allows greater flexibility on the software side via snapshotting VMs and building up/tearing down operating systems at-will.
Proxmox + OpenMediaVault + SnapRAID + MergerFS + backed by BTRFS disks: Same as Proxmox+TrueNAS, except instead of TrueNAS you run OpenMediaVault’s storage stack to give yourself flexibility with HDDs. You’ll might also want to move your Docker stack into its own VM instead of running it on OpenMediaVault, but this isn’t required. While this is technically an option, it feels a bit weird. If you want to dive head-first into a robust server setup but don’t want to buy a bunch of new drives, this could work in a pinch.
Personally my two recommended options are the OpenMediaVault stack or the Proxmox+TrueNAS stack, depending on if you want to buy new drives for a clean storage layout. Keep in mind these blurbs are just a crash course on each option and there’s a lot more going on behind the scenes that will also need consideration/planning.
piracy
Gorące
Magazyn ze zdalnego serwera może być niekompletny. Zobacz więcej na oryginalnej instancji.