> I wonder how many other tech folks has the same impression??
I do! I've worked with C, C++, Python, Java, Go, JavaScript, Ruby, and Pascal, but for anything that isn't network-oriented or a simple CLI tool, I always reach for C (sometimes a strict subset of C++). Its distinct lack of features allows me to focus more on the problem at hand and less on the best of the hundred different ways to do something in other languages. Go is the same way, which is why I use it extensively for mid-level stuff like CLI tools and servers.
I've used C and Go quite a bit, and I find it a horror to write.
I end up duplicating tons of code - the exact same code copied hundreds of times across the codebase, with every time slightly different changes made to it.
How do you do custom data structures that need to parametrize over multiple types without duplication in C or Go? How do you do sane error handling without 90% of your code being if (...) { // handle error } or if err != nil { return err } ?
That code can be simplified a lot if the db object stores the error itself so it can be checked only once after few calls, like what bufio.Scanner does.
The target property overrides the global setting, so you can set CMAKE_CXX_STANDARD as the default and then set the target property if you really need a different standard for some reason. And if you have a whole sub-project that needs a specific version, you can set CMAKE_CXX_STANDARD before calling add_subdirectory to have it apply to only the targets in that directory.
Note that the variables in the "Detecting an operating system" section are for detecting the target operating system, not the host (what CMake is running on). If you use a toolchain file to cross-compile from Linux to Windows, for example, WIN32 will be defined instead of UNIX.
Could they not have required the user to own a copy of Fallout 3 and then extract the needed sound files from the original installation on first launch? Then the copyrighted works wouldn't need to be distributed with the mod itself.
"idea was rejected by (offended partys') legal team" should never be the conclusion of something like this; but I can understand not wanting the trouble for a work of passion.
In fact, working on a mod for a game -- and then getting legally threatened by the owning company of that mod platform -- would entirely drain my enthusiasm or passion for the game/company/platform.
If you read the mod maker's actual note, you'll see that they were not "threatened" but rather they entered into a dialogue with a team they respect and want to maintain good relations with (video game mods are often a path to employment in the industry), so they chose to halt development when Bethesda said they couldn't allow it.
These conversations can be civil and respectful, even if the outcome is not ideal.
I could be wrong but it sounds like Bethesda don't own rights to the voice acting. They only licensed it for the purpose of FO3. Outside of that they can't grant or deny anyone permission to use it. Presumably there is either another corporation who owns the VA rights or the individual artists own the rights. There were some big names involved so I'm not sure if that makes a difference.
Yeah, I suspect this is the case as well. As an example, Skullgirls had Japanese audio recorded for its Japanese physical release, but then had to reach some sort of agreement (and probably pay money?) to relicense the voice acting so they could distribute it in the US and through Steam.
They did a 5th anniversary release of Oblivion, so we know anniversary editions are something on their radar. I would not be surprised if this was indeed the case.
I really wish they provided details on why they had to go to the legal team in the first place and on what grounds they were rejected. Among other things, I would imagine the developers would not be liable for end-users violating the EULA, so it's kind of head scratching why they would interact with bethesda at all.
I think the mod developers don't want to spend their time,energy and money in a legal battle, Bethesda could drag this in courts and who knows with the current copyright laws may even win, would you risk it if you were living in US or such a country? I would give up and work on an open source game instead or a game more friendly to this kind of modding.
Possibly because they are huge fans of the studio and the games (why else would they put so much time into this project??) and they don't want to be at odds with the people who make the games they love so much?
This is usually how it's done. See, for example, OpenMW. It extracts the resources from your already-installed copy of Morrowind during the installation.
E: Also, some total conversion mods will make a copy of your game installation, then install itself into that copy. I think (it's been a while since I've played them) that Nehrim (Oblivion) and Enderal (Skyrim), both from SureAI, do this.
(Though OpenMW isn't a mod. It's a reimplementation of the engine.)
Bathesda also had some very strange requirements for the OpenMW folks when they were in contact[1]. Namely they didn't want them to show OpenMW working on Android (because Bathesda wanted to port it themselves?) nor did they want them to support the XBox version of the game. I doubt that Bathesda actually had the right to add those requirements to a project that is a from-scratch reimplementation of their game engine, but that's the current status.
Supposedly some file formats have changed between Fallout 3 and 4 so you'd need to convert said files as well. Not exactly an insurmountable technical hurdle. There is at least one other similar project that isn't shutting down.
The rule with these things is typically "If you make us give you an answer about if you can do it, it will be no."
I don't know if Skyoblivion ever managed to write a robust solution for translating the codebase from the old scripting language to Papyrus, and I can see why it might be a huge hurdle for modding teams.
To clarify, I was only talking about audio formats. Not automagically converting everything to run on the new engine. Doing that would kind of be missing the point.
There is a similar project redoing New Vegas in Fallout 4 (F4NV - I'm not affiliated with the project, just a fan snooping on their progress from time to time) and one of the really important things is that they're making their vision of what NV could be. This means all new meshes, textures, and code - not the old content updated to run on the new engine.
I've written some code for fiddling around with the plugins the engine uses (.esp/.esm/.esl files). The basic structure hasn't changed, but a lot of the records and fields have. Automatically converting them well enough to not need manual tidying up would be a pretty arduous task.
Converting the old code into papyrus would be as well.
Or what about removing the restricted sound files entirely and allowing the user to provide their own, which could presumably come from some fan version.
Then again, I guess releasing your "redo" of some voice actor's soundtrack violates copyright too?
(Like, I couldn't release a set of files of me doing Darth Vader's lines from A New Hope?)
Hyper-V is extremely strict about what can access its hypercalls, so you can't do anything from userspace like with KVM and HAX. Hypercalls can only be made from ring 0 and creating domains can only be done from the root domain.
Dillo specifically avoids scripting, so I doubt the internals are well-suited to that sort of integration. You could try extending NetSurf[1], though. It uses Duktape[2] as its Javascript engine and its API is pretty similar to Lua's.
Thanks, I should look how others did it. It's true that dillo never cared about scripting, I felt like plugin lua in would force a rewrite of every part..
I really, really wish Microsoft would open up the Pico Process APIs to third-party driver developers. Right now, WSL is the only driver allowed to install Pico Process callbacks. It would be cool to implement a Darwin layer or a Classic Xbox emulator with that tech.
The Pico Process subsystem isn't fully baked yet -- in earlier talks Microsoft mentioned that while the API itself is pretty generic but the current implementation is just hacked together to support the Linux subsystem for now.
I do! I've worked with C, C++, Python, Java, Go, JavaScript, Ruby, and Pascal, but for anything that isn't network-oriented or a simple CLI tool, I always reach for C (sometimes a strict subset of C++). Its distinct lack of features allows me to focus more on the problem at hand and less on the best of the hundred different ways to do something in other languages. Go is the same way, which is why I use it extensively for mid-level stuff like CLI tools and servers.