Project file contains UI state

Problem Description

In a .caproj file, Construct 2 saves UI state for folders (expanded= lines). When having a project under source control (git in my case) there can be conflicts, depending on whether I had a project folder open or closed when saving. There should be none.

Attach a Capx

Cannot attach, I get the message "The extension caproj is not allowed".

Description of Capx

N/A

Steps to Reproduce Bug

• Open Construct 2
• Create a new empty project File -> New -> New Empty Project
• Save the file with File -> Save As Project

Observed Result

Folder open/closed status is saved in the project file.

Expected Result

Folder open/closed status should be in uistate.xml file.

Affected Browsers

N/A

Operating System and Service Pack

Windows 7 x64 SP1

Construct 2 Version ID

Release 168 (64-bit)

Event sheets also have this problem. If you collapse an event or group, then it writes a collapsed="1" attribute into the event sheet xml. This belongs in the uistate.xml.

I think you SHOULD save your project in a CAPX format instead of trying to upload a caproj file.

I think you SHOULD save your project in a CAPX format instead of trying to upload a caproj file.

Well, not possible if you're using git (or any VCS for that matter).

I prefer having to manually deal with some conflicts when I edit the project on my desktop then pull it on my laptop, rather than not having any serious version control at all.

I hope it gets fixed.

+1

I've already asked Ashley is this something for a bug report, got no response. It should be addressed as it really complicates work with any VCS.

> I think you SHOULD save your project in a CAPX format instead of trying to upload a caproj file.

>

Well, not possible if you're using git (or any VCS for that matter).

I prefer having to manually deal with some conflicts when I edit the project on my desktop then pull it on my laptop, rather than not having any serious version control at all.

I hope it gets fixed.

???

What I said is, save your project in capx and upload it dude, don't try to upload a caproj because it will miss all the folders and files of your project.....

>

> > I think you SHOULD save your project in a CAPX format instead of trying to upload a caproj file.

> >

>

> Well, not possible if you're using git (or any VCS for that matter).

>

> I prefer having to manually deal with some conflicts when I edit the project on my desktop then pull it on my laptop, rather than not having any serious version control at all.

>

> I hope it gets fixed.

>

???

What I said is, save your project in capx and upload it dude, don't try to upload a caproj because it will miss all the folders and files of your project.....

It defeats the whole purpose of git. Branching, merging, reverting and rebasing with 1 huge binary file?

I think there is a misunderstandement, Telles0808 asked you to upload a capx file, which will show the project in its integrity for the bug report, in this case though, it is not very useful since it is the project folder save that has the issue (even though I think the capx would have the same information too), I think he meant that the state of the project folders bar should not be saved in the main project file (the caproj one), but inside the one that is said to retain the state of the editor (the uistate one), since the change of state of the editor should not be a data to be uploaded, as it is now, the main file will be changed and upload even if it has no fundamental changes, which can be a problem when working with some source control program in a team.

I think there is a misunderstandement, Telles0808 asked you to upload a capx file, which will show the project in its integrity for the bug report, in this case though, it is not very useful since it is the project folder save that has the issue (even though I think the capx would have the same information too), I think he meant that the state of the project folders bar should not be saved in the main project file (the caproj one), but inside the one that is said to retain the state of the editor (the uistate one), since the change of state of the editor should not be a data to be uploaded, as it is now, the main file will be changed and upload even if it has no fundamental changes, which can be a problem when working with some source control program in a team.

My misunderstanding, apologies to Telles0808.

The .capx file is just a zip file, containing the .caproj file, which contains the said setting. But there's no point. It's not project specific, it's the way Construct 2 saves this setting in the wrong file, in any project you create, even an empty one, as I explain in my original post.

There is also problem with mysterious

sid="8119851569918457"[/code:3i3a7des] fields which can cause conflicts when merging two branches.

JohnnySheffield Has Ashley responded to this issue? You're right, this is a very big bug. Has no effect on one guy/girl working a small solo project, but makes team dev on bigger projects extremely difficult. And for no reason, just write those UI state changes into state xml files where they belong.

Nope, no response for now, which is kinda sad. It would be great to know what are plans for this bug, will it fall in the "wont fix" or "on todo list" category.

It's just an oversight. I didn't think it was a serious problem. When merging it's not a big deal which way you merge the expanded/collapsed state, right?

Ashley I think the problem is that the diff shows changes made to irrelevant areas since different programmers might have closed/opened different groups without changing anything. This makes it difficult to know what was actually changed.

Ashley I am working on a rather large educational game with a central game and 9 smaller games (hence the business license upgrade). The project file is 7200+ lines long, with plenty of folders and subfolders for organizing the assets. Right now, there are 176 occurences of the "expanded=" attribute. Not all of them are in conflict when I git-push them at the end of the day from my desktop and my laptop, but I have to manually check around 10-20 conflicts most times. This can be frustrating, especially at the beginning of a project when assets get added/removed/changed constantly. It's doable, I can circumvent it by running scripts and resetting everything to "expanded=0", but I would rather not have to.