Messages

You don't have to use object oriented scripting - or change your scripts. 2.7 is backwards compatable. If you're just too lazy to download.. well, I give up

Um, how about upgrading it? 2.7 final is out, you know.

I was wondering if there's any way of calling a room object by it's o-name in the global script? I have some code that I'd like to use for several rooms but only call for the ones where it's necessary. But of course AGS doesn't know where it will be used, so it fails to compile due to an unknown o-name referred.

I can use object

• commands, but it would be easier if the object didn't have to have the same number for every room.
  
  I'm considering using a repeated GetName(object) at the start of every room script to compare the name and pass the object number to a global variable, but is there any easier way?

I have no idea what you just said, but if you want to convert a float to int, there's a fine little function called FloatToInt

Shadowplay (and its sequels) will have a very GK-like plot, gameplay and interface although it doesn't use any of the GK characters or mythology.

Another great issue. Maybe a bit short though - it felt like something was missing. I don't know, maybe a tutorial on creating antialiased sprites or something like that

On a related topic, the fade to/from black on room changes is VERY choppy in 32-bit mode on my computer (2.4 GHz P4, 128MB Geforce 4 Ti4200, 512MB). As soon as I switch to 16 bit mode, it runs smoothly.

The strange thing is that all other room transitions work fine. Crossfades, which logically should be even more demanding of the CPU, actually run much smoother.

Have others experienced this? Is it a bug or just a matter of "not wasting time on optimizing the code"?

I prefer full length games because they usually have better stories and more developed characters. Short games tend to stronger on humor and gameplay though.

However, I WOULD prefer a short but concluded story to a big game released in chapters. There's nothing to kill a story like having to wait another year for the ending (or even just a bit of plot development in some multi-chapter epos).To finish a great game like Bestowers of Eternity only to be left with a "to be continued" can't be anything but a letdown.
A good compromise would be independent sequels (like Ben Jordan's cases) with character development and perhaps some kind of bigger plot hidden in the background. It's the difference between an episode of '24' and an episode of 'CSI'. The former is pretty pointless to watch as a standalone episode while the latter can easily be enjoyed separately, but also contains bigger story arcs for the regular viewer. 

Oh, ok - I was thinking it might be some kind of memory leak in the dynamic sprite code. But that is not the case then.

Does this happen independent on WHICH game in the list you restore? And if you try to restore the same game repeatedly, does the crash always happen at the same try (e.g. on the fourth restore)?

Damn, that sucks. I think that the 999 save file is some kind of autosave that is normally deleted when closing the game (if you multitask back to windows while playing a game, you'll see it in the dir).

Are you using savegames with screenshots by the way?

Heh, glad I could be of help. I was struggling for several days with the exact same problem until I realized the cause. Doh! 

As much as I'd love a new Tintin game, you should be aware that Fondation Hergé/Moulinsart are just as protective of their intellectual property as Disney. It would be a shame to get a lot of people involved in a huge project only to see it shut down when it's nearly finished.

Sounds like Rosie is playing the games directly from the zip files (thus putting the  unpacked files in the same temp directory).

Are all the save games saved under the exact same version of the game that you're restoring under? In my experience, if you've made some slight adjustments to the code after saving a game, it WILL allow you to restore without error messages, but the game gets buggy.

Sorry to dig up this old chestnut again, but the topics seemed to fit two suggestions I had:

1) Script controlled object scaling is something that I could REALLY use, in any shape. I was thinking though, as there is a rawdraw function which sizes sprites to any width/height - would something similar be possible for objects?

2) Would it be possible to implement an IgnoreSpecificWalkbehinds(1,5,9) command? For some effects, baselines just aren't enough. Currently I'm doing a lot of cheating using objects as walkbehinds, but it would be a lot easier if different objects only were affected by certain walkbehinds.

Um, is it even possible to change properties at runtime?

I solved the problem. It turns out it was caused by a (possible?) gui editor bug in abbreviating long function names.

My textbox names were quite long to begin with ("txtReplaceDescription" was one), and when the editor autocreated the script, the function was abbreviated as "txtReplaceDescription_Activa". However, in the "Run Script" selection, it had been titled "txtReplaceDescription_Activat". So the correct script was never run. This also explains why one textbox, with the shorter name txtSaveDescription, worked while the others didn't.

Thanks for all your help!

By the way, it was all done with object based scripting, not involving interface_click (I'm pretty sure that whatever function was referenced under the textbox activate part in the help file is obsolete in v. 2.7)

One thing that you should notice when doing your own inventory GUI is that the item height and width must be specified in script, as setting those properties for the inventory window in the GUI editor does nothing(?). I learned this the hard way.

Yes, that was my thought too. I'll go home and try that.

It's strange though that they should still respond to other key presses if the first text box is blocking them.

I suggested something similar a while back, and it's in the tracker. Basically what I suggested was setting a default (x,y,width) for the Display/Say command. I wrote my own function as a workaround though, which allows me to use antialiased text - which simply DisplayAt wouldn't do, even if the text was displayed over a black area.