Messages

Thank you Strazer, I didn't know it would work that way. But it does!

Just to warm it up again!

I'm in need for more frames per loop and I see a lot of people are for quite a long time, but the option is still not implemented.

Did anybody find out a workaround for displaying longer looping animations in the meantime?

Ts,ts! Always the same with those newbies! Always apologising! But you made the right thing: You asked!

I myself had always problems with the positioning of scripts. But it always has to do with programming logic, and you said you know some C and so I believe you know a little how computers "think".

What I want to say with this:

The definition of the animation you made seems to be alright so far. But, if you declare it for the interaction with the object, it is truly clear that it only works when you interact with the object (since this is, what you declared but not what you want). So clear so far?

What you want ist to have it animated during the whole scene, right? So you have to declare it for the scene, say for the room. You can choose between one of the three possibilities given for entering the room.

Excourse: If you want to come back later to the room and the smoke should have stopped then, you should place the animation instructions in the "First time player enters..."- Section and then stop the animation and switch it off when leaving the room. With this, the smoke is visible only with the first appearence of that room.

(Oh, I see Ashen has answered in the meantime. Alright, to get it double should even help twice )

The eNoBlock thing, Ashen mentioned ist absolutely important!!!

Good luck!

Thank you very much for the detailed explanation. I believed that it must have to do with something historical. Since I'm not really a programmer anymore (I was it in my former life ) I have to use my imagination of how the concept of AGS works. So I see there are things only to be displayed, like backgrounds, sprites, videos, music, sound-effects and speech. And, on the other hand, there is something like "the grid", overlaying the scene, which containst all the controls, positions and timings, the whole logical thing. If those things were kept seperately (like video and sound already is) I believe AGS could be even more flexible than it already is at the moment.

I also belive that this pure form of my imagination might not be optimal, since I guess it is a good thing to compress the sprites and other graphics and text which have a benefit from being compressed with the game. But with backgrounds, which are off any logical use, I don't see a reason why they are not treated like videos and sound (except the historical reasons, of course).

Anyway, thanks for your patience with me, and all I hope is now, that maybe the creator and master of AGS hears the call of a little lost sheep with its humble whishes...

Oh, thanks. This maybe didn't come out that clear to me before. So "it work's as designed" once more (sigh). I didn't know AGS makes a big spam out of all the data. I thought different components of the game were treated different as they are used differently. What I want to say is, that I don't see any sense in decompressing and recompressing a background rather to just simply storing and displaying it. Maybe I'm not thinking of all the possibilities (or impossibilities) of AGS making that cluster-to-one necessary, but for realising most screen-by-screen-adventures, especially with photorealistic backgrounds, I see more disadvantages than advantages.

Sorry if I seem to be uncomfortable to you, but it IS a problem for me resulting in a 25 Megs game instead of 3 megs.

-------------------

I saw you put the complete answer in the AGS-Wiki. Thanks for that. I'll be patient and maybe someday...

Wow, thanks! You are so fast! I only had a phonecall after posting and got four answers by now. I really love you, guys!

@Gilbot: Of course I searched the forums and of course I got thousands of Threads, but no answer to my question on the first three pages. Not even a hint. So it's great having this question in a FAQ instead of reading 3000 threads. Thank you.

But, and I am very sorry for this, the compression AGS provides is not as good as it would be, if I could use JPGs. To understand my doubts, I'll give you some numbers. I did the compression of the pics all with IrfanView and the game-zipping with the build in WinXP routines:

bg.pcx (original)Ã,  Ã, -Ã,  Ã, 986 kbÃ,  Ã,  Ã,  Ã,  Ã,  (100%)
bg.pngÃ,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã, -Ã,  Ã, 661 kbÃ,  Ã,  Ã,  Ã,  Ã,  (67%)
bg.jpgÃ,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  -Ã,  Ã,  Ã, 92 kb (!!!)Ã,  Ã, (9 %) (!!!!!)

Compressed Backup of my game workfilesÃ,  Ã, -Ã,  Ã, 9675 kbÃ,  Ã, (100%)
Compressed Backup of the compiled gameÃ,  Ã, -Ã,  Ã, 5379 kbÃ,  Ã, (56%)

So, this is all very nice, what you are saying but obviously not as nice as it could be. And it is not an answer to my question, WHY it is NOT POSSIBLE to import JPGs just like the other formats.

Thanks in advance for some more satisfying attempts.

BTW, I forgot something: @Elliott Hird: The quality of JPGs with Photographs is really good and preferable to all other formats if you want to save space!

Hi,

I didn't find an answer to that technical question, maybe I didn't see the forest because of all the trees...

Why is it not possible to import JPGs as backgrounds? That would really help to keep games small and downloadable.

I started a game with 640x480 Photographs as backgrounds and I guess when I finished it will be about 25 Megs big. With JPGs it might be only 3 Megs  in total.

Oh yes, sorry, but you are completely right! I must have messed something with the sprites resolution or the way I imported them. I filled the slots anew with the same sprite and the same way of importing them and now they all have te same correct size. Sorry for making you worry about your code.

So the only prob remaining is that my player character won't get wet from those few drops. I guess it could help to increase the number of sprites displayed. But I don't know if that would slow down the game too much.

Thanks and be kissed!!

Sometimes soft hits on the back of the head will help!

I didn't realize that defining the condition of an object is treated as an interaction.

Now it works! Many, many thanks!

Hi,

I know I must have done something wrong, but I don't know what...

I try to have an animated object in my room. Therefore I defined an object (it has No. 3) and I defined a View (No. 2, loop No. 0) with the same sprite beginning and followed bei somer other frames making the animation.

Now I put the following lines at the beginning of the room script:

object[3].SetView(2);
object[3].Animate(0, 1, eRepeat, eNoBlock);

Trying to compiole the game results in the following error message:

Parse error: unexpected 'object'

It is no difference having the two line somewhere else in the  room script. I even tried to have them under 'usermode1 object' in the objects interaction pane. No chance!

Does anybody know what I did wrong?

Thanks for your help!

I don't know if I was understood correctly. So let me explain in more detail:

I use the same sprite in all 8 slots. It's a thin white slash. When the game runs and I let it rain, few of the raindrops are displayed in the original size but most of them are displayed much bigger which I think has something to do with your script. What I want is to have them all in the same (, the original) size.

And yes, for the case I didn' cheer enough: I find the script is a really great one and I really love the bubble feature. But the rain really won't make the player wet.

How very nice and easy to use!

Though, I'd like to increase the number of raindrops falling drastically, since what you call a heavy rain wouldn't let me use an umbrella in real life. Except, the drops are that big as they are displayed in the game. Why is that? Where can I change the script for making it using only the original size of the sprites.

Could you help me with those two points?

Thanks in advance!

I'm using the latest official Version 2.7 (not a Beta). Since the walk-to points are not always behaving in the same manner, I understand that it might be difficult to replicate the prob. Of course I know, that clicking somewhere else on the background image SHOULD move the walk-to point to the new clicked on place.

So I try to describe step by step how I replicate the strange behaviour:


- click on the "Setwalk-to point" button

- set the walk-to point somewhere on the background image.

(- now moving the mouse cursor without clicking, normally nothing strange happens)

- now click somewhere on the screen (not on the background image, maybe into the Game-Editor window or on the grey Options area above the background) The Point still is there.

- now move the mouse cursor over the screen without clicking. Somehow suddenly the point disappears. Well it seems, that it does not really disappear but is located somewhere else. At the moment while I'm writing this and switching between the browser and AGS the point appears on another place on the background. And it seems, that only the walk-to point of the active hotspot is affected.

Hope this helps.

Sometimes you only have to write down a problem and the solution will come to you. After sending the thread the illumination came over me.

Thanks to fred anyway. This seems to be a well working solution, and I came to the same idea with the y-coordinate. But I used it to manage the whole thing, since the "Previous-Room-Solution" has the disadvantage that while developing the game it might be possible to put another room between the already connected rooms, and therefore you have to take care of the script. In the following I offer my solution which only affects the involved items:

First I define the state of the walkable areas when entering the room:

Room Editor / Settings / Interaction Editor

Player enters screen (before fadein) / Run script

   if (GetGraphicalVariable("globalGateopen") == 0)  // Gate is closed (I use a global variable since I need this state later in the game)
      {
         if (character[EGO].y <= 160)                        // Character is NORTH of the fence
            {
              RemoveWalkableArea(2);                       // make front area unwalkable
              RemoveWalkableArea(3);                       // make middle area unwalkable (which is between the coords 160 and 180)
            }
         if (character[EGO].y >= 180)                        // Character is SOUTH of the fence
            {
              RemoveWalkableArea(1);                       // make back area unwalkable
              RemoveWalkableArea(3);                       // make middle area unwalkable
            }
      }

Since I can change the state of the gate several times while in the same room and therefore change the state of the walkable areas as well, I have to manage that with every interaction with the gate. Is the gate closed and the gate sprite is visible, I can use the object "closed-gate" to interact with. For the gate open state, I define a hotspot on the open gate shown on the background image to interact with. And here are the scripts for each:

Room Editor / Objects / Interaction... Button

Interact object

   Run script

   if (character[EGO].y <= 160)                        // Character is NORTH of the fence
      {
        character[EGO].Walk(170, 160,eBlock);  // walk to the gate (coords depend where you have your gate)
        RestoreWalkableArea(2);                       // make front area walkable
      }
   if (character[EGO].y >= 180)                        // Character is SOUTH of the fence
      {
        character[EGO].Walk(170, 180,eBlock);  // walk to the gate
        RestoreWalkableArea(1);                       // make back area walkable
      }
   RestoreWalkableArea(3);                           // make middle area walkable
   object[0].Visible = false;                            // let gate disappear

   Game - Set variable value (globalGateopen, 1)


Room Editor / Areas / Hotspots / Interaction... Button

Interact hotspot

   Run script

   if (character[EGO].y <= 160)                        // Character is NORTH of the fence
      {
        character[EGO].Walk(170, 160,eBlock);  // walk to the gate
        RemoveWalkableArea(2);                       // make front area unwalkable
      }
   if (character[EGO].y >= 180)                        // Character is SOUTH of the fence
      {
        character[EGO].Walk(170, 180,eBlock);  // walk to the gate
        RemoveWalkableArea(1);                       // make back area unwalkable
      }
   RemoveWalkableArea(3);                           // make middle area unwalkable
   object[0].Visible = true;                             // let gate appear

   Game - Set variable value (globalGateopen, 0)

Thats it!

Thanks!

Hi,

I know, that there were a lot of threads for similar problems but I couldn't make a solution for my prob out of them. Maybe a bright mind could give me a hint.

Imagine the following:

There is the middle room out of three rooms. Exits to the north and to the south. In the middle, theres a fence with a gate. I have WalkableArea(1) which is in the north of the path, I have WalkableArea(2) in the south and there is also WalkableArea(3) underneath the gate and at the borders of the unwalkable Area underneath the fence. This is mostly because of cosmetical reasons for keeping the character from running into the fence, when coming from the other side. The background image shows the open gate. The closed gate is defined as an object.

The first time, I enter this room, the gate is closed and I'm coming from the south, so WalkableArea(2) must be enabled, (1) and (3) must be disabled. When I open  the gate and leave it open, all three Areas must be and stay enabled. If I close the gate from the north (2) and (3) must be disabled and BE IN THE SAME STATE when I leave the room and return to it (All WalkableAreas are automaticaly enabled instead). If I leave to the south having the gate closed, (1) and (3) must be and stay disabled.

The only solution I found was using Global Variables and it was some kind of complicated. But I'm looking for a comfortable way since this seems to be a situation found in every adventure game at several places.

Thanks for help!

Thank you very much. I'll try it though.

@TerranRich: Since obviously nobody knows why this happens, I really would like to forward this thread to pumaman for I guess this prob is a bug. Please could you tell me, how to forward it or can you manage it for me?
Pumaman has understandably hidden his eMail-Addy.

Thanks!

Hi,

since I did not find a webmasters address...

Some of the PlugIn Links seem to be dead. I tried to download the Plugins of Erica McLane but I only was routed to a web portal with no indication of the plugins. Do you know where to find the plugins, especially the AGS-File plugin?

Thanks!

@TerranRich: You see, this is why I opened a second thread . My "maybe-solution" was just a part of the whole thing. Is it possible to forward this thread to Chris or do I have to write it all again? (And have it all redundant )

@all: I guess I found out, that it only happens if the usage of the "set walk-to point" button was the latest action. At the moment, I work around the prob by selecting a hotspot colour I don't use.

@Geoffkhan: Thanks for the tip. I came to this possibility as well while playing around and going further in the tutorial. But I think, since the walk-to point option is available, I would rather love it if it works!

Thanks, you guys are REALLY helping me and largopredator out with our problem!!!!!

I wonder what is worse: Opening two threads on the same PROBLEM or holding on an off-topic discussion with gigs of typing and leading your own rules ad absurdum.