Can room edge values (LeftEdgeX, etc) be redefined in room script? [SOLVED]

[Fitz]

Is there a way I can change the edges' coordinates inside the room script if/when I want to (say, after a specific event)? In the room's properties, the edge values are referred to as LeftEdgeX, RightEdgeX, etc - but I can't seem to find the right code for changing them.

[monkey0506]

If you read the Room functions page, you'll see that these properties are read-only at run-time. I'm not sure if there's a specific reasoning behind that other than just the fact that certain events are triggered based on the edge positions.

[Fitz]

Yeah, I must've overlooked/forgotten the fact that it said "readonly". But that's not a problem. I had a bunch of ideas of how I can go about scripting the event, and that one seemed the easiest - but others should work just fine.

Thanks, anyway

[monkey0506]

Yeah, I normally would have been a bit more verbose in my post, describing alternatives and such, but I was at work, and time was short.

Not too difficult to get around, but it might be something to look into opening up (making the edges editable at run-time).

[Daniel Eakins]

This should be a simple alternative:

Code: ags

function room_RepExec()
{
  if (someflag && player.x < somevalue) room_LeaveLeft();
}

[Fitz]

Thanks for the response, guys

Daniel Eakins: Thanks! That's actually the second thing I tried and it worked like a charm. Actually, I tried the player.x > thing before, a long time ago, but in my ignorance, I put it in the AfterFadeIn function. And then yesterday it dawned on me why that never worked. Oh well, you never stop learning

Monkey: Yeah, I love AGS for many, many things, it's insanely brilliant - but sometimes things seem a just a little too rigid for something to look perfect. One other thing that's been bugging me is the walking speeds - sometimes one speed looks just too slow compared to the walking animation and the next one looks too fast, and the right speed seems like something halfway between the two. Always managed to work around it in some more or less clumsy ways, but it'd be nice if the gaps between speeds weren't so big sometimes. Or maybe I'm just missing something very simple here?

Meanwhile, the main issue has been solved - the code that Daniel mentioned works perfectly

[Khris]

One other thing that's been bugging me is the walking speeds - sometimes one speed looks just too slow compared to the walking animation and the next one looks too fast, and the right speed seems like something halfway between the two.

The Movement speed setting is determined by the animation frames. In other words, when you draw the frames of the walk-cycle, a foot that's touching the ground must move the same amount of pixels between frames and that number (usually 5 - 10) has to be used as Movement speed.
It's the only way to avoid gliding/moon walking. See Ben304's games for perfect examples.

The other setting is the animation speed which determines the actual movement speed. It's the number of frames that pass before the character is moved and their frame is changed to the subsequent one and can be changed freely, independent of the animation.

[Fitz]

Yeah, I tried tinkering with walking speeds and animation speeds simultaneously. It's just for a short, one-time animation for a secondary character, so it's no big deal - but I'm just crazy about details sometimes. So anyway... WSpeed 6 with ASpeed 5 look pretty close, but just a LITTLE off, as do WSpeed 5 with ASpeed 6. WSpeed 7 with ASpeed 4 look PERFECT, no gliding whatsoever - but it's way too fast. And Wspeed 4 with ASpeed 7 is perfect, too, but too slow. I think I'm going to try something like:

if [cCharacter.Moving == true] {
  Wait(some value)
  cCharacter.x++;}

//because he's moving left

Something like that worked one time before, but I have to check the exact code to be sure.

[Snarky]

Yeah, I tried tinkering with walking speeds and animation speeds simultaneously. It's just for a short, one-time animation for a secondary character, so it's no big deal - but I'm just crazy about details sometimes. So anyway... WSpeed 6 with ASpeed 5 look pretty close, but just a LITTLE off, as do WSpeed 5 with ASpeed 6. WSpeed 7 with ASpeed 4 look PERFECT, no gliding whatsoever - but it's way too fast. And Wspeed 4 with ASpeed 7 is perfect, too, but too slow.

This sounds all kinds of wrong. As Khris explained, the movement speed is a characteristic of the animation. For any walkcycle animation, there's only one correct non-gliding walk speed. WSpeed 7 and WSpeed 4 can't both be right. You want to figure out what your movement speed (which really should be called something more like "step length") is, then play with the animation speed until it plays at the right rate.

Wait, you have the "non-gliding walk animation" option set to true, right?

[Fitz]

Hmm... I'm pretty sure I do, always thought I did, and I never actually had a problem with gliding before. But I just set it to true way in the beginning, because it was "just one of those things to do" - and I never really learned what it actually does. So now I'm probably making all kinds of fool out myself Ohhh well Not arguing about the 4-7 / 7-4 combination, it just had this weird logic to it (multiply both and you get 28) - but I probably did something very stupid somewhere along the way and that is it. Or something switched back to default somehow when I got a new puter, new AGS... I don't know. I had Sephiroth look through the settings and point out all mistakes, and that one never came up. So... I don't know. Right now, I just feel very very stupid

[Khris]

If "movement linked to animation" is set to true:
If we're talking about a character walking across the room, the time that takes is proportional to (animation speed / movement speed).
With a default game speed of 40 FPS, ms 7 and as 4 produce a movement of 70 pixels per second (40*7/4), while ms 4 and as 7 produce a movement of ~23 pixels per second (40*4/7).
What AGS does is move the character by ms pixels every as frames. The product of the two numbers is meaningless.

If sprite production didn't take step length into account and the values have to be eyeballed, it's a good idea to focus on movement speed first until gliding is minimal, then change animation speed until the desired walking velocity is reached.

If "movement linked to animation" is deactivated, the character's final speed is much greater; the character's sprite is still changed every as frames, but movement by ms pixels occurs now every frame. The character's overall speed is thus ms*40 pixels per second, independent of the animation speed. Again, the product of the two values is meaningless.

The confusion over this is understandable, both names are very misleading. Movement speed is actually a distance, while animation speed is actually a delay.

[Fitz]

Actually, the distinction between one of them being distance and the other being delay was clear to me - it's just that everything else was black magic Right now I'm testing how having MovementLinkedToAnimation on/off influences that particular animation and I think I've figured out the right balance. Oh well, it's all trial and error, trial and error Another cool thing I found is negative movement speed values working as fractions of a pixel. There's one place in the game that could really use that.

Anyway, thanks for enlightening me here, I was totally clueless about it.