fisholith's Forum Posts

  • Okay cool, that makes sense. I figured it had to be that I was just overlooking something.

    I'm pretty sure my version was behind because, through a combination of random chance and me just being kind of dumb across several days, I somehow never thought to reload the C3 Chrome tab I'd been using as a sandbox for testing script related stuff.

    I also just saw that there was even another Stable release, that came out a week or so back, that had the Platform Info update. And in hind sight, I'm pretty sure I actually had that version open in my main project Chrome tab, right beside the outdated sandbox tab. Ironically, I didn't test in the main project tab, because I hadn't gotten it working in the sandbox tab yet. With work split up across several days, I think I may have just been generally aware that I'd updated C3, but it didn't occur to me, later on, that it was just my main project tab, and not all tabs were running the same version.

    Anyway, thanks again Ashley and R0J0hound.

  • Thanks Ashley,

    When I loaded your example, I got a prompt that the version I was using (r388.2 stable) was too old to open the file (made in r398.2 beta), so I enabled beta releases in the construct settings, and got r398.2 beta.

    In r398.2 beta, your cp3 previews correctly on my computer, and in Chrome dev tools, runtime.platformInfo now shows up in the debug view as expected.

    It looks like my C3 version was just behind enough to be missing the runtime.platformInfo script interface.

    As a test, I created a completely blank project in the newer r398.2 beta, and runtime.platformInfo is present as a property of runtime, even without adding the Platform Info object to the project bar. It shows up between mouse and ticksPerSecond.

    I then returned to an instance of the older r388.2 stable, and even when I add the Platform Info object to the project bar, runtime.platformInfo doesn't appear to be present as a property of runtime.

    So I think it may have just been a case of my version not being up to date enough.

  • Hey R0J0hound, thanks for the reply.

    That's what I thought initially, but I've also tried evaluating those same lines in the middle of the tick() function, at which time I'd expect everything to be loaded.

    I basically just modified the tick function as follows,

    let tickCount = 0; 
    function Tick(runtime)
    {
    	console.log( 'Tick()' );
    	if ( tickCount === 0 ){
    		
    		console.log( runtime.platformInfo );
    		console.log( runtime.objects.PlatformInfo.getFirstInstance() );
    		console.log( runtime.objects.PlatformInfo.getFirstInstance().os );
    		console.log( runtime.objects.PlatformInfo );
    		console.log( runtime.objects.PlatformInfo.os );
    
    	} 
    	// Code to run every tick
    	tickCount ++;
    }

    I get the same output as in my original post above,

    // undefined
    // [object Object]
    // undefined
    // [object Object]
    // undefined
    

    (just copied this from the console after running the modified code above)

    and I still don't find any sign of the "runtime.platformInfo" property.

    Likewise, I've used Chrome dev tools to pause mid tick(), and on inspection of the objects returned by these two expressions,

    runtime.objects.PlatformInfo
    runtime.objects.PlatformInfo.getFirstInstance()
    

    I still don't find the property "os" owned by either object, or any of their prototypes.

  • Solved:

    Solution

    I updated C3 to the most recent version, and the Platform Info script interface now works as expected.

    Problem

    Without realizing it, I had been using an outdated version of C3, that predated the addition of the Platform Info script interface.

    Cause

    It was me all along! My C3 version was out of date as a result of my having left the same C3 Chrome tab open across several days. Without refreshing the tab, the version fell behind. I'd updated the C3 version in an adjacent tab at some point, and didn't realize later on that I then had multiple C3 tabs open that were running different versions.

    Original post:

    I'm trying to use the "Platform Info" script interface to determine if my project is running in a browser, or in NW.js.

    I can't seem to access or interact with the platform info script interface at all.

    I assume I'm doing something wrong, but I'm not sure what.

    What I tried

    I initially just wanted to test out printing the platform info's os value to verify that I could.

    1. I created a new empty project.

    2. In the layout editor I right clicked to insert a new object, and chose the "Platform Info" object.

    So, in the project bar, in the "Object types" folder, there is now an object named "PlatformInfo".

    3. In the "Scripts" folder, I double-clicked "main.js" to open it in a tab.

    4. In the main.js tab, in the function body for

    async function OnBeforeProjectStart(runtime){}

    (edit: Following R0J0Hound's reply below, I should also mention I've also done all of these tests from within the Tick() function as well, just to be sure that pretty much everything would get a chance to load.)

    I added the following five console.log statements to the top of the function body. Each line is just trying a different way to access the platform info data.

    console.log( runtime.platformInfo );
    console.log( runtime.objects.PlatformInfo.getFirstInstance() );
    console.log( runtime.objects.PlatformInfo.getFirstInstance().os );
    console.log( runtime.objects.PlatformInfo );
    console.log( runtime.objects.PlatformInfo.os );

    5. I ran the project in preview mode, in Chrome, and when checking the Chrome dev tools, I got the following output in the console:

    // undefined
    // [object Object]
    // undefined
    // [object Object]
    // undefined
    

    For clarity, here are the expressions and their output shown together:

    runtime.platformInfo 
    // undefined
    
    runtime.objects.PlatformInfo.getFirstInstance() 
    // [object Object]
    
    runtime.objects.PlatformInfo.getFirstInstance().os 
    // undefined
    
    runtime.objects.PlatformInfo 
    // [object Object]
    
    runtime.objects.PlatformInfo.os 
    // undefined

    Chrome dev tools

    To better understand what I was looking at, I used a break point in Chrome dev tools to pause execution of the preview. I set the break point at the end of the function body for

    async function OnBeforeProjectStart(runtime){}

    and with the execution paused, I inspected the "runtime" variable to see if I could find

    "runtime.platformInfo", but I wasn't able to.

    I was looking for this property on runtime because I thought the Platform Info script interface documentation was explaining in the second paragraph that it is the preferred way to interact with the platform info features.

    So, I'm pretty sure I'm just missing something pretty obvious, but I'm not sure where I've diverged from what I'm supposed to be doing.

  • Thanks for the info and the suggestion Ashley.

    I like your idea of grouping all the imports in a hub file, so the individual files get to stay individual, but in a web context they can still all be imported through that one hub file.

    In my particular case, I think it's not a problem that, when running in a web context, the game won't know about additional files after export, as I'd likely only need that functionality in a Node version of the project anyway.

    I expect I'll ultimately export the final incarnation using Node, and incorporate some fs reliant features, but in the meantime, just being able to do the majority of the previewing directly in Chrome with a single click is really nice and streamlined. And the hub file idea should make that work pretty nicely.

    I plan to make my game logic interact with stored data through a custom data storage interface, that detects the web or Node context the project is running in, changing file access techniques and enabling or disabling related features. So the hub file was kind of the last puzzle piece to let me keep nearly everything the same for the core game data.

    Thanks again Ashley, I really appreciate that you take the time to answer so much stuff in the forums.

  • Is it possible to dynamically import all .js files found in a specified subfolder of the C3 project Scripts folder? I think this may work in Node, but in a browser it looks trickier, and might involve C3 scripting API use. Though I'm not sure getting a C3 project folder's file/contents list is supported in the C3 API.

    e.g.

    Suppose, within the C3 project "Scripts" folder, I create an "entity_definitions" folder. In that subfolder, I create several individual js files, each exporting an entity definition. Can I, at runtime, get a list of the files names in that folder, and dynamically import them?

    Motivation

    There are a variety of preset js-objects I want to define, and I'd like to organize these definitions as one definition per .js file.

    I want to collect these .js files in to packs of definitions that all reside in their own folder.

    Roughly speaking, I'll end up with some folders (e.g. "pack1", "pack2", "pack3"), each containing a bunch of little .js files.

    For flexibility and extensibility reasons, I would prefer not to have to hardcode the names of all these files directly into import statements in the game code. (Also kind of nice for modding.)

    My understanding of the Node context so far

    I think this should be possible in a Node context using the core "fs" module.

    That is, if I export for node, or use remote preview for Node, I think this is doable.

    My understanding of the Browser context so far

    However, in a browser context, the file-system is not directly accessible, so I think I'd need to use some C3 API feature to get access to files that were part of the C3 project file hierarchy. I'm pretty sure C3 provides a way to get single files by name, but I'm not sure about getting a list of file names from a C3 project folder.

    Some notes

    It's not a must that the final project work directly in a web browser, but it's a nice-to-have, and it would be convenient to use the default chrome-based preview, instead of remote preview. (Though I do very much appreciate that the remote preview in Node feature exists, as it may turn out to be a critical part of my work on this project.)

    Anyway, any thoughts or suggestions are welcome.

  • Thanks for the replies, R0J0hound and Oosyrag, :)

    What you both mentioned about a 2D world's data growing in memory at a much slower rate than a 3D volumetric one, and possibly fitting entirely in RAM for much longer is a really good point.

    And your caution about getting stuck in the pre-optimization weeds before it's actually solving a concrete problem is good advice, Oosyrag.

    Mainly, I just wanted to check with people more familiar with C3, that streaming to/from file wasn't ruled out by something I wasn't aware of. I figure at some point, an infinite world is going to have to go to disk, and even if it's a problem to solve much later on, I'm just at the engine scouting phase. So it's handy to have an idea of how much a given engine will be working for or against certain aspects of the project, before committing to one.

    It sounds like NW.js would be the way to go for file read/write stuff, which has been my experience with C2. I made a C2 color theme editor quite a while back, and it relied on the NW.js file facilities, though I don't recall if I could invoke a save/load without a prompt using the built-in NW.js C2 object. I could always code a plugin though, if the functionality is available somewhere in NW.js features.

    Anyway, thanks again for the info, R0J0hound and Oosyrag. :)

  • Given a tile-based procedurally generated world, in the vein of Minecraft or Terraria, is there a good way to save and load map data chunks to disk as needed?

    That is if a player travels East, new chunks are procedurally created ahead of them, and old chunks far behind them are saved to disk and unloaded from memory. Then when the player turns back and travels West, the chunks ahead of them to the West are reloaded from disk as needed.

    I know that the browser-based nature of C3 is likely to make this a bit tricky, because browsers don't have free reign to write files for security reasons.

    Ideally I'd be looking for desktop style behavior, where the game stores map data essentially the same way Minecraft does.

    e.g. Loosely speaking, Minecraft streams map chunck data to and from a local folder, which differs slightly by platform.

    • Win: %appdata%\.minecraft
    • Mac: ~/Library/Application Support/minecraft
    • Linux: /home/USERNAME/.minecraft/

    Another benefit of this desktop-style behavior, is that world data stored in the folder isn't vulnerable to erasure by clearing local browser data.

    I'm not sure what the best approach would be, but my initial impression is that this would require exporting for NW.js in order to take advantage of the more desktop-like context NW.js operates in.

    Would an NW.js exported application allow saving and loading of map data, without prompting the user for a save location for each chunk file? I figure that prompting multiple chunk file saves every few blocks would slightly encroach on the spirit of exploration. :)

    I'm not familiar with the nuances of C3, but my experience with the prior incarnations of Construct so far, is that just about anything is possible, with enough insight.

    If there's a better approach, or if it's genuinely not doable, or simply not something that C3 is a good fit for, any thoughts or suggestions are welcome. :)

  • Thanks Wisdoms. :)

  • Hey Ashley, :)

    Hope you're doing well. I don't know if you remember me, but quite a while back I used to spend a lot of time writing up tutorials and answers to user questions for Construct 1 and 2 in the forums. I've talked with you a few times here and there.

    I just got my C2-based game funded on Kickstarter, and it's still climbing past the original funding goal, and I wanted to thank you and the rest of the Scirra team.

    It's not an exaggeration to say that my dream is becoming real because of you. So thank you, Ashley. :)

    I posted about my game in the "Your Construct 2 Creations" forum, though I know most traffic has likely moved to C3 at this point.

    I would like to share the game with the wider Construct community, but I'm not sure if there's a good place to do that. If you have any advice or suggestions, I'm all ears. No worries if not though.

    This is the post I just made in the "Your Construct 2 Creations" forum.

    Down Ward - an Owl Flight Platformer

    Thanks again, and best wishes for the continued success and growth of Construct 3. I'm looking forward to getting familiar with it in the future. :)

  • Hi all,

    I've been working solo on Down Ward for a few years now, and regularly updating a free version. The game follows Gable, a little owl, exploring her way through overgrown ruins.

    Subscribe to Construct videos now

    The game is on Steam and Game Jolt at the moment.

    Down Ward - Play/Download

    If you're interested, I'm currently running a Kickstarter that will end a few hours after Thursday (April 29th).

    Just for fun, a pixel Portrait of Gable. :)

  • Thanks , much appreciated . :)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Hi all,

    I've been working on a C2 game for a while now, called "Down Ward"

    You play as Gable, a little owl, as she sets out to rekindle the dormant relics of a land long abandoned to ruin.

    A video:

    Subscribe to Construct videos now

    Some gifs:

    i.imgur.com/ECoLvnr.gifv

    i.imgur.com/fSq4zfA.gifv

    i.imgur.com/5VQXadf.gifv

    The game:

    Down Ward - Play/Download

    If you're interested I also launched a Kickstarter,

    Down Ward - Kickstarter

    (Please let me know if posting a Kickstarter link in this forum is a problem, I don't want to be breaking any rules.)

  • Down Ward

    Gable, flutters her way through a leafy alcove. :)

  • Okay, just posted a bug report, as per your suggestion.

    Thanks again for helping me look into this Ashley. You're the best. :)