Jase00's Forum Posts

  • For what it's worth, I recommend NOT using the desktop build of C3.

    I was in the same mindset of "Nah, no browser". The desktop build had a critical issue sometimes, where it would randomly close (even if you haven't saved), and I lost huge amounts of work/time. Sometimes these crashes would then force you to clear your appdata folder for C3, thus spending time logging back in, installing addons/themes/setting preferences... Only for it to crash again randomly and repeat the same steps.

    Chrome, with no browser extensions, has been very reliable over the past 4 years!

  • The bug here makes me nervous for the weekend, as I know I would subconsciously "Clone" things at times, and risk crashing C3 (I checked and also get crash):

    github.com/Scirra/Construct-bugs/issues/8338

    Before I knew of this bug, I had already moved to the beta and continued working, made a lot of progress (and have earlier backup of old version, for worst case).

    I however don't want to risk the crash occurring, so I "edited project file, reverted back to r416". Spent few mins testing, seemed fine, made 2 or 3 changes including animation rename, 2 new events, hit "Save", and the save locked-up on "Working...". I waited a while, no difference. Closed and reopened C3 still in r416, but turns out my project corrupted and cannot be opened (but of course I have backups, phew!)

    I tested again (got my r417 backup, downgraded again, made different changes), but thankfully did not have same save issue and project did not corrupt. Checked HDD space, all healthy. Never had issues with save like this before. Unsure why/what happened, may not relate to downgrading, but as mentioned, never had such save issues ever, in years of using C3. (Chrome, no extensions, no VPN, no new things on PC, can save fine in both versions still).

    I think I will stick to r417 in this case as the risk is much less and I rather not use old backup and redo work I have recently done, but I would be eternally grateful to see a hotfix for this "Clone" crash, before the weekend commences, if possible at all?

    I wouldn't usually ask, but just on the case of "Clone" being common and ingrained in my workflow, and feeling too risky to backport and corrupt my project (whether this was a rare unrelated save issue or not, I am not sure, but if related, definitely do not want other eager beta users making same mistake as me).

    The red crash screen certainly sends a shock of "OH NO" down my spine, so anything to avoid this is greatly appreciated - Having Diego recently solve the "bookmark bar" crash has been ethereal to be able to use bookmarks without risking a red crash screen! I suppose I could be testing the r417 crash screen when cloning, maybe the "Save project" button works fine (although it makes me nervous since, what IS it saving in the red crash screen, the cloned broken object? Maybe it's ok, maybe not).

    I hold my hands up that I could have tested more correctly before moving to beta, and it's not on Scirra to fix my own choices, but wanted to try asking just in case it is feasible.

    I always use beta, always have backups, haven't lost work ever (or never a significant amount)!

    EDIT: I tested r417, cloned, crash, "Save projects" from crash screen, opened, and seems fine, doesn't include the cloned object, but of course not sure what damage might occur. The downside though, is, I use "Folder Save", and measuring time to "Save project from crash, open c3p file, save as project folder again" takes about 2 to 3 minutes to do. I do not look forward to encountering this bug many times over the weekend, piling up to be many minutes of time lost, along with nervousness if the recovered c3p file is broken in any way.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I agree with much of this!

    I am 4+ years into a project, with NWJS events scattered everywhere. I attempted to design my project to keep file operations inside common functions, but that failed over time and file actions are peppered across the project. I foresee it being a journey to replace all nwjs events, but of course this would be much more easier if FileSystem was not Async (or had option to choose from async or not), as this could be a near-direct-replacement easily if actions and such were not async.

    However, async isn't inherently "bad", but it's certainly not easy to "move over" to in a current project, and requires different forms of design/thinking when planning your systems due to async. Doable, but a lot of effort and can be a lot more advanced to design. I would disagree if it was the case that "It should have always been async, therefore going forward it will only be async", I think choice and options are good, I do agree that it's ideal to use async, but it's not "easy" per say compared to non-async, so having the choice feels far more desirable - I can see myself using both async/non-async for different systems in my project. Let the devs realise that "non-async with big file operations may freeze your game", but this may be rare/non-existent for most devs, as small file operations would occur most of the time, plus I doubt beginners would be attempting filesystem operations with huge files as their first projects and can be pointed to the other option when they ask for help. Choice is good!

    I am also a "advanced level editor" kind of person - Only needing access to a folder in "Documents", but lots of paths, folders, subfolders etc.

    I explored filesystem in past, but haven't recently (although was ramping up with excitement with seeing updates and seemed to be parity occurring between nwjs and filesystem plugin).

    I believe that filesystem/webview adoption could work out better if there was exact parity AND something else tempting (random example: what if file-system allowed zipping/unzipping - Something new and desirable to make people "want" to move to WebView2). In current form, I foresee "Lots of work to move to filesystem, to then use webview2, which has murmurs of issues occurring". Whereas, if extra features were offered for WebView2 that are desirable and cannot be achieved in NWJS, then that may sway many devs into using WebView2, even if there's a different set of bugs to deal with. I'm not aware/creative enough to think of possible features, the ZIP one would be amazing (there's old third party one, ironically NOT async and locks-up game when using and breaks on Worker Mode), and personally a ZIP feature, even if just for Windows only and not Mac/Linux, would immediately motivate me to move to WebView and rewrite all my NWJs events to handle async, without a doubt in my mind. This is a not-so-subtle suggestion but I promise I'm not trying to be cheeky, I think ZIP stuff relates to the topic, as advanced users of file operations may wish to zip level editor files and such to make it easier to distribute mods/levels/custom content, rather than utilising 3rd party software or asking players to zip it themselves. Then players can drop files onto the game, WebView unzips wherever we wish, boom, done, mod support! If "ZIP" stuff or other features could be a general HTML5 implementation, then WebView could still have features to benefit from it, maybe allowing "If you open your WebView EXE with a file parameter, then pass the file paths into the game if it's already open, or open the game with the paths", allowing devs to make custom file extensions for their "mod" files (AFAIK NWJS does not support this as of now, can't open NWJS EXE with a file path and feed this into the game, nor detect if game is already open when trying to open EXE with filepaths and feed paths into running game).

    One thing I like about FileSystem is that it "auto-creates a folder structure", if you enter Documents/Test/A/B/C/, it creates each folder instantly, that's a great benefit!

    In fairness of WebView2, although again, not certain, but, perhaps it is viable in it's current state - So long as you can indeed "list contents", even if many times, then collecting an array of paths is doable (Not sure how easy it is to then revisit a path and such, much like NWJS being instant/easy).

    I think the export option should have a "Bundle with WebView2 Version", much like NWJS does - I immediately have 0 interest in an auto-updating WebView2 system - I hate to imagine waking up one day, and game on steam dies on many computers due to a WebView2 update. Sure, this could happen with any windows update, but it would make WebView2 games stand out when all other Steam games are fine, basically rendering "only C3 games" breaking on Steam. I have 0 interest looking into a "Manual" solution to bundle WebView2 versions and such, the convenience of the build service offering all versions of NWJS is extremely helpful and easy - And I'm a long term user, I can imagine beginners wanting the easy route more than me!

    I am mixed on how to determine whether to move to WebView2 or not, and do have fright from NWJS getting stuck on a LTS version (as I always use beta), but of course I don't foresee NWJS disappearing if WebView2 hasn't reached a close parity (which it is certainly approaching).

    EDIT: How far can WebView exports be expanded upon with plugins, in sense that, if there were hard-limits with FileSystem API and it "must" be async, "must" list files before checking they exist, and "must" have certain rules in place, could a Scirra-made C++ extension bypass some of this?

    This could allow for parity with NWJS plugin, and perhaps other desirable features for benefiting a WebView export, like setting menu bar options and such (much like the nwjs plugin has)?

    I recognise the desire to keep all file operations under 1 plugin, and it's a fair philosophy to follow, but if it dampens potential for specific exports, that would be a shame. We know that FileSystem plugin doesn't work for Android as of now, but if there was a way to have an alternative method for Android filesystem access and it was in demand, I'd predict Scirra would support this anyway, even if temporary.

    Maybe the FileSystem plugin could detect that it is a WebView export and utilise the C++ extensions without the user's knowledge. I would even take a "WebView" plugin that has it's own set of FileSystem actions and such, much like NWJS currently does - Even if this is a step back at compacting all file operations into 1 plugin, I think this is a excellent way to keep parity, allow choice for devs.

    I know it may be a back-n-forth with the history of WebView, where there was already a unique plugin for file system stuff, which is now removed, which may then return, BUT it could aid with eliminating NWJS, get more on board, wouldn't affect anyone that currently uses FileSystem plugin and their async systems will continue to work, and could open extra doors/features for WebView exports to make it desirable to move to WebView2, overall encouraging devs to want to move to WebView, rather than that they have to move.

    WebView2 clearly is the best path forwards and gives Scirra the most control they have ever had over desktop exports - I feel the excitement, and it's close to being a no-brainer to switch over to.

  • For ProUI, I believe this was handed to the community by the original developer, and the community has fixed it for the latest C3 versions.

    Download under "Latest Release":

    github.com/ConstructFund/proui

  • I guess that would be an action like "Randomize pitch", then set the range like 0.6 to 1.4?

    Though that's exactly what "Set Playback Rate" does and it's only 1 action, too. Can throw in random(0.6, 1.4), or if only specific pitches, choose(0.6, 0.8, 1, 1.2).

  • Had a list of feature requests I was thinking to submit, but I guess I wanted to check if they're "theoretically possible" before writing them all up:

    1. Getting collision point coords, and defining custom collision polygons in events.

    2. 9patch having mesh support.

    3. 9patch having "load from url" support (and setting margins in events).

    4. Setting a dynamic layer to 3D.

    5. Adding effects to dynamic layers.

    6. Having multiple "cameras" or viewports, for things such as split screen or a 3d game with a rear-view mirror. (drawing canvas proved to be bit laggy for this).

    7. Add/change image points in events.

    If some are impossible (or are an enormous amount of work requiring major changes to C3 and maybe still discovering it's somewhat impossible) then I'd put those thoughts to rest and move onwards, just wanted to save time in submitting it all if they were hopeless to begin with - had them in mind for years but haven't submitted yet. Some of which are what I'd consider the "last pieces for making a fully moddable game" - currently I believe C3 is very powerful in terms of modding support as it stands, just few remaining things, some of which are able to be worked around, but some cannot.

    Even just "yeah all are possible" is fine, but always happy to see deeper explanations! (no expectations, can wait and see if enough votes reach each one and discuss further).

  • Put all your click-able objects into a family, then you can setup your events like:

    On click FAMILY

    Pick top instance of FAMILY

    You can find "pick top instance" within an object, like Sprite>Pick top/bottom, or Family>Pick top/bottom.

  • Do other webapps have same issue, I guess a comparable one to test could be gdevelop as that's web based.

    No other issues with network, downloads, websites?

    Can join online games fine?

    Speed tests reporting normal speeds?

    Tried different servers on the vpn to maybe bypass this issue (assuming you can pick various countries and such)?

    I did have a look online as I'm sure you have already done, very unusual and seeing repeated "clear cache" which of course you did early on. Hmm.

    I found another suggestion online, not sure how comfortable you'd be to try, nor can I advise exactly, but you could analyse your network traffic with Wireshark and see if your requests are malformed. It's tricky to explain further, not sure what you'd be looking for, or how would you know what traffic should look like if it is indeed malformed.

  • Hard to say but it's working over here, and judging by you trying 2 browsers and the error being 400 which is "bad client", I'll take random guesses you may already have tried. Maybe it loaded last cached data but then you saw red error in C3 due to not being able to fetch newest data for update, then you cleared cache and now it has no past data and the issue worsened.

    Antivirus software suddenly interfering, or any kind of software that helps with privacy.

    Extensions (doubt it unless you happen to use same ones on both chrome and edge).

    Do you use a vpn or a custom dns server, maybe those are affecting it.

    Make sure to restart computer after changes.

    Oh and, if on windows, open command prompt, type: ipconfig /flushdns

    Reboot after just in case but can always test right away.

  • It's tricky, I wouldn't have thought 20 objects would slow down with this For Each event.

    It does seem laid out as best as it can, as the "for each" needs to be there to individually check each Shooter against the family, which may be different for each shooter.

    Typically it's best to try and design game to be kinda "functional", meaning: Does your game really need to be checking alllll the time for all shooter objects to aquire a target? Or could this be lowered a lot more by including some conditions above the "for each" condition, such as "is onscreen" if you have a big layout with screen scrolling, or maybe designing a way to "disable" shooters that are too far away and therefore lighten the cpu usage of this for each loop.

    P.S. I see you post a few times asking for help so wanted to suggest: There's an unofficial Discord for Construct, with help section for both c2 and c3, tends to get a good mix of replies quite quickly and sometimes from many people giving their ideas and thoughts (depending on who recognises the issue and such!).

    discord.gg/construct-community-116497549237551109

  • Maybe there's confusion about the thread linked:, that thread is about nwjs, which is an EXE version of a html5 games, usually would find these to be distributed via steam - steam having a paid entry fee and someone who attempted to upload a malicious game would lose money and be banned for ever attempting that, never once heard of it happening, so that's the reassuring case for an EXE downloadable html5 game.

    If someone, even an adult, downloads an exe from a friend or unusual website, and they aren't familiar with computers, always used admin account, AND it happened to be an extremely new malicious method that Microsoft haven't seen before (Where Microsoft have dedicated team who are extremely vigilent about updating Windows defender regularly), then yeah they may have their computer compromised.

    A html5 game in the Web browser, like oosyrag mentions, is safe, a lot safer than an exe file, Web browsers have many manny protections in place, many restrictions (cannot run exe from html5 Web browser game).

  • Also a malicious exe would often be more dangerous when it has admin privileges (I.e a window will appear asking for the admin password for the computer before it runs). Of course there's occasional exploits found that could be malicious even without admin password, but as long as Windows is kept up-to-date, you're often safe.

    A child shouldn't be admin on a computer as a child could do some wild stuff like delete system files themselves and such.

  • You can, at least with nwjs!

    You add the nwjs plugin to your project, then can use 2 different actions, "Run file" or "Shell open".

    Note, you must export with nwjs to test this, or use the remote preview tool to avoid having to export (this tool can be found here: construct.net/en/forum/construct-3/general-discussion-7/construct-nw-js-desktop-app-131317 )

  • Lolol, excellent write up with visuals! Just wait until uglypenguin sees all this and just quits game dev for good.

    Honestly though we promise it is easy once you are familiar, but our descriptions and tarek2's visuals are to help comprehend it all.

    Ask away if unsure, also feel free to join the unofficial Construct 3 discord server if you want immediate feedback for little questions at all: discord.gg/construct-community-116497549237551109

  • Oh boy, using the Dictionary plugin is very useful for your case with a level editor!! I'll answer in great detail as I am also working on level editor stuff and it's enjoyable to make and think about! Grab a glass of water and regret ever asking for help!

    Dictionary

    Think of it like: Dictionary is very similar to Instance Variables. Dictionary is a list of "Keys" (Keys are like an Instance Variable's name) and a value that you choose what data you want to save, strings and numbers can be used. So yeah it's just like Instance Variables but with extra power, and keeps all this data in one place.

    So for example, in your project, lets use a Dictionary to store all the bits and pieces of data about the level such as the "Level_Name" and other data maybe like "Version" or "CreatedBy" depending on what you need.

    To store data in a Dictionary:

    1. Add a Dictionary, rename it to what you want like "DictMapData".
    2. Go to Event Sheet and Add new event.
    3. In the new event, add condition as a test like "On SPACE key pressed".
    4. Add action DictMapData>Add Key, then key name to "NameOfLevel", value to "TestMapLol"

    Can then add a Text object as a test, then add one more event to like "On G key pressed", then Set Text to DictMapData.Get("NameOfLevel")

    Now run the game, press SPACE, and yeah, text gets set to "TestMapLol" so we know the Dictionary has stored the name of the level, woo!

    Other Dictionary notes

    You can download this dictionary the same way as you have done for the Array, load the same way. It downloads all that data as 1 file, nice and tidy!

    Add hundreds of keys if you wish, it performs excellently! Could add keys like "Version", "CreatedBy", add more events to set/get data from TextInputs that the player types into and such.

    Could add other cool stuff, for example, with Date plugin added to your project, you could do action for Dictionary: Add key "DateOfLevelCreation" with value Date.Now.

    You can then set a Text object at any time to Date.ToDateString(Dictionary.Get("DateOfLevelCreation")) and this will display the creation date of the map to your players.

    Image files can technically be stored in the dictionary if you ever need that sorta thing (Maybe you use images for an icon of the map, or custom sprites/backgrounds) but I'd say it's preferable to keep images separate, because: In order to store the image, you need to convert the image into a value that can be stored in Dictionary which is either a string or number. There's a way to convert image into a string, known as Base64, by using the Cryptography plugin. But problem is, those strings are HUGE and don't wanna slow down Save/Load and player sees the game lag, or worse, there's so much image data that when you load it in all at once, it crashes the game. Maybe 1 or 2 small images are fine. To be fair, haven't tested it much, maybe its fine to add images to Dictionary, it is probably a good method for a Website-based game if that's what you're goal is.

    Saving big lists of items with an Array

    In a level editor, you'd have things that the player can endlessly spawn. Maybe it's ingame objects, coins, spikes. Maybe your TileMaps if there are more than 1. This is where things get more tricky as you have to deal with Arrays, but overall it will make a lot of sense once you use them long enough.

    Array is more or less a grid of data. 1D being a list, 2D being a grid, 3D being a...3D grid.

    When using the actions in an Array object, it can be a little confusing, like "Push" and such to add values - You can use these if you wish, but I will use an alternative method as I feel it's more "readable", using "Set Size Of Array" and "Set Value At".

    1D

    Basic list of data, an Array with size of 5x1x1 is essentially "A list of 5 bits of data I want to store". As Array's work with index numbers you write data to the Array at X=0, X=1, 2, 3, and 4. Maybe you write a shopping list with this: Set Array X=0 to "Bread", set Array X=1 to "Lemon", etc. Very basic type of Array.

    You might be able to use this for your TileMap objects if it's literally just the TileMap JSON data needed and no other data:

    1. Add new test event like "On A pressed".
    2. Add action Array>Set size to 0x1x1 (this empties the list so we can start adding)
    3. Subevent under "On A Pressed".
    4. On subevent, add "For Each - TileMap".
    5. On subevent, add action Array>SetSize to X= Self.Width+1 , Y=Self.Height, Z=SelfWidth
    6. Add another action Array>Set Value At X, X=Self.Width-1 , to value TileMap.AsJSON

    Done, so say you had 6 TileMap objects, and you press the A key, the result will be the Array reaching size of 6x1x1 , and each list item is the TileMap's JSON string.

    You can then load by making an event: Array>For Each X, then action: Create Object TileMap. Another action: TileMap>Load From JSON and type Array.At(Array.CurX) as CurX gets the Current "For each" index. This loop will check X=0, see the TileMap data, load it in, then the next part of the loop checks X=1, see the TileMap data, load it in, etc.

    2D

    Lets go to 2D Arrays, lets say size is 5x10x1, this can be thought of in two ways: Either "This is a list of 5 "groups" of data with 10 properties", or "This is an X and Y coordinate grid". In the case of saving a list of objects and data, we will think of it like "A list of 5 groups of data with 10 properties".

    A 2D Array is a good path to take. Lets assume we want to store 5 pieces of data per object. Your Array would start at size 0x5x1, as we have no object data stored yet (0), and we have 5 pieces of data we wanna store about the object (5).

    In your mind, or write this down, but you want to "map" each number. As we want to store 5 pieces of data, we need to decide what we want for each index from 0 to 4 (Seems strange it goes to "4" but think of it like index number 0 is actually storing data, so we still have 5 properties, but it just starts at index 0 and ends at index 4). So as a random example, I will plan that Y0 will be for the "NameOfObject", Y1 will be the XPosition, Y2 is YPosition, Y3 is Object's colour, etc.

    Follow similar events to the "1D" example as written above, but instead of "Set at X", you can use "Set at XY", then the X remains as "Self.Width-1", and the Y can manually be typed, lets say 0 because we want to write in the "NameOfObject" data, then set value to "TestObject" or "TileMap" or whatever. CopyPaste this "Set value at XY" action, edit, change the Y to 1, we planned earlier that 1 will mean "XPosition", so we can then set this value to TileMap.X. etc etc etc.

    The loading part is similar to 1D, too, we still only need to do a "For Each X" for the Array, but we can do extra stuff now in this creation event, so could edit the "Create Object TileMap" action to update the position correctly and set the X position to Array.At(Array.CurX,1) and Y position to Array.At(Array.CurX,2). Tada, this makes the TileMap load to it's correct position!

    I will skip 3D Arrays.

    Use both Array and Dictionary for readable and expandable level editor data

    Once you are VERY familiar with all of this, the ultimate wombo combo you could do is a combination of a 2D array AND Dictionary. Will go light on detail:

    You can add many Dictionarys, maybe you add them for each Level Editor object and use them as an alternative to Instance Variables, so each Enemy object gets it's own Dictionary and stores Health, Ammo, Type, Colour, and other customisable pieces of data.

    The benefit of this is: You could have your 2D Array be 0x2x1, and we will plan the Y=0 to be "TypeOfObject" and Y=1 to "DictionaryAsJSON". Then follow the example written in the 2D section above, but simply load this dictionary in for each level editor object with 1 action, and now you have an easy-to-use Dictionary and can get data from Key Names rather than "memorising/reading notes about the Array to remember what each Y index is supposed to mean", or else you may be like "Was index 12 the colour of the object? Was index 33 the angle of the object?"

    Download/Save/Load stuff

    I notice you use "Download" for the Array (and you would then use Download for the Dictionary), which is good for a game that's going to be uploaded onto a website or for Mobile devices. For desktop/EXE/Steam games, the "preferable" way would be using the FileSystem/NWJS/WebView plugin, letting you have a "Save to" window popup and such if needed, and also being able to write files directly to the player's computer without any popups (With "Download" the Dictionary data always goes to the player's C:/Downloads folder, but with these plugins for desktop games, the player can choose the location to save, or you can design you game to automatically save in any location on their computer).

    Hope this helps and good luck!