Messages

Ah ok I see. I doubt one of these is actually a major reason why it gets out of sync anyway.

If I recall correctly, I also had a problem running the game in question (it crashed on death screens), which I solved by disabling the sound and music.

Later I tried running it with a newer version of the AGS engine and that worked fine even with sounds, although some things went strange, like looping of sound/music when a death message screen is displayed.

Yeah, and having the ability to make visual walkthroughs would be just awesome, surely not a complete replacement for text-based solutions which have their own pros, but to watch a game from a different perspective of another player -- movie mode! 

So does the engine redo logic decisions each time replay runs?

If so, what happens with functions that return volatile values, eg: DateTime.RawTime or Random (with maybe a different seed value) or some if_file_exists, etc... , ie. such that doesn't rely on the user input but on the current state of the system?

In theory the engine just needs to record its state whenever it's changed, so that it could be reproduced later on replay, something like this:

loop 0: move_character
        turn_object_on
        show_gui

loop 5: hide_gui

loop 9: stop_character
        disable_walkable_area

loop X: etc

note: it's enough to save delta for loop number: loop 0 ... +5 ... +4 ... +etc


If the engine works in a single-threaded fashion this should be enough to define a deterministic behaviour of the game. Although maybe it has something to do with computation errors, such as with floating point operations or something similar which causes a game replay to run differently the other system you try it with, maybe.

Just my thoughts...

[Programming / Scripting / Coding]

Programming / Scripting / Coding

At present, I got some free time and am happy to help with programming, scripting or coding an AGS game depending on the state of the project. I would prefer doing a framework programming myself from scratch, but could also help adapting/refactoring the current code as well as writing some specific routines if necessary; general scripting is also fine.

Provided there is not too much work to be done, I'm able to support (work on) several projects simultaneously.

Contacts:
Private message (preferable)
e-mail: scorpiorus@yandex.ru

Cheers,
Alex

[Characters pane]

On the Characters pane look for the Talking colour setting.

See the AGS Manual for more info.

The WAV file in question was probably encoded in a format which AGS does not support. Basically, WAV should be in an uncompressed PCM format for the engine to play it.

Try converting it to WAV PCM, for which you can use Microsoft Sound Recorder that comes as a standart application for MS Windows.

In XP it's here: Start :: All Programs :: Accessories :: Entertainment :: Sound Recorder.

Just open your original file and then "Save as..." but make sure to change the format to PCM. See if it works then.

I guess making it totally synch-ed is not as easy as it may sound, because game logic based on the number of game loops per second may well go differently on different systems or even on the same system the other time it runs; there is no guaranty that time intervals between calling repeatedly_execute, for instance, are exactly the same.

Edit: hmm, on the other hand the replay mechanism doesn't need to (actually must not) reproduce the making of logic decisions at all but just change the engine state sequentially, in which case the above may not be relevant here.

I think this implementation is based on the idea that, generally, masks do tightly relate to the current background image and whenever you alter your background image in a certain way the masks should also be updated. And yeah, because of this it could be a good idea to generate the masks with a program you draw your backgrounds in.

Yes, but it was made using a script editor's trick with interactions to make it look like a script module, so it will need some refactoring to be fully compatible with the latest AGS versions; and updating old-style script command names should also be addressed. I'll see if I can do something about it.

EDIT: Ok, here is the version that runs with AGS 2.72. Note, however, that I haven't changed much of the code -- just upgrated to new-style commands here and there (there are no enums or struct methods used):

http://www.geocities.com/scorpiorus82/qfg_battle/qfg_battle_v11.zip

Here is the template you are probably looking for:

http://www.geocities.com/scorpiorus82/qfgbe_v1.zip

Note, however, it was made for a rather old version of AGS, so if you want to take a look into the script I'd recommend opening it with AGS v2.55 or about that.

You can find old versions of AGS on the AGS wiki page.

Nice work with rewriting the MI3 user interface! Many people will surely find a use for it

It's very handy when teleporting around in debugging.

Yeah, I too think that one is surely handy to have.

So - is there anyone else that might be useful in the default game, without going overboard?

You know, while we're at it... is the default template ok as is? I've made one change, I can make more...

Yep indeed, we should probably keep it balanced -- add some really necessary things but keep from bloating the default template's global script with advanced (or not so commonly used) stuff. Again just try not to confuse people having no or little experience with AGS and its scripting language.

Game options GUI is really necessary. Additional debug features may come in handy but the question is how much would that bloat the global script? If they are added, a reasonable idea would probably be to put them into a script module, because debugging features may be used frequenlty but their code changed infrequently. It still may be included into the template as a script module, though.

Double-click handler seems like a candidate for a separate script module. Can't say for sure whether or not it would be useful for the default template to have.

Nice work with the template!

I think, how feasible would it be to put all the code from game_start into a separate function and just call it from within game_start to keep the event handling function in question clean, similar to how show_inventory_window is used?
I think it would be less confusive for beginners, should they want to add their own code on game_start (maybe a couple of lines) but see there is already plenty of code there.

[Digital sound]

And also, have you yet tried what Pumaman suggested before, ie. fiddling with the game settings?
Try disabling the Digital sound and MIDI music in the game setup and see if it makes any difference.

Glad to know you got it working

By the way, noloopcheck can be specified once for the most outer level function (say, on_key_press), and thus all subsequent inner calls are automatically treated as noloopcheck ones, which may be useful for testing purposes. Though, of course, as a general rule it is highly recommended to decide whether to disable the check or not on a per function basis in order to avoid possible hangs of the engine due to logic errors in the script code, as the manual suggests.



Having a global counter of loop iterations seems like the best way to implement the check, I believe. It is simple, yet effective means to provide general protection against infinite loops caused by logic errors. Strictly speaking, each loop instance, so to say, could have its own counter to make the check perfectly accurate for combinations of nested and successive loops but in practice it means increased overhead in terms of both performance and memory usage, as for instance nested loops would then require separate counters and their total number is generally undefined because of a possibility to have "nested" loops through recursive function calls. So such complications are not really necessary in my opinion.

We just should take into account that with the global loop counter the following code...

Code: ags

int i= 75000;
while (i>0) i--;

int j= 75001;
while (j>0) j--;

...will normally abort the game.

while (1 to 15) {
  while (1 to ~50) {
    ...
  }                      <----- line mentioned in the error message
}

That code alone should not abort, but maybe the function with that code is called recursively (or in an outer loop/loops ) ?

And the weird thing is: it works perfectly fine as long as there are Wait(1);s in the code.

Wait(1) has an effect of updating the engine state, so it doesn't count as a hang to the engine.

Anyways, a recursive call may indeed get it very quickly to the 150000 limit point.
Say a 50 iterations loop called recursively 4 times will end up at 50^4 = 6250000 iterations in total.

Have you tried a noloopcheck keyword to stop it aborting the script?

I'd add my support to any suggestion to have Strings initialise like that by default

Yeah, provided there are no real issues of technical kind with implementation (how memory allocated? etc.), assigning all String pointers (including arrays of pointers and data members of structs) to the dummy "" instance by default would make things less confusive for beginners.

Such a change could potentionally break things in already written code, though -- ie. no errors at compile time, but introducing logic ones at run-time.

I'd also vote for still having a possibility to define/set a null String pointers then, as quite often it is handy to have a separate state for nothing (null).


String a;           // defaults to ""
String b = "blah";  // inits value to "blah"
String c = null;    // nothing


Some older thread discussing the issue: http://www.adventuregamestudio.co.uk/yabb/index.php?topic=28977