Fengist's Recent Forum Activity

  • Would be interested to see the same project with the new beta Fengist

    New r161 version uploaded. Link in the OP for comparison.

  • Which means, let's say in the 500th recursion, if all the found = false, it won't repeat anymore.

    While a good idea, in my case, a recursion would likely cause an even bigger delay in completion. Each cycle through the loop I'm looking at an element in the array. I'm then looking at the 9 elements surrounding it (x-1, y-1 to x+1, y+1) and basing changes off the results of that. Changing the element the loop is looking at could affect the element prior to it but I wouldn't know that until I ran through the loop again. (I'm playing with procedurally generating island terrain using an array as the template for the tileset.)

    And as an update, the While worked great, just like a good ole' Pascal repeat until. Here's the resulting code. It's purpose is to 'smooth' out the terrain generation. The OrphanCheck is the conditional to stop the while and the -1 in the array indicates it's a water tile. ArrayOffset is a 'border' around the islands that's guaranteed to be water.

    * On function 'EliminateOrphans'
    ----+ System: While
    -----> System: Set OrphanCheck to False
    --------+ System: For "IslandColumns" from ArrayOffset-1 to ArrayWidth-ArrayOffset
    ------------+ System: For "IslandRows" from ArrayOffset-1 to ArrayHeight-ArrayOffset
    ----------------+ System: Array.At(LoopIndex("IslandColumns"),LoopIndex("IslandRows")) ≠ -1
    -----------------> Array: Set ThisX to LoopIndex("IslandColumns")
    -----------------> Array: Set ThisY to LoopIndex("IslandRows")
    -----------------> Array: Set ArrayAve to 0
    -----------------> Functions: Call OrphanCount
    --------------------+ System: Array.ArrayAve ≤ 4
    ---------------------> Array: Set value at (LoopIndex("IslandColumns"), LoopIndex("IslandRows")) to -1
    ---------------------> System: Set OrphanCheck to True
    ---------------------> System: Add 1 to ArrayCount
    --------+ System: [X] Is OrphanCheck
    ---------> System: Stop loop
    
    * On function 'OrphanCount'
    ----+ System: For "IslandXCheck" from Array.ThisX-1 to Array.ThisX+1
    --------+ System: For "IslandYCheck" from Array.ThisY-1 to Array.ThisY+1
    ------------+ Array: Value at (LoopIndex("IslandXCheck"), LoopIndex("IslandYCheck")) ≠ -1
    -------------> Array: Add 1 to ArrayAve
    
    
    

    And to show what I'm doing and why I needed this, here's what the 'island' terrain looks like without running this loop.

    And after running the while loop

    Basically, it's purpose was doing some 'cellular automata' to check and see if a land tile had at least 3 neighboring tiles that were terrain and if not, set it back to a water tile (-1)

  • Chrome:

    Click the 3 dots top right.

    Look for Zoom, click the +

  • AFAIK there's no way to determine if an app crashed or the user simply closed it normally, ended the task or exited normally. And, the console log doesn't keep a history that I know of, it's created as the app is running.

    If I really wanted to track down a specific cause I'd have a 'hidden' debug mode which sets a boolean to true if the user selects it and stores that as a local variable.

    I'd use the Browser plugin to write various events in my app to the log (if debug is true) to keep track of what the app is doing. I'd use the JS code above to try to constantly capture that log and store it locally as well. The next time the app is run, I'd check to see if the debug is true and if so, either send that entire log off to a server somewhere or have a 'developer' layout where you can pull that previous run log up and examine it.

    Using that basic method, you could at least determine where the app crashed and possibly the cause.

    You could test your app on your phone in developer mode as that post suggests but more than likely, if your app runs fine in preview without errors, any errors generated on your phone are likely going to be a result of that platform's hardware/drivers/etc and not bad code.

    Again, all of these ideas are just theories, nothing I've actually done or tested.

  • ( had to outdo your pascal after all ;) ).

    I love you guys, I really do.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • In most other languages there are things called exceptions that can be checked for.

    en.wikipedia.org/wiki/Exception_handling

    In some languages, exceptions can be checked for globally so that if the program crashes anywhere, it breaks out of what it's doing and the programmer can decide how to handle the crash, like a bug report. In JS there is the try/catch which can be used on blocks of code to find when things go wrong.

    In Construct there appears to be nothing like this. In most languages

    4÷0

    would cause an exception. In construct, it let's it fly and gives the results as Infinity. This tells me that Construct is likely set up to at least avert crashes caused by the programmers bad code.

    So, as far as I know, there's no way to have your actual app check itself for errors or crashes and report those crashes back to you. My method of debugging is to run in Chrome and hit the F12 to bring up the developer console. I keep watch on it to see if any serious errors are occurring. If my app runs on my hardware, it's able to do everything I want it to do and I see no errors, then I've done all I can.

    As Ashley pointed out, there are so many different hardware and software configurations out there that it's impossible to test for all of them.

    About the closest thing I've found that can help you track down errors is this:

    stackoverflow.com/questions/19846078/how-to-read-from-chromes-console-in-javascript

    I haven't tried this, but supposedly this JS will capture the console log (in Chrome, I don't know about other browsers). You could likely adapt this to store the log locally and send that log back to a web server somewhere where you could review it. Determining whether the app crashed or not is another ball of wax you'd have to solve. Another thing that could give you some insight is the PlatformInfo plugin. The information it provides is pretty limited but you could also have that sent back to a server to at least know what OS the user is running.

  • Let me demonstrate how old school I am. The pseudo code in my op... it's Pascal

    tutorialspoint.com/pascal/pascal_repeat_until_loop.htm

    And yea, the Do While seems to be Java's equivalent.

    The While loop in Pascal seems pretty close to what you described in Rust. In Pascal, the moment the condition becomes true the loop breaks, and I didn't consider that it would work any differently in Construct.

    In my case, I needed to run through an array of 20,000 elements and check for a number of true conditions and make changes which could affect cells already examined in the loop, making them true. I needed to keep checking the array until all conditions were false.

    I don't need them often either which is why I haven't encountered this in Construct before, but when I do need one, there's just no good substitute.

    Thanks guys, I have been educated.

  • Well be damned.

    In every other language the While requires a condition.

    While found=false do begin
     do stuff
    end while
    

    In that case, even a single found=true breaks the while loop.

    Apparently Construct doesn't even require a condition for the while. Never needed one before so that was a bit unexpected.

    Thanks.

  • lol, yea, crashed the editor to the point that I got an Aww Snap trying that stunt. Lost about 4 hours of work.

  • Does the stop loop action work?

    I imagine it would but, both For and Repeat in Construct force you to enter a number of times it should be repeated. Seems like bad coding to add in a for loop to run a million times just to make sure you get the job done when a repeat until a boolean condition exists would work.

    While is totally unsuitable, at least in my coding experience, because the instant 'Found' becomes true, it breaks the loop.

    But yea, thanks for the idea. I guess a million for loop is on the way.

  • Yea, I tested mine as well when the patch first came out and the third test did MUCH better. As soon as 161 gets fixed, I'll load up a comparison, make a note here and update the OP with a link.

  • Pseudo code:

    Repeat
     Found = FALSE
     X=Time mod 10
     if X = 0 then Found = TRUE
    Until Found = True
    
Fengist's avatar

Fengist

Member since 6 Nov, 2015

Twitter
Fengist has 5 followers

Trophy Case

  • 9-Year Club
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • x3
    Coach One of your tutorials has over 1,000 readers
  • x2
    Educator One of your tutorials has over 10,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

16/44
How to earn trophies