The Unreal Engine Wiki is now permanently offline
forums.unrealengine.com
forums.unrealengine.com
> Why can’t we put a read-only archive online currently? The Wiki, even in it’s read-only state, was presenting security risks, and it was deemed necessary to take it offline.
What am I missing here?
This indicates otherwise.
Maybe the people at UE need to be taught how to use wget.
That's still a lame excuse though. They could have outsourced all the "hard" stuff to a free Netlify account.
That is just an excuse.
> This isn't very helpful, Amanda! I know that the wiki wasn't optimal, but there were many wiki pages developers like me had bookmarked for years beacuse they contained comprehensive and easy information, which is now missing. Why not just keep the wiki read-only online? Just to retain the old pages? I'm pretty lost right now without some of these articles and I don't understand why the only option you had was to completely disable it. Please think about opening it up again just for read. I don't care about the maintenance mode, but the wiki was an important learning point, which is now gone.
If you don't want to support the wiki that's fine, you don't owe anyone hosting, but if you're going to dump it, atleast give someone the opportunity to scrape the site and host it themselves.
I can at least see why they'd hesitate to leave things up, depending on the anticipated risk and likelihood of addressing it in reasonable time.
Edit: Downvote if it makes you feel better, but this is really how groups execute on problems like this without taking time away from other important projects. "Security issue? Extensive fixes needed? Take it down!"
Don't need to explain, don't need to make a fuss - just announce and move on.
But I also think loktarogar provided a better solution.
And that is what a discussion forum is for.
[0] https://addons.mozilla.org/en-US/firefox/addon/single-file/
Naturally, you mean you'll SAVE that page, right? LOL.
Archiving even just a single webpage is non-trivial. You're dependent on the internet archive if you want a reliable backup.
1) The wiki software and database have been abandoned for years. There is no maintenance and no further release.
2) It will stop working shortly. Like, it doesn't start on Ubuntu > 14 or current MySql at all.
3) It already stopped working and/or the content is already lost. Can be an accidental deletion or the 10 year old server passed away.
4) Security vulnerability. Remote code execution / SQL injection in the wiki software. That can't be fixed because point one.
I wrote a longer blog post on software death cycle in companies https://thehftguy.com/2019/12/10/why-products-are-shutdown-t...
You'd need to process each page then data mine it.
1) httrack wasn't able to crawl anything for some reasons. wget only with special flags available in the latest version.
2) All the links are broken. Wiki have their own linking system between pages that are processed on the fly. The archive with all links hardcoded to wikidump.example.com/wikidump/page really doesn't work in place.
3) More challenges with saving pictures and attachments.
4) Unicode characters in some pages, that broke the page and/or the crawler.
5) Infinite crawling and a ton of useless pages. Consider that every URL with a query string is a separate page. /page?version=50&comparewith=49
6) Crawling large amount of documents takes forever. Could be an hour wasted on each try. Consider tens or hundreds of thousands of unique URLs to save, see point five. Really wish the crawler could parallelize and run on the same host as the wiki.
"After over a year in maintenance mode, the official Unreal Engine Wiki is now permanently offline."
It seems to have been a problem for some time.
At the very least, put it in read-only maintenance mode, with a big disclaimer at the top saying so.
But to just destroy information, information about your own product, is…well, it's stupid. Profoundly so.
[0] https://web.archive.org/web/20200329185200/https://wiki.unre...
EDIT: It seems like the main problem is that they didn’t do a good job communicating their intention and timeline for removing the old wiki.
Building a New Thing comes with excitement and praise.
Microsoft has done this so long their own people strongly recommend using URLs in https://aka.ms/ their long term link maintenance software, so that when yet another "exciting" change happens to their entire Microsoft web site you can still find all the vital documentation. Maybe their "Knowledge base" articles for example, will become a Wiki again, and then a social networking site, and then a blog the week after, and then a different Wiki with newly inscrutable URLs. But the aka.ms link can be updated so that you don't need to spend an hour navigating.
The more important maintenance becomes to a company's actual financial health the more senior management rebel and become sure their destiny is to radically reinvent the company. If directors did their actual job (working for the shareholders, for whom "exciting" aka "massively loss making" isn't the goal) the very next thing you'd hear after the CEO announcing the company has a new name, new branding, new logo, would be the Chairman arriving to tell everybody actually it's not a new name, new branding or new logo, just a new CEO, sorry, no big leaving do he was escorted off site by security.
From a purely historical/retrocomputing point of view, I'm really disappointed IBM took the legacy Library Server site offline.
It was full of fascinating detritus... old OS/2 manuals, various ancient layered products that IBM dreamed up once upon a time back in the 1990s or early 2000s and which never went anywhere (DDM, DCE, etc)...
Why couldn't they just donate the contents to archive.org or something like that, if they don't want to host it anymore?
At least they still have the offering information site online – https://www-01.ibm.com/common/ssi/ – full of product announcements from the 1980s. To pick some random examples:
https://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common...
https://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common...
Sadly, I'm sure sooner or later the old stuff from there will be gone too.
They still host a bunch of old classic Mac/Apple II files, but they're not longer browsable, you have to find old links to them.
E.g, here's the first floppy image to install MacOS System 7.5.3 http://download.info.apple.com/Apple_Support_Area/Apple_Soft...
Their support site also still has a bunch of articles from the 90's in the database, you can still get them to show up in the searches on their own support site, but they're not browsable and hence not indexed by Google.
Anyone need help getting HyperCard 1.2.5 working on their Macintosh IIfx with the NuBus Macintosh Display Card 8*24 GC? https://support.apple.com/kb/TA46247?viewlocale=en_US&locale...
I don't know how often, giving beginners access to a space shuttle, will it lead to a successful project that can compete with non-indie game developers.
There is also a fine line between an indie team of developers who can benefit from those tools, and experienced game developers who would not need them.
It seems unreal and unity are just very capable, but cheap, tools that are well-marketed towards students and beginners. The problem is, once those developers learned to use those tools, they are still unable to develop a game without those tools, which is a huge win for unity and unreal.
Generally I tend to believe unreal and unity only enable developers to make games that will never be able to compete with more established and skilled game developers. I think it's a pretty sad situation, because initially I really believe indie games were able to compete with those big studios, but they're not, and I think unity and unreal are responsible for this. It seems the whole FOSS mantra/paradigm/philosophy has a lot of trouble penetrating the field of game development, maybe because games are heavily monetized towards consumers, unlike other softwares. It bothers me.
That said, for a hobby project it seems fine.
> Godot uses a shading language similar to GLSL ES 3.0. Most datatypes and functions are supported, and the few remaining ones will likely be added over time. Unlike the shader language in Godot 2.x, this implementation is much closer to the original.
https://docs.godotengine.org/en/3.0/tutorials/shading/shadin...
Godot is relatively new and definitely "not there yet", but at least with its open nature you can do `git clone godot-doc.git` and no top manager can take it away from you.
Someone else already mentioned Godot, which I think is fantastic and a lot of fun for making 2d games. I have not tried to use it for 3d, I understand its new renderer is making it more competitive with more advanced engines.
edit: btw, I don't really agree with anything GP said. I just wanted to plug these two nice open source alternatives. I personally (as a casual hobbyist) did not really mesh with Unity or Unreal, for different reasons but I definitely understand what they offer to both beginners and serious businesses.
For example, there are few indie games that managed to get a lot of sales because they innovated in terms of technology or ideas, like factorio or minecraft. Yet those games are pretty ugly, they're not "HD", while there are too many indie games that are HD with high poly graphics.
Indie devs don't have money, so they obviously cannot compete on the art and content. They have to make games nobody is making, and not hesitate to make pixel art or low poly content to concentrate on the gameplay. They cannot compete with big studios on content. It's too time-expensive.
This is the most important thing that people forget about games: the content doesn't matter. 3D artists don't matter. Games are not CG movies. Unless you're Kojima or final fantasy, nobody cares about cinematics. Game developers must focus on the gameplay and stop advertising about fancy graphics. This is a never-ending problem of video games since the 3D era: too much focus on the graphics, and no efforts on the gameplay, game balance, game theory, mechanics, reward system, difficulty, game lifespan, etc.
> What engines are you suggesting
If you're not aiming for bleeding edges graphics, you can use an graphics engine, or make your own. For physics and other stuff, there are plenty of libraries. I'm just saying unreal and unity are not engines, they're framework/platforms. They impose too many contraints, and you can't do everything you want with them. Not to mention the IP or business side.
Nearly every major studio or publisher has a similar toolset they've either built from scratch (RED Engine, Frostbite, Anvil, Decima, Id Tech, etc.) or license (like Unreal) and built on top of. Years of testing, R&D, and workflow refinement goes into making these toolchains extensible and useful for teams of all skill levels and functions, as well as to make them scale well to the needs of different titles.
The trade-off with these tools, is that their tremendous breadth can make working with them on complex projects their own knowledge domain for smaller teams, even as it abstracts away many of the complexities that come with developing your own engine.
If you're an engineering oriented developer who has the luxury of developing for a very restricted set of platforms and the time to debug their own tooling, with narrow, well-defined graphical requirements, a clear vision, and a technically inclined art team, then using a framework like Ogre makes perfect sense. Lightweight frameworks are a joy to work with, and you only have to add what you need on top of them to get the job done.
But iteration is slower, and you may spend months getting your tooling where it needs to be if you're going to work with a team.
Good luck onboarding new artists and game designers though. First you have to worry about training. After that, compatibility. Artists tend to have a workflow that works best for them, and even using open file formats, and established toolchains, they've got a gift for finding edge cases in your system. Your map editing toolchain also has to work for both the artists, and the designers.
Conversely, a mature engine like UE, or Unity has a wealth of crowdsourced documentation, and it's almost impossible to trip over an issue that someone else hasn't already triaged before you. New team members are almost guaranteed to know how to fulfill their responsibilities within the constraints of the engine's toolset, so they can get to iterating on prototypes much faster.
They're also typically extensible enough that the engineering guy(s) can put whatever efforts they would have contributed to designing a rendering engine, tools, and debugging platform issues into adding features unique to their title.
The featureset on these behemoths may be overwhelming, but it's more or less on par with what the 'pros' are using, so just by adopting one, you're virtually eliminating your technical capability gap with them. There is still a gap. With respect to tooling, Indies simply lack access and experience with parametric modelling tools like Houdini which greatly increase the efficiency of content-generation.
The rest of that gap can be broken down to experience, and manpower. Experience can be fixed, but few indies are able to throw the number of bodies at a project that someone like EA or UbiSoft can.
Engines allow anyone to make AAA level experiences with AAA levels of graphical fidelity now.
The output gap has become about art and content, something no indie can effectively compete with in terms of volume.
I agree that developing on large engines can cause you to hit a wall, and the engine essentially becomes the developer's world, but I think overall the proportion of people in the world who go further is the same, even if the proportion of people in the world cluelessly noodling with the low-cost space shuttle they've been given, and putting out garbage increases.
People incapable of competing have been allowed to join the market. But the democratization of engines has also given those with the potential to be great a much lower barrier of entry onto the development scene
> a mature engine like UE, or Unity has a wealth of crowdsourced documentation, and it's almost impossible to trip over an issue that someone else hasn't already triaged before you
C++ in UE4 is a nightmare to work with because you have to scour forums for a day and a half to find somebody who might have mentioned the name of the function you need. Great engine besides that, but that is a pretty big deal. Unity however - everything is the first page of search results. Incredibly valuable!
They allow it, but those indie devs don't seem to compete with AAA games. What's the catch then? I think that it's performance, game design, experience, etc. It's pointless to compete with big game studios on the same types of games.
> AAA level experiences
Sorry but what exactly is this? That's not what makes indie games interesting. And I don't think indie game devs will really achieve those "AAA" things.
Most indie gamedev projects I've seen die involve people who are primarily programmers who get stuck in framework hell. They're endlessly trying to build and tweak basic features for a basic framework, when any major engine has all of those features out of the box or with a 5 second package download.
I've had to get myself out of the habit of doing everything myself, admitting defeat, and downloading existing packages. Oftentimes someone out there has something better than what I wanted to make and easily tweakable, saving weeks of time and still allowing me to give it my own touch.
Even for a total amateur who won't use 1% of the features, Unity and Unreal have two huge things: support and a community. You can ask a question anywhere about anything and generally there's someone who can help and even give a precise solution. That's huge.
Anyone that wants to do games should use a pre-made engine, if the game is at all interesting, people will play it, even if the technology sucks.
Of course this doesn't mean you shouldn't write your own graphics engine for fun and as a learning opportunity but if your goal is making a finished game then you should avoid falling into this trap.
The only reason someone can't actually compete, is man-hours available. Some things are just very time-consuming to implement.
But this last point applies to any engine, even the ones the big studios use.
About open source, just check Godot. And Godot is a competitor to Unity, in the 'learn this engine and you will have to keep using it' market. Which I think is fine for Indies.
My son was really into Unity development for a while, but he got discouraged when they deprecated their entire networking stack without providing a suitable replacement (since August 2018) and are even removing support from old LTS releases.
For a multi-billion dollar company to suddenly take down a wiki that hundreds of man-months went into creating, that is visited millions of times each year, with no warning or archive- that is open user hostility. They can certainly afford to keep it around in read-only mode as a static site. An intern could run wget and have a mirror up in a few days tops. If there is unmoderated content they are worried about, they can afford to clean it up. This is wrong.
They seem to be a concerned parent who's mixed up.
It was their second networking stack already, and both have had been ridden with problems. Last stack's still open sourced on BitBucket, and you can choose it as a starting point for your networking stack,.
Some promises, like what Unity networking was trying to achieve - a hassle-free real-time game mulitplayer without dedicated servers - are just not achievable, and your customers are better off if you admit it. It's much worse when you buy into marketing hype and start discovering structural problems that require total rewrite close to the release.
I worked with Unity since 2009, and in 2017/2018 implemented a custom multiplayer solution for an open-world RPG game without a dedicated server. Which was originally written on that exact stack. Never had a worse burnout in my life.
> The Wiki, even in it’s read-only state, was presenting security risks, and it was deemed necessary to take it offline.
https://forums.unrealengine.com/unreal-engine/announcements-...
At the very least they could have made this open source
https://web.archive.org/web/20191212230615/https://wiki.unre...
Are they having financial problems? Surely Fortnite is keeping the lights on...
Could be a signal of underlying management confusion/instability. Might need to reassess.
Might grab a copy of the archive for reference then local host it. We've got a ton of internal references that will be broken.
We haven't touched UE for about 10 months.
Every line is fact.
It's possible that really aggressive security measures could mostly prevent that but even if you were to patch weekly that won't stop someone from pairing an undisclosed mediawiki attack with some other attack that isn't well-known. A game studio's machines are probably using LTS versions of Firefox or Chrome w/slower update cadence, which potentially means multiple days of vulnerability even after an exploit is patched.
Also, now that Epic processes credit card payments (Epic Store, etc) it's possible the mediawiki install would prevent them from passing PCI-DSS audits.
https://web.archive.org/web/20181004001430/https://wiki.unre...
Very frustrating.
Unreal Wiki must be experiencing similar trends. The real reason it was shut down.
RIP
On the opposite I once maintained phpwiki which never had any security problems, and all my known instances still work fine after decades. No much need for massive manual interventions. lots of admin plugins. XSS attacks impossible. I ran backup jobs for the DB (berkeley db was 30 faster than MySQL) and as HTML archive. So even if you have to put it down for php maintainance, you can trivially replace it with a readonly dump without any action buttons and without any PHP.
* Constant vandalism
* Dubious user created content rendering computer non functional
* Trolling edits to cause breakages to people copy/pasting shell commands
* SPAM
* Maintaining the wiki
Before that we forced users to log-in for edits, then forced moderator approvals for everything, then forced moderator approval for new account. Then gave up and retired the Wiki.
So no, wiki are not free content. They are a pain, especially when your community tend to have many trolls/hostile individuals like the gaming community. It's not "downright lies" all the time.
Indeed it is not free content, the volunteers that edited the UE4 wiki must be pretty disappointed. But Epic isn't broke and the vague reasoning they offer is insufficient to me and many others.
p.s. Coincidentally I am a daily user of AwesomeWM. Thanks for your efforts!
About maintaining wikis, that is indeed a problem. In addition, most wiki software I used has extremely clunky administrative tools which make moderation way more challenging than needed.
I used to maintain a tiny private wiki for a previous job, and even in a very small operation (10s of users), it was a disproportionately large maintenance burden.
So why can’t we put a read-only archive online currently? The Wiki, even in it’s read-only state, was presenting security risks, and it was deemed necessary to take it offline.
We still have the data, and as mentioned above, we will work to migrate the top content into various official resources. In the meantime, we’re investigating how we can make this content available, even in a rudimentary way.
Some individuals from the community have already reached out to explore a community-hosted Wiki. We are following up with these folks and are evaluating next steps to see what may be possible here as well. "
Well you always learn new ways to express incompetence. They do know that you can render wikis into static HTML pages?