Messages

Too bad you're using 2.72, otherwise you could run Game.ChangeTranslation in the game_start for each game. Not a very helpful response, sorry. My guess is yes, it would work to have one huge file, and yes, it would slow the game down (because AGS searches through all Strings in the translation file until it finds the right one). If I remember correctly, your game uses its own internal storage of multiple Strings in a single line - and this may in fact speed it up a bit, because you have less Strings to run through. But for actual performance there doesn't seem to be any way to find out short of testing it.

Edit: Also, doesn't your cross-game code need to know the translations for all the games at all times? If you changed translation files between games, any words in the history list that didn't have a translation in the current game would appear in English.

Everything that was around when you were a kid is always great. Everything since then has always been crap.

Exhibit A:



Exhibit B:

No, objects don't talk - at least not in AGS. You could have an invisible character speak the lines of the toaster, but the easiest thing would be to just make it a character and figure out the proper coordinates (y should be the same as for the object, x should be the same as for the object plus half the width of the sprite).

It's because you're using a single "=" instead of "==" in the if statement. "==" is used for comparing values, "=" for setting them.

It should be:

Code: ags

if (bad6.Visible == false) {

Dualnames reported a similar bug in the parallax scroll module thread.

I haven't researched more than the two links you posted, but this sounds like scaremongering to me. As far as I can tell they are pulling this idea of TV-like packages out of their asses. So what if "broadband providers will be legally able to limit the number of websites you can look at" (not "forced" as you write)? How many are actually going to do it? If just one ISP decides not to block anything, they'll soon be the one with all the customers. There's really no money to be made in this business model. To an ISP traffic is traffic, and they're even reluctant to block peer-to-peer networks short of a court order, because their business is selling high-speed connections to those who need them with no questions asked. I doubt even the entertainment industry could afford enough money in bribes to match the income from millions of users paying a monthly fee.

Edit: I thought I had read a similar discussion before. I could swear I also made a post, but apparently not - at least this reply pretty much sums up my thoughts on both matters. And if it turns out I'm wrong, well, then none of you will be able to access the forums to tell me so anyway

Go with 640x400 - that way your game won't stretch on widescreen monitors and can be letterboxed on regular 4:3 monitors.

According to the AGS Tidbits & Snippets (whether they're up to date or not, I don't know), the pathfinder uses an array of 1400 rows, so the maximum room height is 1400 pixels (2800 in hi-res rooms, I don't think using hi-res coordinates affects the pathfinder resolution). In theory, there's no width limit.

I have no idea whether the difference between 1/255 and 1/100 (or rather, 3/255) is audible, but I think it's slightly silly losing "resolution" just because it's easier to imagine sound volume going from 0-100. I mean, does anybody find it problematic to use an 8-bit scale for RGB values?

They all look kinda cross-eyed. I really think the eyes would benefit from being tree pixels rather than just two.

Definitely keep it 0-255, changing to 0-100 would be purely cosmetic and allow for less flexibility. If the 8-bit range bothers anyone it should be super easy to whip up a conversion module with percentile based functions.

You need to use the eBlock parameter in the Walk function, i.e. "cBaller.Walk(572, 503, eBlock);", otherwise the script will directly proceed to the next line instead of finishing the walk first. Also, the correct usage in your second example (but DO use the blocking walk instead, this is just to inform you) would be:

Code: ags

while (cBaller.Moving) Wait(1);

Hmm, do you have some kind of Wait(1) or similar between saving one game and running the other? Saves are only performed at the end of the function, so if you change games in-between perhaps this could cause problems.

Edit: No, actually Wait(1) still wouldn't work, I think, since the function is still running. Setting a variable to a certain value (e.g. "bool changegame = true") and checking for that in repeatedly_execute would work though. Of course you would have to set it to false again in on_event eEventRestoreGame.

Have you checked that you're restoring the right slot and that the savegame folders are set up correctly? Try deleting/moving any existing savegames to make sure that it's actually the savegame you just saved and not some old file that is being restored. Are the savegames from the two games in the same or in different folders?

Edit: Additional questions, is the restore code called from game_start? And is RunAGSGame called with the "mode" parameter set to 0 or 1?

Edit 2: Saw your comment on the blog about generating savegame names from variables. While troubleshooting, maybe you could try commenting out that line and substitute it with a static name? Just to rule out an error source.

Mr Flibble, it's definitely possible - but as you say, the result will be horrible slow when performed in the repeatedly_execute on a larger part of the screen. I did a module which inverts, multiplies etc. color values, and even on small sprites it lowers the framerate by about 10. Pre-rendering all the frames at run-time is an option, but would mean a pause of several seconds while doing so. I think the best solution for doing it in-engine, would be to render the frames and then output them to .bmp files ready for sprite import.

Yes, the Wait(1) is the problem. Is the "int y" definition stored outside or inside the rep_ex? If it's inside it will be reset to the default value every frame.

Edit: No, sorry, misread. Another problem is the "while" conditional. This makes the code wait until the y value is 0 until proceeding to the next frame. Remove the while and it should work. Instead do a check for "if (y>1)" to avoid y going below zero.

Code: ags

if (y>1) {
   SetViewport(0,y);
   y--;
   player.y--;
   }

Yeah, it's definitely possible. That's exactly how the Smooth Scrolling Module works, by calling SetViewport every frame in the repeatedly_execute_always. If you post your scrolling code, it would be easier to locate the problem.

The main problem with dead ends is that most players, when they realize, will just abandon the game. Those who are patient enough to replay it will most likely do so using a walkthrough, to avoid ending in a similar position again. In either case, you've just excluded a bunch of players from finishing the game in the way it was meant.

I'm not against additional content or bonus endings for thorough players. But even if I missed some hidden item along the way, I still want to be able to finish the game in a more or less succesful manner. One of the main problems in 'A Tale of Two Kingdoms' was that unless you picked up an item at the very beginning (that you had no reason to want in the first place, and the acquiring of which involved several actions that seemed out of place for the situation), you missed out on several subplots, a bunch of gameplay and had no way of getting the optimal ending. If it wasn't for the commentary track that provided motivation for another playthrough, there's no way I would have started all over just to see the proper ending.

She looks like she's ice skating! Sorry, I had to say it - that was my first reaction, and I'll address it below.

I think the sprite itself ended up well, but as you say the animation doesn't really flow. Framerate is an issue of course (at least in my browser the animated gif is much too slow, it looks a lot better when I import it into AGS and run it with a delay of 5), but I think one of the main problems is that your end-positions are quite extreme and the low amount of frames make the jump between them quite sudden. 6 frames is in itself quite few for a hi-res animation, but it doesn't seem much of a problem when played at a higher framerate.

Instead, try in-betweening some of the elements and make the end frames more subtle. For instance her torso seems to be rocking back and forth like a boat (very noticeable on the neckline a breasts) in very sudden jumps between frames. I also think the final hand position in front of her is too extreme, it seems she's behind her wrist rather than just moving her lower arm forward. And as for the "ice skating" issue, I think it would help a lot if her legs moved inward rather than to the sides when they bend backwards.
There's some minor problems with the shading of the dress (the vertical shadow appearing on her thigh is somehow distracting) and the shoes look a bit lumpy in the forward position, but that's something to deal with when you've perfected the movement itself.

All that said, I think this is very good work for someone who (as you said in the other thread) doesn't consider themselves very artistic. If you can achieve this level of movement in just 6 frames, you're well on your way to becoming a good animator.

It only works in 256-color games and is accomplished by cycling the palette (or in this case, a certain part of the palette since the cockpit interior doesn't change). Check up on the function "CyclePalette (int start, int end)" in the manual. If your game is 16- or 32-bit color, you'll have to create the effect as an animation instead.

Edit: See also the palette section in the tutorial for a more thorough explanation.