makebelieve's Forum Posts

  • 14 posts

  • If you are using Node-Webkit, try setting the full path to a variable then calling Node.js directly with Browser -> Execute Javascript:

    "var fs = require('fs');fs['writeFileSync'](arguments here)"

    See the fs syntax here: http://nodejs.org/api/fs.html.

    I hope this helps.

  • I get the same error when updating to r190 and installing NW for C2, just by running the project that ran perfectly on r184. No plugins used, no changes made to the project. When I switch back to r184, everything is back to normal again.

    1) Start preview with NW. NW loads.

    2) Javascript alert:

    [attachment=2:2y9fir10][/attachment:2y9fir10]

    3) Javascript alert:

    [attachment=1:2y9fir10][/attachment:2y9fir10]

    3) NW fails:

    [attachment=0:2y9fir10][/attachment:2y9fir10]

    Same thing happens with Chrome, Firefox and IE, with the additional info (from FF):

    [quote:2y9fir10]Assertion failure: Project model unavailable

    Stack trace:

    assert2@http://localhost:50000/preview_prelude.js:16:10

    Runtime.prototype.loadProject@http://localhost:50000/preview.js:1090:3

    Runtime.prototype.requestProjectData/xhr.onload@http://localhost:50000/preview.js:376:5

    Subsequent failures will now be logged to the console.

  • I found a workaround though!

    OSX Node-Webkit does support packing all files in Resources/app.nw file instead of having them in the Resources/app.nw/ folder.

    https://github.com/rogerwang/node-webki ... -your-apps

    Moving the files to OSX via FAT32, packing them with zip, moving them back to Windows, and creating the hybrid CD, works perfectly.

    If only this could be done when generating the apps from Construct 2, it would save the round-trip to my Virtualbox Hackintosh!

  • CD's are old and largely obsolete media, and the only real answer is to be more careful mixing new standards with old standards. forward compatibility is tricky and there's always going to be unavoidable issues.

    But it's not the CD (which is obsolete, but not exactly), it's HFS+ (which is very current as it is OSX's native fs) and the way it supports UTF-8. I bet that if I put the files on a HFS+ formatted usb stick (instead of FAT32) I would have the same problem. I have to work on Windows and transfer the files from Windows to OSX, thus the problem.

    I think it's basically the way NW is set up for OSX. If all files were in a zip file instead of flat out in a folder, HFS+ would not be an issue. But I guess there is a reason for that.

    Sigh! I'll do the renames with a script.

  • In the end I used a batch file to process the lot for me.

    It's not just renaming, it's also changing the references in the event sheets, etc.

    I know how to use a find with egrep, mv, and sed, but still.

  • Well, yes I could rename all sprites, sounds, music, xml, and json files. There are 305 of them though

    Would be nice to either have a warning or a workaround.

    NW needs all these files in one zip file for Windows and Linux but for some reason needs them unpacked in a folder for OSX.

  • Problem Description

    I have created a project where assets that are saved on disk (e.g., sprites) are named in Greek. They contain accented characters as well. I then export for Node-Webkit and create a Hybrid CD (yes, a CD! but these are the specs I have). The CD contains:

    • An ISO9660/Joliet part for Windows that contains all files generated in the win32 export folder.
    • An HFS+ part that contains all files generated in the osx export folder.

    The CD works perfectly on Windows and the application starts correctly. The CD is recognized in OSX, the application starts but never finishes loading.

    The problem is the accented characters, that in HFS+ are represented in their decomposed form, but Node-Webkit tries to load them in their normal UTF-8 form.

    For example, the file 'αρχείο.png' is stored as 'αρχει´ο.png' in HFS+ but NW has a problem loading it.

    This may be a problem with NW, but I would really like to have had a warning when I started, if there is no solution.

    By the way, when I use a FAT32 formated USB drive and attach it to OSX, everything is fine. HFS+ is the problem.

    Attach a Capx

    TestwGreekChars.capx

    Description of Capx

    Shows a sprite.

    Steps to Reproduce Bug

    • Export project
    • Choose Node-Webkit
    • Use a Hybrid CD creation program like Macimage
    • Add the win32 files in the ISO part, osx files in the HFS part
    • Mount the image or the resulting CD in OSX
    • Start the application

    Observed Result

    Application starts loading and hangs.

    Expected Result

    Application should load and display a sprite.

    Affected Browsers

    • Node-Webkit: YES
    • FireFox: N/A
    • Internet Explorer: N/A

    Operating System and Service Pack

    Windows 7 64

    Construct 2 Version ID

    Construct 2 r184

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • It works!

    Thank you!

  • Should be fixed in the next beta.

    Great! I have another big project coming up so that would be really helpfull.

    Many thanks!

  • 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.

  • 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.

  • >

    > > 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 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.

  • 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)

  • 14 posts