Storing resources/assets using SQL or NoSQL database avoids all kinds of corruption of projects, assets, datafiles, so why Epic has not done it yet It’s quite obvious what needs to be done decades ago.
It will also help to make it super easy importing assets between old and new projects without any problem.
The one major Issue everyone faced with the current data saving mechanism is you can’t import assets from UE4.27 to UE4.26.
Using SQL or NoSQL will solve this versioning issue.
You would have to have some form of query interogation system, like PHP has where you can query in the Sql DB, fields, rows and so on.
Plus the access time is a factor also, but I would not be surprised if you would find a custom plugin that did this, with a query system of some sort written in python.
The sql server is not made to respond in real time fps I think, it’s pinging, because the language that is accessing it is server side. You will get a ping because the language is on the other side, communicating with the user interface and that takes like time, like comunicating with HTML for example to translate to user browser interface that is on the other side.
You would have to have a seriver of some sort somewhere that is turned on on a socket maybe.
I am talking about the on working projects not compiled ones, it will definitely save lots of communication problems between two engines on the same machine.
You still need a feed from a server, sql data base resides on sql server.
Maybe there is now like a system where a database of such structure does not need a server, that I don’t know. It needs a server because the server offers the format for it’s structure, it has ports sockets, channels to the DB and you need a server side type of langauge I guess to interogate the data base, and that type of language only operates on the server, not in the browser or in an interface based structure, but it returns results there to the user interface.
That is why I was saying that it’s access time might not be great.
If you have the original assets, you just… import them. If you don’t have the original assets… well, that sucks.
I don’t think “everyone” faces that issue, there’s not really much of a reason to go backwards in versions, and it’s been a looooooong time since package data formats broke.
While there are advantages to what you propose, retooling the engine to load everything from a database would probably be a pretty lengthy undertaking to solve issues that aren’t really related to what you suggest, but also still aren’t really issues that really need to be solved.
It would not prevent corruption of data (the database could just as easily get corrupted), it would not implicitly improve the loading of assets between different versions of the engine.
Version control systems quite handily work for things like this, though.
It’s why I back up my files, my source files, my content folder.
There was a guy here really crying that he lost everything, he said he worked a lot on his project and now it’s all gone.
So if you base your work on blue prints, and it’s all gone no where to get it back.
with C++ you just get your source files and rebuild, your content backed up.
No Problemo.
I just delete the binary folder, the intermediet folder and hot build , and behold all coruption is gone from the source files.
I am currently in Trouble importing an open world map from v4.27 to v4.18.
I have a project in version 4.18 which uses a plugin to support the master uplink for multiplayer servers, this plugin is not updated for +4.18 and I am not able to import the map from 4.27 into this project.
I have to reinvest months in creating this open world map in 4.18 , its about 16x16/km .
This is not hard to install an virtual server on the same machine such as WampServer or WampServer even I use them to develop large websites in offline mode, perfect choice to use with any application for processing SQL or NoSQL databases .
Well, you should have made the map in the version you were going to use.
Anyway, open the map in the project it’s in, hit Select All, Copy, switch to the editor you want it in, and hit Paste.
Version control!!!
I’m very bad at blue prints eblade, so I need to improve three , I don’t even know what version control is , lol
Version control are systems like Git, SVN, Perforce, that you use to keep an archive of the changes to every file in your project. With any version control system, you can always rebuild exactly what you had at any point in time (assuming you checked in your changes to it, at least)
Why I should?
I would say Epic should remove this versioning at least for the maps…
I have a project in v4.18 and it has a voice chat plugin which is only supported by 4.18 and I got this plugin by luck, it costs 600USD if will buy it for the newer version of UE.
Believe me epic should release an external tool which can recompile any asset for any engine version you wish to make it possible to import any new version assets in the older version.
I have tried to export the map as .fbx and the export was successful and I tried to import that .fbx in the v4.18 and the engine denied to import the big fbx files, its about 9GB, while importing the map the machine is out of memory… I don’t know why these simple things are so complicated
Because it’s not that simple.
The way to do that is Select All, Copy, and Paste to the old version.
That’s why you should do that. Because that’s the correct way to do it.
If you want to find out what happens when you remove the versioning, go into the engine source, disable the version check, and build it and see what happens. Find out how simple it is, or isn’t.
You have access to the entire engine source code, if it’s that simple, go for it.
If it helps you locate it, it looks like PackageFileSummary.cpp is where you want to go to try to do that.
I will give it a try and it will need to build the engine again which is a pain and I think I will be rebuilding the engine many times if something goes wrong
That’s because it’s not that simple to do it Open the editor in 4.27, open the map, select-all, copy, open the 4.18 editor, and paste.