Messages

That wasn't it, but thank you anyway.

Could it be that during this dialog, you turn this variable to true. If that's the case, it would only work if you exited the dialog and restarted it (Due to your check being in the start section of the dialog). You could of course turn the OptionState to on in the dialog that turned your variable to true, that way you wouldn't have to leave the dialog.

I have no business answering these questions, just a thought.

I have made a bool determining whether or not the player character has noticed a certain feature on the person he's talking to. If so, a dialog option will be available.

However, the dialog does not recognize the bool.

I would do this:

Code: AGS

@S  // Dialog startup entry point
narrator: You inquire about...
 if (seentattoo == true)
 {
 option-on 2
 }
return

I have defined the seentattoo bool in my globalscript and exported it. I have imported it to the room where the dialog is taking place. Am I missing something here?

Oh, how embarassing. I thought I could be there with a solution. Better luck next time.

WORKS PERFECTLY! AND SO SIMPLE!

Thank you Khris!

Now onwards to the day/night cycle integers. I feel like I can totally do this!

Perhaps the script is trying to remove the walkablearea every time you enter the room. If the walkablearea is already removed and you enter the room again, perhaps the game stalls on trying to remove the same walkablearea once again.

Have you tried using the room_Load function?
Have you clicked the room function initializer at the room editor screen?

Ok, I'm trying again (I keep overloading my questions with useless info).

Question: How do I code in a function that tints the whole screen, or at least a region of the screen (so my status bar is unaffected) in a darker, bluish colour, indicating nighttime? It should be pretty simple, right?

I've tried using light level for a region (only the character is tinted dark, not everything else), and the SetAmbientTint function (stil only the character is tinted).




You can see my first postings further down, (but they're made before I tried hard enough by myself):

I'm doing an animation where cEgo is being manhandled out a door. That all works fine, with the simple tools I have available. Now, as an experiment, I'm trying to also tint the screen, so that it looks like nighttime when he is thrown out.

I use this in my code:

Code: AGS

function room_Load() //preparing animations setup before fadein
{
if (thrownout == true) //if bool says ego is being thrown out
  {
  SetAmbientTint(0, 0, 250, 30, 100);    //no red, no green, 250/255 blue, 30% blue saturation, half illumination. Look like nighttime?
  cEgo.LockView(25); //the real cEgo being invisible while animation is playing. View 25 is an empty frame.
  object[1].SetView(19, 1); //bouncer seen in doorway
  oThrownout.SetView(35, 0);  //object looking like cEgo grabbed by the neck, displayed in front of object looking like bouncer
  }
}

function room_AfterFadeIn() //now for the actual animations
{
if (thrownout == true) // if bool says ego is thrown out
  {
  Wait(10); //cEgo helpless in the arms of the bouncer
  cEgo.FaceLocation(85, 190, eNoBlock); //real cEgo looking downwards, preparation for when he is visible again
  object[8].Animate(0, 5, eOnce, eBlock);  //object looking like cEgo thrown and landing on street
  ShakeScreenBackground(5, 8, 20); //ouch, for 20 game rounds
  Wait(40); //lock game while screen is shaking for the 20 rounds, then continue lock further 20 rounds while bouncer is standing in the doorway, admiring his handiwork.
  object[1].SetView(19, 0, 0);  //image of closed door, no animation
  Wait(120); //the object looking like cEgo is lying around a bit longer
  object[8].Animate(2, 10, eOnce, eBlock);  //object looking like cEgo coming to his senses and slowly getting up
  oThrownout.SetView(35, 1); //object[8] looking like cEgo turned invisible
  cEgo.UnlockView(); //cEgo visible and ready again at the spot where object [8] becomes invisible
  }
}

All the animations works like they should. But there are two problems:

-The screen doesn't tint until all the animations have finished playing. This may have connection to the second problem:
-Only cEgo is tinted. Everything else is not.

I want to tint everything, the whole screen. So, according to the manual, I should use the SetAmbientTint. What am I doing wrong?

EDIT: Sorry for not reading thoroughly. The manual says only objects and characters are tinted.
However, I'm still puzzled as to why only the character is tinted. Objects are not. Can anyone explain why?

[quote/]

Thank you Khris. As always, your codings are a little over the top of my abilities, but they inspire me to make something that works for me nonetheless. And I think this one really does.

The reaction time of the monster is exactly the same when I start a new game. No difference there.

I've noticed this: The monster's speed settings have a lot to say. It doesn't actually alter what happens, but it makes things LOOK very differently. With high speed settings, the monster will still walk across the entire screen before turning to cEgo, but it takes much less time, so it's less noticeable. With low speed settings (it is a huge, bulky monster, not a sprinter), it takes forever to get there, thus its reaction time also becomes slower. Ergo: In the FollowCharacter mode, the follower reacts again after reaching the spot where the followed character stood, not after a certain wait measured in seconds.

Anyway, on to the code (tested and working):

Code: AGS

bool Monsterisalive;

function room_FirstLoad()
{
Monsterisalive = true;
Display("Watch out!");
}

int Monsterchase;

function room_RepExec()
{
  if (Monsterisalive)
    {
    if (cMonster.IsCollidingWithChar(cEgo))
      {
      Display("It's no use trying to run.");
      //Fight initiating. Animation of monster dying
      Display("After a nasty, brutish and short fight, you slay the Monster to the ground.");
      Monsterisalive = false;
      }
    else 
      {
      Monsterchase ++;
      if (Monsterchase > 80)
        {
        Monsterchase = 0;
        cMonster.Walk(player.x, player.y, eNoBlock, eWalkableAreas);
        }
      }
    }
}

This way, the monster checks every game round if the chase timer has reached 80. If not, then add 1. If so, then null the timer and alter direction towards player. And since there are 40 game rounds on a second, the monster changes direction every 2 seconds.

And it works!

I also added a bit about being caught up by the monster.

The walkable area is quite unobstruced and large.

I'll try to recreate the room in another new game as soon as I can and see what happens.

I'll also gladly upload my source files, but perhaps I'll waste less of your time by trying out some things by myself first.
Is there anything in the global scripts that might cause these problems?

Am I correct in assuming that the best thing to do codewise is have the monster be a character, not an animated object?

For testing purposes I filled the entire room with walkable area 1.
What's your setup?

There is one walkable area, walkable area 1. It fills about half the room. I have not yet defined the walk-behinds.
I'm not sure I understand what you mean with setup.

Oh, and the room isn't cluttered by code, it's a new room. In fact, ALL the code in the room is this:

Code: AGS

function region1_WalksOnto()//exit room
{
cEgo.ChangeRoom(10, 308, 155);
}

function room_AfterFadeIn() //pursued when entering room
{
Display("You better watch out for this guy");
cMonster.FollowCharacter(cEgo, 1, 1);
}

Did you try 0, 0?

I did a few tests and 0,0 0,1 and 1,1 all worked fine for chasing the player.

Yup, did those, too.
No effect. The monster is lagging behind helplessly, walking across the entire screen length before stopping to think about changing direction. What am I doing wrong?

Did you remove the line in Room_RepExec?

Sure.

Wait, something's wrong here.

I do exactly (I think) as you and the manual tells me, yet the following character takes a VERY long time to react, and when he does, he walks across the entire screen before checking to see if he needs to turn direction again.

I use this code:

Code: AGS

function room_AfterFadeIn()
{
Display("Watch out for that guy!");
cMonster.FollowCharacter(cEgo, 1, 1);
}

This should make cMonster follow cEgo closely around, running at his speed setting towards cEgo and checking very often to alter direction towards cEgo.
Right?
Any ideas as to why cMonster takes so long to try and intercept cEgo?

Speed is NOT a factor once you set dist and eagerness to 0, that is a special case where you have both characters always set at the same coordinates. Imagine you make a t-shirt as a character; with the "null settings" you can have it so that the shirt is always drawn on top of the player sprite.
1 is the lowest setting you can enter without triggering the special case, and then, walking speed is accounted for.

You can also press F1 in AGS to open the manual, and type the name of any command there to have a full description, together with example code. Sometimes it is hard to figure out what AGS *can* do, but the manual is a good help and a nice read on a sunday afternoon 

Usually, I do read the manual before posting a question here. I guess I got a bit over-excited.

[Character.FollowCharacter(Character* chartofollow, optional int dist, optional int eagerness)]

Character.FollowCharacter(Character* chartofollow, optional int dist, optional int eagerness)

The optional parameters are what you want: dist is the distance the following char will try to "hold", a low value means "closer to the followed". Eagerness is how frequently the follower will update its position; again, a low value means "more frenzied chase".
If you enter 0 for dist AND eagerness, the follower will always, instantly, forever, stand where the followed character stands. This is most likely NOT something you want, so take care! 

The command belongs to after_fadein, not repeatedly_execute, by the way- you only need to call it once (or again when the behaviour must change), so there is no need to call it over and over in rep_exe.

It's that simple! I should have figured that out myself. Thank you for your time and sorry for taking it for something so trivial. I take it the pursuing character's speed still has something to say, yes? Even with dist 0 and eagerness 0, if the player controlled character is faster than the computer controlled character, the player will still outrun the monster when going in a straight line, yes?

I'll take it to the test as soon as I can. Thank you again   

I want my character to be pursued by a monster across the screen. Part of the puzzle is to figure out how to get around the monster.
I made the monster a character, gamewise.

Anyway, to have the monster pursue the character, I'm trying with this code:

Code: AGS

function room_RepExec()
{
cMonster.FollowCharacter(cEgo);
}

It works, but the monster reacts very slowly indeed, and only changes direction towards the character at long intervals, making it much too easy for the character to walk away and around the monster.

I also tried this:

Code: AGS

function room_AfterFadeIn()
{
cMonster.FollowCharacter(cEgo);
}

but that made the monster's response time even worse.

Any suggestions as to how I can make the character "cMonster" more effective in pursuing the player character?

Thanks. That cleared up an important issue.

and this piece of advice:
if (oChair.Graphic != sprite_slot_of_ego_sitting_in_chair) return;
REALLY helped me out in simplifying a couple things, like interacting with a plate thats either filled, empty or not there.

Actually, Khris's solution is less code than yours, and works in a simpler way (it amounts to: if the player is sitting in the chair, refuse to do any action other than "look," or anything to do with the food). If you spend a couple of minutes to work it out, and look up ClaimEvent() in the manual, you'll see that it's not difficult at all. (You would need to add a way to actually get up from the chair, though. He forgot about that.)

The advice he gave you, that whenever possible it's best to base the programming logic on what's actually going on in the game, is a very good principle to follow as a guide. Having your character walking around invisibly, with a "hologram" appearing to sit in the chair, could cause all kinds of unexpected effects once your game logic becomes more complex.

Also, if walking on a certain hotspot (seems like this should be a region, BTW) causes the character to continuously walk to that spot (i.e. getting stuck), isn't there a risk that he could accidentally walk on it and become stuck even when he's not supposed to be sitting in the chair?

Is there a difference between a region and a hotspot for this specific purpose?

Anyway, the risk you mention doesn't happen in the solution I made here. When Ego walks around, he stomps on the hotspot all the time, but it only activates the character.walk command when he's "sitting in the chair". And my game logic isn't more complex than that   
Perhaps when it does become complex, I will have to learn more.

Really, I really do appreciate all of your help, and I'm very happy that you're taking the time. This forum is a real gem. I'm sorry if you feel that my not heeding all of your advice is being ungrateful. We have a saying in Denmark: "If you want to hit the treetops, aim for the stars". Without your advice, I wouldn't have gotten halfway to where I am now, even if I don't do everything the "right" way.

And if we're discussing whats simple or not, well, I do think I found a simple solution in just turning the character view "off" and have him stay in the same spot. The solution with turning "off" the mouse click could provide basis for bugs too, yes? I only need to prevent him leaving the room, no more than that. This should keep in principle with the philosophy of whats actually going on in the game.

And thank you for the ClaimEvent pointer. Did look it up, looks very useful.

oChair.View is a single number, you can't compare loop and frame all at once like that.
But you don't need to anyway.

Code: ags

if (oChair.View == 24)

But what is the problem with having cEgo walk continuously, except for it being "messy"? It works well with me, and I cant really see any error possibilities coming up.

If you want to put a framed picture up on the wall, do you use a nail, or do you hire two guys who hold it in position in turns? It's just extremely bad practice to "solve" issues in such ways. Sure, it might work, but there can always be unforeseen consequences. Technically, the character is moving the entire time, although they're the exact opposite of moving. A module that relies on Character.Moving being correct can screw up everything. So at that point, you have to go back and change the code anyway.
If you just want to kludge this together and don't care about using the proper tools, I won't bother you any longer though

Oh please do bother me. I'm learning a lot from all this. But I have to keep myself entertained too, as I go along. With a learning curve too steep, there won't be time for some fun.

You can add an on_mouse_click function to the room script:

Code: ags

You can extend this any way you want.

The general idea is to not do stuff that doesn't also happen in the game world, i.e. if the food isn't on the table, don't just set it to be transparent but set the .Visible property to false.
You should never do stuff like continuously send the player to their current coordinates just to prevent them from walking somewhere else. It's really messy and will likely cause problems elsewhere.

And, like I did in my example code, never use variables when you can check something else instead. A view changes while the player sits? Just check the view directly.
The more you use the actual properties of game world objects as far as they are reflected by AGS properties (visibility, current sprite, coordinates, etc.), the more readable and less error-prone your code will be.
[/quote]


Whoa, much too complicated for me. I'm way out on my depth for something as advanced as this. Seeing as I can make it work with my simple tools, I think I prefer it to stay that way, with all due respect, and thank you for your kind help.

Instead of using transparency though, I think using views, loops, and frames of loops, may be much better and simpler. Perhaps also, instead of using bool isEgoseated, I could make do with using a check on what view the chair (or cEgo) is set to.

But what is the problem with having cEgo walk continuously, except for it being "messy"? It works well with me, and I cant really see any error possibilities coming up.

EDIT: I can't seem to make it work if I simply check the view of the chair. I would expect it to be something like this:

[code=AGS]
if (oChair.View == 24, 0, 0)     //if the view of the chair is the view, loop and frame showing cEgo not sitting in the chair
 {                            //then have cEgo walk to the chair and sit down 
 cEgo.Walk(147, 123, eBlock, eWalkableAreas);
 cEgo.LockView(25);  //ego not visible and not clickable
 oChair.SetView(24, 1); //ego in chair
 cEgo.Walk(137, 125, eBlock, eWalkableAreas);
 }

What am I doing wrong here?