Updating Project writes over existing C++ code

[martyj]

So I updated my LE project and the following source files were changed and the modifications I added to them was removed.

 

App.h

App.cpp

Main.cpp

 

Could we not have the engine modify our code?

 

If you change these files, let us know, but don't force a change on them. Some of us don't use the built in C++ code that calls LUA scripts to do everything

[cassius]

I think the bak files are your original files after an update, but its a good idea to copy your sourge folder before an update.

[martyj]

Honestly it shouldn't be needed. If there's a code change let me do it myself. Don't trash my code and force me to fix it via version control when I had a working version.

[gamecreator]

Not a new problem; happens every update. Leadwerks overwrites your files and restores files you deleted. I wrote a file cleaner because of this but it would be nice for Leadwerks to just stop doing it.

[Admin]

The request here is a little contradictory. You're saying you want to update your project, but you don't want it to update the files? How would you propose this be handled?

[Rick]

I think this comes back to what is being updated. The update of textures or script files may be something we don't care about and don't want. Updating the LE library of course we would want but that alone shouldn't cause main.cpp or app.cpp to change. Changes to those files we'd just want to know what would change and why. Maybe we don't want or need that change.

[gamecreator]

I honestly don't know what the perfect solution would look like but at worst, Leadwerks could scan a text file in the root that the user can populate for files to ignore/not recreate. If it has the word NONE at the top it will only update essential Leadwerks files like the DLL.

[gamedeviancy]

You could just have the project updater copy the files and change the extension before writing the new ones...

 

App.cpp -> App.cpp.bak

App.h -> App.h.bak

Main.cpp -> Main.cpp.bak

 

You could make this an optional setting in the Editor preferences for those who don't want it.

 

Edit: Skipped over cassius' post. Does the Editor already do something similar to this?

[martyj]

I think Rick covered it best.

 

Since I'm using the C++ version of the app. It's assuming that ANYTHING inside /Source/ should be off limits to be "updated/modified/changed" I'd even say not to change /Projects/ as well, as it's a pain to reimport everything into visual studio.

[Josh]

I think this comes back to what is being updated. The update of textures or script files may be something we don't care about and don't want. Updating the LE library of course we would want but that alone shouldn't cause main.cpp or app.cpp to change. Changes to those files we'd just want to know what would change and why. Maybe we don't want or need that change.

The library is always loaded from the Steam install directory, and never needs to be updated. So your description is for the update system to not update anything.

 

Since I'm using the C++ version of the app. It's assuming that ANYTHING inside /Source/ should be off limits to be "updated/modified/changed" I'd even say not to change /Projects/ as well, as it's a pain to reimport everything into visual studio.

Fair enough, but if I add a new header file in the engine your project will no longer compile.

[Rick]

The library is always loaded from the Steam install directory, and never needs to be updated. So your description is for the update system to not update anything.

 

I think it comes down to asking us if the file changed from the previous version before just assuming the change is wanted. That way if we made our own modifications we can decide to keep ours, take the updates, or even possibly merge. Really this comes down to source control like features which would really make sense for code changes.

[gamecreator]

If nothing else, could we at least please not replace deleted files? That should be easy, right?

 

I think it comes down to asking us if the file changed from the previous version before just assuming the change is wanted.

It seems like this could automatically be detected by comparing the project creation time to the file modification time.

[Josh]

If nothing else, could we at least please not replace deleted files? That should be easy, right?

How would the editor know if the file was deleted, or if it just a new file I have added?

 

You guys are basically asking me to disable the entire update functionality...so I have to ask why are you using it in the first place, if you think manually modifying things would be easier?

[Rick]

How would the editor know if the file was deleted, or if it just a new file I have added?

 

Don't you keep track of LE files per version somewhere? The server that you call to get the updates should have a list of LE files (your files you send to us) in it. If a file does NOT exist in our project then don't send it because it means we deleted it. You would need a file listing on your server per version and then see what project version we are updating and compare.

 

 

Server

=====

version 1.0 Files

-----------------------

Noise.lua

FPSPlayer.lua

Trigger.lua

 

version 1.1 Files

------------------------

Noise.lua

FPSPlayer.lua

Trigger.lua

Isometric.lua

 

 

Client updating project version 1.0 to 1.1

================================

Their project has

------------------------

Noise.lua

Trigger.lua

 

You can see that they don't have FPSPlayer.lua but the server does. This means they deleted it and so you shouldn't send it to them because they don't want it (since they deleted it). You should send Isometric.lua though because it's new since the last version they have to what they are updating to. This means it's truly a new file that needs to be sent.

 

Now let's say you changed Noise.lua from 1.0 to 1.1. If the hash of the client version is the same as the hash on the server for the old version the client is updating from then you are free to update since they didn't make any changes themselves and won't lose anything. If they are different then act like any source control and prompt for us to decide what to do. Keep ours, accept new, try to merge.

 

All of this is pretty much what source control is doing so I would imagine at some level you could just put your code files into a private git repository and just have the updater use git to manage all of this for you? I'm sure there is some git library out there that would allow you to integrate that functionality directly into the editor and you could host a private git on your server. From a source control view a delete on our side is basically saying ignore this file completely which means don't ever give it to me (in the given project only of course).

[NightQuest]

One way it could be done:

Compare file with previous versioned file (would require having a .old or having the file hash somewhere),

If identical, update.

If not identical, offer to update.

If user selects No, show them a list of changes from the previous version so they can implement them manually (diff).

[martyj]

I'm not even concerned about bringing back deleted files. It's a bit of a pain, but for the most part I ignore them.

 

As far as using the "update" functionality, I honestly didn't know what it did until I had this problem. The engine always just complained that the project needs to be updated before running inside of it.

 

Maybe what you could do for us having to delete files is not include them in the project, but allow access to them in sample projects.

 

I think for the most part, the most common use case of the game engine is to not build off of what's included, but to "Start from scratch". I don't use anything from the original LE project in my code. Everything's been customized to fit my own use case.

[shadmar]

Just use a local git repo per project. Solves all these issues, and you know what update changes. App.cpp overwritten? No problem, merge or just checkout HEAD. Same goes with other files.

[Olby]

You guys are basically asking me to disable the entire update functionality...so I have to ask why are you using it in the first place, if you think manually modifying things would be easier?

 

The current update process is not transparent. Like it or not but it just doesn't work. First, we never know which files are updated. Sure we can run diff on the project folder and the Leadwerks template but this is not something an average user would do. Secondly, there are situations when users are forced to update, for instance, when essential shaders are modified. Therefore updating the projects is important to keep up with all the bug fixes etc. But you must draw a clear line between "essential" engine files (like water, light, shadow shaders, dlls etc.) and non essential template files like FPS controller, object scripts, textures, models etc. In any case a list of changes (filename level) would really help to prevent potential loss of work. I like the suggestion of automatic diff comparison of files against the update and only push the necessary ones rather than the whole template.

[Rick]

I agree with Olby about essential engine files vs non essential files. The game related scripts are just not essential engine files and should be treated differently.

[Ma-Shell]

How about categorising the non essential files and treating them like workshop-items, so you can choose whether to include them or not.

[Rick]

Ma-Shell this is really a great idea I think. Those game lua files could very easily be 1 workshop kit that we decide if we want or not.

[drarem]

I would like to know if a fix was applied to the default App.lua or FPSPlayer.lua so I could apply it to my modified versions.

[beo6]

@drarem

i recommend using any diff application to check for changes in your scripts.

There is for example winmerge: https://bitbucket.org/jtuc/winmerge2011/downloads

but there are a lot others and some editors also include it.

 

You have to work with them anyway if you start using versioning in your projects.

[martyj]

@Drarem, I found when modifying Lua files, it's best to just create my own Lua file. So if you have an FPSPlayer Lua file you could name it like MyNamePlayer.Lua or Player.Lua and not loose your code.