walking below the screen (SOLVED)

[EnterTheStory (aka tolworthy)]

Can I make it so that if I click in the middle of the screen, ego walks there as normal, but if I click at the very bottom of the screen, ego walks further toward me so I only see him from the knees up?  Is that possible?

edit: I assume this would need character.z  I don't need the exact code (I can work that out later), I just need to know if it's possible in principle. Right now, before I learn the details of AGS coding, I'm adding 140 rooms from my old Sludge game. Many of those rooms rely on ego being able to move very close to the camera.

[Khris]

You could add a region at the very bottom and put something like "player.Walk(player.x, 280, eAnywhere);" in "p walks onto region". You'll probably want a "player.ChangeRoom(...);" to go after that.
So, in general, the player can move off the screen. But since he's going to leave the walkable areas, you'll have to use the eAnywhere param.

Alternatively, you can use Character.AddWaypoint() which ignores walkable areas, too.

Code: ags

// inside on_mouse_click / eMouseLeft

  if (mouse.Mode==eModeWalk && mouse.y>Room.Height-10) {
    player.Walk(mouse.x+GetViewportX(), mouse.y+GetViewportY());
    player.AddWaypoint(mouse.x+GetViewportX(), Room.Height+40);
  }
  else ProcessClick(...)

This will work for all rooms. You can add a check for player.Room to make it work in specific rooms only.
(The ViewportX/Y commands are used to convert the mouse's screen coords to room coords, since Walk require the latter.)

[EnterTheStory (aka tolworthy)]

Thanks. As long as  it's possible, that's all I care about.

Character.AddWaypoint() which ignores walkable areas

I didn't know addWaypoint ignored floors. Is there any alternative? I planned to use it extensively for background crowds, and I don't want them to walk though wals and trees.

[Khris]

You could write a routine that constantly checks Character.Moving and assigns them new coordinates, sending 'em on their way with .Walk.
I've never used strazer's CharacterControl module, but I think it should be perfect for the job, too.

[EnterTheStory (aka tolworthy)]

You could write a routine that constantly checks Character.Moving and assigns them new coordinates, sending 'em on their way with .Walk.

Would that risk re-starting the walk animation every time, so the character stutters or slides?

[Khris]

The standing frame would be visible for one frame, if at all. The smoothness of the walk-cycle might suffer a bit, but I'm pretty sure it won't be that noticeable.

[EnterTheStory (aka tolworthy)]

Thanks. And presumably Character.Moving could be used instead of addWaypoint, to wait until one walk has finished before starting the next?

Edited to add:

Will walking below the screen raise problems with the "walk behind" areas? or is it possible to set a baseline BELOW the level of the bottom of the screen? Can baselines be edited manually?

[Khris]

You can set baselines manually in scripts, e.g. oTree.Baseline=165;
I'm not sure about the behaviour with the char off-screen, or the possibility to set a baseline off-screen, but you could use a non-clickable GUI to replace a failing walk-behind.

[EnterTheStory (aka tolworthy)]

You can set baselines manually in scripts, e.g. oTree.Baseline=165;

Thanks. Presumably oTree refers to an object called tree? Can the same be done for color regions? My rooms have background images, floors, and walkbehind areas defined by an imported 16 color bitmap. So for example if I wanted to reset the blue coloreed area to y ==200 then I'd note that blue is palet number 1, and would the code be something like walkBehind[1] = 200 ??

[Ashen]

Read the manual: SetWalkBehindBase. (E.g.: SetWalkBehiendBase(1, 200);.)

For what you're after here, though, maybe it'd be easier to include a little extra on the bottom of the background graphic, and use SetViewport to stop it scrolling past a certain Y value? That way you wouldn't have to worry about setting baselines 'outside' the Room, continuous scaling of characters would still work, etc.

[EnterTheStory (aka tolworthy)]

For what you're after here, though, maybe it'd be easier to include a little extra on the bottom of the background graphic, and use SetViewport to stop it scrolling past a certain Y value?

The perfect solution! Thanks!

As a new user I've got to say I'm highly impressed by AGS. Some parts had me worried at first - like there appears to be no way to define an object globally (e.g. "a tree" or "a window" with all its possible interactions) and then drop it into a dozen rooms. But after thinking about it for a couple of hours I think I know how it could work.

Thanks again.

[Khris]

I'm not sure about the solution you came up with, but if you want a global object, simply use a character instead.

[EnterTheStory (aka tolworthy)]

Would that work for hotspots? For example, a lot of my background objects contain trees. I want a generic "tree" object so that I don't have to add the same code ten times per room. I can see that an invisible tree character could be placed in the room, but I don't know how it would be called when the user clicks on one of the tree shapes.

If that could be made to work it would be simpler than my idea, which was to add code to the global script so whenever you click on anything its name is compared with a list of global objects. I have a suspicion that my plan may not be as simple or reliable as I hope - your way sounds better, if it could be made to work.

[Ashen]

This sounds like a confusion of vocabulary to me, and since I'm kind of obsessive about details, I'd like to clear that up.
You don't seem to want a 'global object' in the AGS sense of an actual thing that can move between rooms, but rather a way to call the same code from multiple locations without having to duplicate it. To make an AGS Object (like you'd create in the 'Objects' pane of the Editor) that can move between rooms, Characters are the way to go. For the second thing, not so much.
I suppose you could set a Hotspot/Object/whatever's 'Any click' interaction to cTree.RunInteraction(mouse.Mode), I don't think you'd even need cTree to be in the Room it was called from, and it'd run the code as defined in a single place (the Character interaction functions in the Global script). However that's really no different from just making your own function and calling that - which it sounds like you're doing already - except that it means you waste a bunch of characters.

If you post the code you're currently using, and why you think it mightn't be as reliable as you'd like, we could maybe suggest ways to improve it if needed.

[EnterTheStory (aka tolworthy)]

Thanks for the advice.

If you post the code you're currently using, and why you think it mightn't be as reliable as you'd like, we could maybe suggest ways to improve it if needed.

I haven't written it yet - it's just pseudo-code. But I need to plan ahead because this kind of decision affects the basic design of the game. The reason I am cautious is (a) I'm new at AGS, and (b) this means going further away from the "normal" way of doing things. Long experience tells me that somewhere down the road this will lead to some minor but hard to trace bug. Bug tracing takes longer than anything and is my least favorite job!

[Ashen]

Writing your own functions to avoid duplicating code all over the place pretty much is the normal way of things in AGS - that's one of the reasons the ability is there. (In so far as there is a 'normal' way in AGS, at least.)
It's also easier to trace bugs if your code is more centralised, and AGS is pretty good about telling you where they are, anyway.

What you're after wouldn't be too hard (well, this part won't - it's an ambitious project you're planning), so don't let that worry you. You'd just need a function to check a value (to see whether you clicked a Tree or an NPC, for example), and the Cursor mode (for what interaction to run) - which is pretty simple - and some way of running that function - which could range from simple (like calling it from the 'Any click' interaction) to slightly trickier (use Custom Proerties and a bit of fiddling in on_mouse_click or unhandled_event to handle it automatically). Since this is kind of off the original topic of the tread, feel free to PM me, if you want to discuss it further. (Or start a new thread when you've got some actual code, of course. Hopefully, by that point you won't be as new to AGS, and not as unsure about what's possible.)

[EnterTheStory (aka tolworthy)]

Thanks for the suggestions. I'll probably be back when I have some real code in week or three. The important thing is I know now that everything I want is possible, and roughly the form it will take. Thanks again.

[RickJ]

I would like to add to what Ashen has said about calling global functions, especially in your case where you intend to have multiple installments via RunAGSGame().     I think the normal  "AGS way" of doing things is to create event handler functions, via AGS's event tab, for each object, hotspot, etc and then call one or more functions from there to do the work.  If the function is something that can be used multiple times then it's made global.  I then to leave only the highest level of game logic in eevent handlers functions and push the heavy lifting down into functions.  In your case you could use modules to define your global functions so that they could be used in subsequent games/chapters.

[EnterTheStory (aka tolworthy)]

On the advice of the mods I just marked this thread "solved." Thanks to al those who helped! The topics evolved a little, so if any other newbies are reading, here is what I learned:
(1) A character's can be forced lower than normal by using character.z, though we have to be careful with scaling, since he will appear closer to the camera yet no larger, and with walking behind objects)
(2) a screen can be made lower than the visible part, remembering to use 'setViewport' to keep the room from scrolling down, and remembering that the uer cannot of course click below the level of the visible room
(3) trapping a mouse click or mouseover for the purposes of special (click-on code) is not as difficult as it sounds

Sorted!