Messages

Blackthorne, have you tested QFI on Android? I know Himalaya Studios was having issues with their games silently crashing, but I could never reproduce it.

Just wanted to post an update that we've been porting Al Emmo to iOS and these random silent crashes still occur on that platform, so whatever the cause, I can confirm that it's not Android-specific.

[Update: May 9th, 2014:]

Update: May 9th, 2014:

Quick update to say that Al Emmo is now available to buy on Steam. It's available for both Windows and Linux.

Thanks to monkey_05_06 for helping out with the process!

I didn't have that many windows open in Windows nor many tabs open in AGS at the time. Actually, far less than I typically do, as I had just loaded up the editor not long before.

I was in the process of changing all my Dialog.Start(); instances over to goto-dialog instances when the editor crashed with the following error:

Spoiler

Application Error
---------------------------
An unexpected error occurred. See below for details.

System.ComponentModel.Win32Exception: Error creating window handle.
   at System.Windows.Forms.NativeWindow.CreateHandle(CreateParams cp)
   at System.Windows.Forms.Control.CreateHandle()
   at System.Windows.Forms.ToolStripDropDown.CreateHandle()
   at System.Windows.Forms.Control.get_Handle()
   at System.Windows.Forms.ToolStripManager.ModalMenuFilter.PreFilterMessage(Message& m)
   at System.Windows.Forms.Application.ThreadContext.ProcessFilters(MSG& msg, Boolean& modified)
   at System.Windows.Forms.Application.ThreadContext.PreTranslateMessage(MSG& msg)
   at System.Windows.Forms.Application.ThreadContext.System.Windows.Forms.UnsafeNativeMethods.IMsoComponent.FPreTranslateMessage(MSG& msg)
   at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)
   at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
   at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
   at System.Windows.Forms.Application.Run(Form mainForm)
   at AGS.Editor.GUIController.StartGUI(String[] commandLineArguments)
   at AGS.Editor.ApplicationController.StartGUI(String[] commandLineArguments)
   at AGS.Editor.Program.RunApplication(String[] args)

[close]

I guess this could be related the the same issues mentioned previously in this thread. I did notice (when I reloaded the game into the editor) that I had accidentally doubled up a dialog with two commands under @2, like this:

DBortInitiation

Code: ags

// Dialog script file
@S  // Dialog startup entry point
return
@1
  cBort.Say("Blah Blah Blah.");
return
@2
goto-dialog dBortMain
 dBortInitiation.Start();

Not sure if that has anything to do with it. Just mentioning it in case it's relevant.

I had saved the game (CTRL+S) but hadn't compiled it when the crash occurred. After saving, I recall trying to double-click several dialog topics, and none of them would open. After a few attempts, I double-clicked another dialog and the editor crashed with the above message.

Ah, right. Would this be something for 3.3.1, then?

Sorry, scratch that. I actually looked at the Quest for Glory 2 source code, and saw that we had used goto-dialog commands everywhere, which is why it wasn't ever crashing.

Another thing is that goto-dialog won't work in all cases. Take for instance this type of script:

Code: ags

// Dialog script file
@S  // Dialog startup entry point
return
@1
 cEgo.Say( "Blah Blah." );
 if( globalvar_somecondition==1 ) dDialog3.Start();
 else if( globalvar_somecondition==2 ) dDialog4.Start();
@2
 dDialog2.Start();
stop

Random thought: could the Dialog.Start(); function be tweaked to automatically stop, break-out of, and close any active dialog that's already running, prior to starting the new one?

I tested a bit more and it seems that any parent/child dialog combo in the 3.3.0-compiled game (and for any character) crashes the game if jumping back and forth between parent and child dialogs like this.

As an experiment, I just tried this same pattern in our Quest for Glory 2 remake, which has similar dialog tree structures and was compiled with 3.2.1. I couldn't get this crash to occur in that version of the engine. Did there used to be some kind of safeguard or additional checks in 3.2.1?

I don't think I have any dialogs set up with that exact structure, but I found a way to crash it every time on my side. My dialog structure looks as follows (note: dialog names are changed to the number of each in-game dialog for easier reference):

dDialog144

Code: ags

// Dialog script file
@S  // Dialog startup entry point
return
@1
  cShareen.Say( "Blah" );
  dDialog145.Start();
stop
@2
  dDialog143.Start();
stop

dDialog145

Code: ags

// Dialog script file
@S  // Dialog startup entry point
return
@1
  cShareen.Say( "Blah Blah" );
  dDialog146.Start();
stop
@2
  dDialog144.Start();
stop

-I navigate to dDialog144 and click option 1 to go to dDialog145
-On dDialog145, I click option 2 to return to dDialog144
-Repeat the above process around 20 - 25 times.
-The game will ALWAYS crash on dDialog145 when clicking option2, with the following error:

Error: post_script_cleanup call stack exceeded: possible recursive function call? running _run_dialog144

Changing all the dialog script name references in the game to goto-dialog X instances kind of defeats the purpose of easily being able to refer to them by script name. Plus, it'd be a bit unfeasible to do that with over 335 dialogs in the game.

Does the engine actually need to crash fatally when it encounters this kind of issue? Could it perhaps just write a warning to the log file instead, but keep the dialogs (and game) running?

I have no idea what _run_dialog144 is (I'm guessing it's something hard-coded into AGS?), because I'm simply running the dialogs with the function Dialog.Start(); when the Talk icon is clicked on the character. But the crashes typically don't happen when I first click Talk on a character. I have to navigate back and forth through a few linked Quest for Glory style tree dialogs before it happens. It often seems to occur when I'm reading a child dialog and click "Something else" to return back to the main dialog.

Dialog 144 looks like this:

Option Text
1: Goblins    (Show: checked, Say: unchecked)
2: About something else... (Show: checked, Say: unchecked)

Code: ags

// Dialog script file
@S  // Dialog startup entry point
return
@1
  cShareen.Say( "They were once an intelligent race. Creative. Resourceful. But their once-grand path has since split into tiny tracks. Now they dwell in splintered groups, deprived of their strength, their unity, and their purpose." );
  dShareenGoblins.Start();
stop
@2
  dShareenThirdTrial.Start();
stop

Nothing out of the ordinary. Yet I've noticed that the game seems to crash on the same few dialogs every time, and they all seem to be newly added or recently edited ones (where existing options where shuffled and new ones added).

--EDIT--

Would it help if I sent you the Game.agf file?

Thanks, I just tested it and the compile errors that resulted from moving the dialog folders up/down seems to be fixed now.

As you suggested, it didn't fix the existing "post_script_cleanup call" crashes, though, as I just encountered another one in my tests. After rebuilding all files, it greatly reduced their frequency, but it's still possible to get the crash eventually if you click through the dialog options enough times.

Will the fix also resolve the post_script_cleanup call crashes?

From what I can tell, it seems to crash, at random, when clicking options on a dialog that was newly-added just before to its parent folder was moved up/down. (Or when clicking options on an existing dialog that was edited just before its parent folder was moved up/down.)

Hmmm... even though the game compiles successfully after closing the editor and reloading the game, the dialogs now seem to be riddled with issues that crash the game frequently. I keep getting fatal crashes like this, which never occurred before:

Error: post_script_cleanup call stack exceeded: possible recursive function call? running _run_dialog144

This occurs completely at random. Sometimes a dialog works fine, and other times clicking options on the same dialog crashes the game.

I can also confirm that restarting the editor and recompiling fixes the issue until moving more folders.

It would also be worth checking into whether this issue affects GUI, Inventory, Views, Character, Audio, Room folders in the same way.

Yeah, it gives the same compile error when it encounters a dialog name script reference, either in a room script, the global script, or any other script.

[every]

I just ran into a pretty major bug in 3.3.0 which prevents the game from being compiled.

I have a lot of dialog topics sorted into various folders, and I wanted to sort those folders by alphabetical order, so I right-clicked on each folder, one at a time, and then clicked either "Move Up" or "Move Down" until all of my dialog folders were in the right order.

Next, I tried to compile the game, but the first script instance of dialog topic 0 (dJonisMain) in the global script tripped up with this error:

GlobalScript.asc(568): Error (line 568): undefined symbol 'dJonisMain'

It seems that every single dialog topic in the game now isn't recognized at all. Yet, when I double-click on the affected dialog topics in the editor to open them, they all open fine. All options are intact and even the script names are exactly as they should be.

Even if I rename the affected dialog to something else and then change it back again, it still gives the same compile error.

I'm in full agreement with what Snarky and Stacy are saying. Building an entirely new AGS4 and discarding all of the coding tweaks and iterations that have been tried-and-tested over the past decade seems like an overly ambitious task which risks running out of steam before all those little touches could be fully tested and re-implemented. Even if an exact facsimile engine was created, it'd likely be many years before it saw full completion, by which time, the most ardent/serious AGS developers will already have moved onto Unity or other feature-complete engines. Additionally, for developers who have large, existing projects, a brand new AGS4 would pretty much put them dead in the water - being forever stuck in 3.3, unable to be updated and take advantage of the newer engine's technology/features. This would have a pretty severe impact on commercial AGS games that are already available on services like Steam, as outdated AGS titles could no longer be updated and will only grow increasingly incompatible over time; to the point where they'd eventually need to be removed from the sale on the service.

About backwards compatibility being broken: as someone who has several large AGS projects dating back to 2000, which use a crapload of legacy code, I can say that yes, it would be a pain in the ass to update huge amounts of it to new code that does the same thing in an enhanced engine. For example the day-night fading cycle in our Quest for Glory 2 remake relies on numerous legacy RawDraw functions that could introduce bugs all over the place if updated. However, even though this is the case, 100% backwards compatibility still isn't overly important to me. Any developer who has an affected AGS game, which they need to keep up-to-date, is going to ensure that their project is using the latest functions and update accordingly if they get compile errors. It'd take me what - maybe a few days at most to update all those legacy code instances to the new code and then maybe a week to test it all thoroughly. In my view, refactoring 3.3 and breaking backwards-compatibility for the sake of maintaining the sanity of those working on the code is preferable to having a brand new engine that I can't even update the game to at all. Besides, there will always be the 3.3 engine if people want to play ancient AGS games. It just doesn't seem to make much sense to make backwards-compatibility with "Larry Vales" take preference over the modern needs of the engine and its userbase, giving the programmers aneurysms in the process.

The problem seems to be information overload. Some people have suggested that AGS should be a fully-integrated development system that can handle all types of games if it is to have any future. But I'd argue that this makes it just another cookie cutter engine that robs it of CJ's vision and goes against what so many current developers rely on it to do well. Of the handful of devs who create serious games with AGS, is this really worth the time investment? And what of AGS's legacy - ostracizing existing AGS developers at the expense of attracting larger crowds doesn't seem like a good way to go and makes even less sense when there's no financial motivation to do so. Now, that's not to say AGS shouldn't eventually be capable of creating other types of games... just that this shouldn't be considered as a crucial priority until the source is in a more stable state. Lofty visions divert attention and misdirect focus. AGS shouldn't try to be too much too soon. There are other engines that cater to developing all sorts of games, but AGS is, and always has been, an adventure game tool - keep it focused.

My 2 satang: If I were approaching this the same way I usually approach working on a mammoth game project, I'd identify the biggest hurdle first, regardless of how mundane it is, and work through it to make a stable foundation for building other additions/improvements. And I would not stop until that's done. With AGS3.3, the current hurdle seems to be the daunting task of refactoring of the messy code. I know that's not a fun task, and seems like a lot of time-consuming work for little reward, but at the end of the process, wouldn't the result essentially be that we'd end up with a clean, enhanced version of 3.3 with all the same flexibility and functionality of the clean AGS4 that's being proposed? If refactoring the current code is being considered, then the focus should probably remain on achieving that goal without adding any new engine features until it's done. I think we could all agree to make that sacrifice if it meant this issue becomes a thing of the past.

Regarding crowdfunding and paying a programmer to refactor the source code, I think that could be a good idea. I know CW said that, as a community member, he's personally not comfy with the idea of having an obligation, and I understand where he's coming from. But on the other hand, with a programmer hired from Elance.com, where I have had some good experience, or a similar site (preferably where you can rate their performance and value for money) the "obligation for payment" aspect may be precisely what's needed in order to have this task taken seriously, and see the work get done in a reasonable timeframe. Most people here understandably can't invest huge amounts of time to AGS development because they work other jobs and treat this as a hobby. Whereas hiring an experienced programmer who would make this their day job for a few months would ensure that the job gets taken seriously. Of course, there would first need to be a decision made about the direction for the engine to go in so that a hired programmer could be given a definitive roadmap to follow.

Weird. You should have seen a dialog before that error, that shows the actual error...
Anyways, I've added the actual error to this message as well, so once a new version is released if you'll reproduce the issue you'll have more information to show us.

Shortly after posting that, I realized a few other programs I opened new files or documents in also failed the action ("the program cannot create a new blank document" and similar error messages). It crashed about 5 times in AGS within the space of 20 minutes when I got that previous message I posted. But I've been testing several more days now, and I have yet to see the crash occur again. So I guess it was just some strange quirk or memory hiccup my computer was experiencing at the time. Haven't seen it once after rebooting a few days back.

[Unexpected error: The process cannot access the file 'C:\AGS8\Mages Initiation\game28.dta' because it is being used by another process.]

A couple of funky errors I received with the RC today:

1) At one point I was deleting, replacing, and adding a bunch of music files. I hit F7 to save and the game compiled. But when it finished, it gave me this error:

Unexpected error: The process cannot access the file 'C:\AGS8\Mages Initiation\game28.dta' because it is being used by another process.

Exiting the editor and re-opening was enough to resolve the issue.

2) A more serious one. I double-clicked a view which contained only blue cup sprites in loop 0. Instead of the view opening, I received this error message:

A serious error occurred and the AGS Editor may now be in an unstable state. You are STRONGLY ADVISED to shut down the editor and restart it. Before saving your work, make a backup copy of your game folder in case any data has been corrupted.

I closed the editor without saving the game. Re-opened it and kept getting the same message every time the editor loaded up (but before it allowed me to choose a game to load). It looked like all the panels etc. had been compacted into a small square in the upper-left corner of the editor and the rest of the screen was just grey. The AGS editor files had somehow been corrupted. The only way to open any games in the editor was to re-extract fresh files from the zip, overwriting the corrupted ones. Unfortunately, the error message didn't go into any further details than what's stated above...

No worries, glad you got it sorted.

Can please tell us what libraries you have installed on your system?

Apparently, I have these ones installed:

.NET Framework v1.1 [1.1.4322]
.NET Framework v2.0 SP2 [2.2.30729]
.NET Framework v3.0 SP2 [3.2.30729]
.NET Framework v3.5 SP1 [3.5.30729]
.NET Framework 4 Client Profile [4.0.30320]
.NET Framework 4 Extended [4.0.30320]

VC 2005 ATL Update
VC 2005 Redistributable [8.0.56336]
VC 2005 Redistributable [8.0.61001]
VC 2008 Redistributable [9.0.30729.5570]
VC 2008 Redistributable [9.0.21022]
VC 2008 Redistributable [9.0.30729]
VC 2008 Redistributable [9.0.30729.4148]
VC 2008 Redistributable [9.0.30729.6161]
VC 2010 x86 Redistributable [10.0.40219]
Microsoft XNA Framework Redistributable 3.1 [3.1.10527.0]

MSVCRT [14.0.1468.721]
MSXML 4.4 SP2 [4.20.9839.0]
MSXML 4.4 SP2 [4.20.9841.0]
MSXML 4.4 SP2 [4.20.9848.0]
MSXML 4.4 SP2 [4.20.9870.0]
MSXML 4.4 SP2 [4.20.9876.0]
MSXML 6.0 Parser [6.10.1200.0]