ADRIFT Forum


The place to discuss the ADRIFT Interactive Fiction toolkit

Crashing to desktop

This forum is the place to learn about and discuss ADRIFT 5. Feel free to mention any bugs you find here, but please also add these to the Bugs & Enhancements list.

Please also refer to the ADRIFT 5 Wiki for more information.

Crashing to desktop

Postby BBBen » Sat Sep 02, 2017 12:03 am

I'm getting a lot of crashes to the desktop in a game at the moment. I'm not sure what could be causing it; it seems to happen in my combat system (which is quite complex) but I can't see a clear common denominator. Does anyone have any idea of the kind of things that might cause the runner to crash like that? I don't know where to start debugging. I suppose it could be something multimedia related as there's a bunch of audio, jpegs and gifs involved, but I don't see which of those should be causing an issue because they didn't before. Could it be some kind of variable? Or the game trying to do something it can't?
BBBen
 
Posts: 287
Joined: Sat Jul 02, 2011 5:46 am

Re: Crashing to desktop

Postby BBBen » Sun Sep 03, 2017 11:15 am

Well, I worked it out.
BBBen
 
Posts: 287
Joined: Sat Jul 02, 2011 5:46 am

Re: Crashing to desktop

Postby Lazzah » Mon Sep 04, 2017 7:57 am

BBBen wrote:Well, I worked it out.

And......??????
OUT NOW: The Lost Children
Current W.I.P.: Magnetic Moon
Also available: The Axe of Kolt, The Spectre of Castle Coris, The Fortress of Fear, Die Feuerfaust - The Fist of Fire
User avatar
Lazzah
Moderator
 
Posts: 2016
Joined: Thu Mar 31, 2011 4:54 am
Location: London, England

Re: Crashing to desktop

Postby BBBen » Mon Sep 04, 2017 9:06 am

.....And it was a matter of overloading the engine. I have a system of combat 'rounds' in the game. Certain actions trigger a round to advance, which involves a lot of tasks to be triggered and variables to be changed. I had an ability that, during a round, would then trigger a second round to pass immediately afterward, thus denying you the chance to make any moves that round. Unfortunately it seems like those rounds are complex enough that triggering two at once crashes the runner. At least, that's my theory.
BBBen
 
Posts: 287
Joined: Sat Jul 02, 2011 5:46 am

Re: Crashing to desktop

Postby ralphmerridew » Mon Sep 04, 2017 2:19 pm

That sounds possible. Do you know how long the task call chain can get?

(That is, Task A has a task action that immediately runs Task B, and Task A won't finish until after Task B does. Similarly, Task B has a task action that immediately runs task C. ... and so on. A minimal game can have a call chain of 310-320 items before crashing due to "stack overflow". If you're running a loop by having a task call itself, it's pretty easy to hit that limit, but unlikely otherwise.)
Bloodhounds can make you laugh and cuss in the same breath. They are endearing, faithful, and can sling drool ten feet in any direction. -- Virginia Lanier
User avatar
ralphmerridew
 
Posts: 2501
Joined: Fri Dec 13, 2002 11:56 pm
Location: Missouri

Re: Crashing to desktop

Postby BBBen » Mon Sep 04, 2017 10:07 pm

I don't know how long it is exactly, although it wouldn't surprise me if it went over that 310-320 mark when it called itself. It would have only looped once, but it's a big chain.
BBBen
 
Posts: 287
Joined: Sat Jul 02, 2011 5:46 am

Re: Crashing to desktop

Postby ralphmerridew » Sun Sep 10, 2017 2:08 pm

O_O I'm impressed.

Just to be clear: "Task A has an action that runs Task B; Task B has an action that runs Task C; ... Task I has an action that runs Task J" would have a chain of length 10.
"Task A has actions to run Tasks B, D, F, H, J, L, N, P, ... X; Task B has an action to run Task C; Task D has an action to run Task E; ... Task X has an action to run Task Y." would only have a chain of length 3, even though 25 tasks are called over the course of the turn.

It's not important how many tasks are called; what causes trouble is how many are being processed at once. So you might be able to alleviate the problem by modifying the call chain a bit to be flatter.

For example, you could change the first example to "Task A will set %will_continue% to 0, then run task B, then run task F". Task E sets %will_continue% to 1 instead of running Task F. Task F adds a condition that %will_continue% must be 1. The same things happen, but now the maximum call chain is about half as long.

(I'd recommend trying to flatten out the call chain anyways; the maximum length before problems occur is not explicitly set, and may be different on a later version of Runner.)
Bloodhounds can make you laugh and cuss in the same breath. They are endearing, faithful, and can sling drool ten feet in any direction. -- Virginia Lanier
User avatar
ralphmerridew
 
Posts: 2501
Joined: Fri Dec 13, 2002 11:56 pm
Location: Missouri

Re: Crashing to desktop

Postby BBBen » Sun Sep 10, 2017 9:45 pm

Oh, in that case the chain may not be so long; a lot of tasks are called but it shouldn't be likely to loop more than once. That said, I'm sure it was that self looping that was crashing the game.
BBBen
 
Posts: 287
Joined: Sat Jul 02, 2011 5:46 am


Return to ADRIFT 5.0

Who is online

Users browsing this forum: No registered users and 2 guests

cron