I've been using Esenthel Engine for 4 years now and I must admit it's an awsome engine.
Though, I'm still using Esenthel Engine 1.0. I would really like to buy a license and change to Esenthel 2.0 since it has more features than the previous version, but there are 2 things that keep me from doing it.

1. Lack of possibility to use file names
I understand that you added converting file names to UIDs to ease the process of creating games for some developers, but for complex projects(especially the one which are having many procedural(not hard-coded) features) it's a huge inconvenience. I have many codes that I developed throughout past 4 years and they all depend of having file names and own directories structure available.
I'm not asking you to remove current system, but to add possibility to use editor the old way with saving to where we need.

What is more, I'm not alone in this request. I've seen threads like this already on Esenthel community.(Example: http://esenthel.com/community/showthread.php?tid=7457)

2. Putting all the files in one PAK when publishing the game
It's a huge problem for big projects. What about an application that weights ~10GB. It would have awfully big pak. It's not efficient and doesn't looks good. If we look at professional developers with years of experiance, we can see that they never store all the data in one package. Especially in big projects.
It wouldn't be a problem, if I could use my own directories structure and file names since I already have developed a complex publishing tool for Esenthel Engine 1.0.

The same as before, I'm not alone in this request. Other developers discussed it with you in this thread: http://esenthel.com/community/showthread.php?tid=7470

To sum it all up, in my opinion this two features would make a GREAT addition to the engine making it suitable for everyone. I'm not asking you to do this for free(Although it would be VERY nice ), since Esenthel Engine is a commercial project of yours, but you can set up a contribution and I'm sure it would be a success.

Thank you for taking some time to read my thoughts.

Regards,
Kacper

I second this.
If such contribution appears, i will take part in it.

1) I recommend getting a license, then you can use Editor Network Interface
http://www.esenthel.com/?id=doc#Editor_N..._Interface
which will solve all of your problems

You can already get folders/structure with the current system when enumerating the elements with the mentioned functionality.

http://www.esenthel.com/?id=doc#Project_Files

2) you can always PAK the files by yourself through codes, in whatever way you wish

Thank you for your response. Editor Network Interface is not exactly what I'm looking for.

The main thing is the possibility to use the editor the old way. If you could only add saving to file(which location we are able to choose) for every element(Material, Meshes, Worlds etc.) it would be enough.

Please, add this since it would be a greate addition to Esenthel Engine 2.0 and as you may see I'm not the only one interested in it.(And willing to contribute to get this)

I third this.

From a development point of view, if you want to use third party tools for managing code or assets it can make everything very difficult to manage and manipulate data in it's current form for UID for file names. There should be a option to store the name of the UID as the filename as an alternative to the current system.

I would very much love to see this as well.

From what I understand the UID approach was chosen so that moving/renaming the files would be simpler, but it actually complicates things significantly for any bigger project. Normally, the move/rename problems would be solved by a tool that keeps the path history and updates all references (search and replace on all project files).

Now, I understand that this has already been implemented, and it might not be easy to bypass it. In that case, I think an option to export all project files (with the paths like they have in the project), and the option to import a certain directory to a project, replacing existing files but keeping UIDs could cover most uses.

So, suppose I want to run a third party tool on some files in the project.. I could do:
- export all to $somepath
- run tool on $sompath
- import $somepath to project, overwrite all files.


While on the subject, I'd also like to request a way to use paths to get the UID in the code, sort of like this: If that is too complicated to implement properly, an option to export all path-UID pairs to a text file would work as well. Then I can write a tool that parses that file, and generates the above macro/function..

I have stayed out of this conversation for a while but I guess i will chime in. I am pretty sure the reason the engine uses IDs instead of file names is only partially due to the fact you can easily re-organize your files. I assume it also makes the collaborative development possible which is a feature i think is really cool and sets this engine apart. I would also not be surprised if having files as IDs makes compiling for multiple platforms much easier as well (could be wrong though).

All in all, I feel once you get used to using the file IDs, it makes things much more simple. I personally like it and have not seen anything that it prevents you doing. If you have specific needs, it seems like those can be address with the export tool that is built in and the network interface. Even exporting for debugging includes the name of the element as a comment which is really nice.

Just my 2 cents.

(03-12-2014 07:27 PM)Ozmodian Wrote:  I would also not be surprised if having files as IDs makes compiling for multiple platforms much easier as well (could be wrong though).

Why do you think so? IDs are decoded into filenames(like "535k23498bhl32y980p32") which are the names of files stored on HDD.

Maybe a good solution would be making a class that handles IDs with customizable names. It would have a map which will pair IDs with file names, and then we could set if we want to use editor-generated names or original ones.

I felt the same way at first about upgrading to EE2.0 due to the filesystem. However after biting the bullet purchasing a licence and making a few changes to my code it is mostly a transparent issue. The way I handled it was to connect my toolset with the EE Editor and query all of the files which were written out to a sqlite file system table that held the file type, original filename, editor name including folder structure, and encoded id filename. Then my toolset queries the table by file type and retrieves user friendly editor name strings to display to the user and retrieves the encoded id filenames from the friendly name when being used to load files or saved to an entity data file. In a way this way of doing things made my toolset more user friendly as now instead of a bunch of file dialogs i now have drop down boxes with only the files that apply to the field.

You will have to modify any external api's open/load to convert a user friendly string to an id encoded filename as well. Some work would have been needed to be done anyways if you planned on using pack files with external apis.

In reply to the use of third party tools what you should be doing is:
- Add file to EE Editor keeping both the original file and Editor files.
- Run tool on original file.
- Right Click file in editor and reload file from source.

My workspace is:
|-EE Projects
|--SomeEncoded Directory Name
|-Raw
|--Project Name

I personally keep the Raw project files in the same directory structure as i have it in the Editor.

You should never get rid of your raw files even if the engine holds engine specific versions.

As for your pack file concern, if I'm not mistaken you should be able to mount as many pack files to the engine as you want. You should be able to separate out file files however you want. I was also under the impression that the pack files had some sort of priority when being mounted where if you had a duplicate file the higher priority pack file's file would be loaded instead allowing you to patch individual files in a much smaller patch pack file. If not that would be a much appreciated addition.

Just want to put in my agreement with Ozmodian. Think it's just fine the way it is. Not trying to hurt the chances of this feature request getting on the roadmap. I just think it's important for all views to be expressed in regards to this topic.

I'm not asking to remove current ID system. I'm just asking to extend it.