A litle help with coding (Erm... code heavy post)

[Poe42147]

Hey all... erm... the best way to describe what i'm doing is stars flying from random points at the top of the screen to the base of the screen... That's no drama, I've got four (o2,o3,o4,o5) "stars" (so i can have more than one on the screen at a time without issues), and they run through fine the first time, but when i reset V64 (basically the timer for when the stars actually start and end), the stars start from further down the screen around the 40agi-pixel mark... For the life of me i can't work out why. Heres part of the code for it:

Code: [Select]

if (isset(f50)) {
v64++;
if (!isset(f60)) {

if (v64 == 10) {
get.posn(o1,v61,v62);
v71 = 34;
position.v(o2,v61,v71);
draw(o2);
v70 = 130;
move.obj.v(o2,v61,v70,150,f45);
}
if (v64 == 30) {
get.posn(o1,v61,v62);
v71 = 34;
position.v(o3,v61,v71);
draw(o3);
v70 = 130;
move.obj.v(o3,v61,v70,150,f46);
}
if (v64 == 60) {
get.posn(o1,v61,v62);
v71 = 34;
position.v(o4,v61,v71);
draw(o4);
v70 = 130;
move.obj.v(o4,v61,v70,150,f47);
}
if (v64 == 65) {
get.posn(o1,v61,v62);
v71 = 34;
position.v(o5,v61,v71);
draw(o5);
v70 = 130;
move.obj.v(o5,v61,v70,150,f48);
}
if (v64 == 70) {
v61 = 0;
v70 = 0;
v62 = 0;
v64 = 0;
}
}
}
if (isset(f45)) {
reset(f45);
erase(o2);
}
if (isset(f46)) {
reset(f46);
erase(o3);
}
if (isset(f47)) {
reset(f47);
erase(o4);
}
if (isset(f48)) {
reset(f48);
erase(o5);
}

Basically, It randomly generates a horizontal position (vertical is preset...), and the "star" then moves to the base of the screen (move.obj.v), when it gets there the "star" is erased, until the timer reaches 70, and then it resets and starts again.

But then the preset vertical position somehow (Through elven magic maybe?...) defies itself and goes further down the screen, so the the stars start somewhere around the centre of the screen.

Long winded am I, indeed.

I've tried setting the variable (71) exactly at the point it is used, and STILL it happens.

*sigh*

Any help would be much appreciated

[Kon-Tiki]

Can't see what's wrong with it by reading through this part of the code. Only thing I can suggest is you either put

Code: [Select]

if (v64 == 70) {
v61 = 0;
v70 = 0;
[b]v71 = 0;[/b]
v62 = 0;
v64 = 0;
}
and see if it still does that. If it does, some more of the code'd be helpful. I'll check the code out for you tomorrow evening (don't have AGI Studio around here ) if it's not solved by then.

[Cosmic R]

not sure if this is the problem, but check you dont have stuff like set.horizon(40), and also you may want to ignore.obj(o1) (I think that's the command) to make it ignore the priority of the object so that it can pass through anything. hope that helps.  let us know if it works.

[Joel]

When posting code for others to review, please use proper indention techniques. It aids comprehension of the logic. Define names would be nice, too, so we don't have to try to figure out the purpose of each variable, and you've got quite a few of them.

In any case, I couldn't reproduce the exact behavior you're describing based on the code you've provided. I was, however, getting other bizarre behavior such as flashing objects at the top of the screen which I am almost certain is due to interaction between your motion start code and your object erasing code. You should make sure that the animation is done before trying to restart it. Based on the behavior I saw, it looks like you tried to do that with counters, but the motion restart code executed before the object erase code when the animation was done (hint: put print statements inside the major portions of this code so you know when stuff is happening). The flags you supplied to move.obj should be used to determine whether it's ok to restart the animation.

[Joel]

Correction: in the code you posted, the objects don't even reach their intended destination. They get to about y 105 before resetting to the top, and they leave garbage behind on the screen. This is based on leaving f50 set the whole time. However, without knowing what condition sets f50 (or even what f50 is there for), I can't reproduce your behavior.

[poe42147]

f50 is simply set to initiate a timer. Each time the logic compiles v64 ++ adds to v64, and thats how we get to:

Code: [Select]

if (v64 = 10) {}

etc

I set f50 so i can reset it later and remove the timer function OR use that specific timer (v64) later in that logic.

f50 is set under the f5 flag, so when the room first loads up it starts the timer...

Sorry to have offended you dude, but I don't use defines, nor do I indent the code. I use programming for other things other than agi, so i just try and keep everything in the same style, as opposed to learning 50 different ways of defining each object/variable/whatever in each language i use.

I've totally rewritten the code, although i still don't understand why the code in it's previous (as posted earlier) form wouldn't work.

It's in a similar form to the sand-speeder logic in space quest 1, where the rocks are coming down the screen. In fact, i originally was going to initiate this section of the code with a variable, but after breaking down the code in that logic, i initialized it the same way as sierra did.

Thanks for the help and feedback all.

[Joel]

You didn't "offend" me  

I'm just saying that if you're going to post your code on the message board for people to look at, it needs to be readable. It helps us help you.

AGI is not the only language I program in, either. However, I have yet to use a programming language where indention didn't significantly improve code clarity and maintainability. Still, you're perfectly welcome to use confusing style to your heart's content.

To the issue at hand, here's the code as I used it:

Code: [Select]

#include "defines.txt"

if (new_room)
{
  v255 = 1;
  load.pic(v255);
  draw.pic(v255);
  discard.pic(v255);

  animate.obj(o1);
  animate.obj(o2);
  animate.obj(o3);
  animate.obj(o4);
  animate.obj(o5);

  load.view(110);
  set.view(o1, 110);
  set.view(o2, 110);
  set.view(o3, 110);
  set.view(o4, 110);
  set.view(o5, 110);

  set(f50);

  show.pic();
}

random(0, 150, v200);
random(0, 160, v201);
position.v(o1, v200, v201);

clear.lines(20, 23);
get.posn(o2, v200, v201);
display(20, 0, "o2 x: %v200 y: %v201");
get.posn(o3, v200, v201);
display(21, 0, "o3 x: %v200 y: %v201");
get.posn(o4, v200, v201);
display(22, 0, "o4 x: %v200 y: %v201");
get.posn(o5, v200, v201);
display(23, 0, "o5 x: %v200 y: %v201");


if (isset(f50))
{
  v64++;

  if (!isset(f60))
  {

    if (v64 == 10)
    {
      print("starting o2");
      get.posn(o1,v61,v62);
      v71 = 34;
      position.v(o2,v61,v71);
      draw(o2);
      v70 = 130;
      move.obj.v(o2,v61,v70,150,f45);
    }

    if (v64 == 30)
    {
      print("starting o3");
      get.posn(o1,v61,v62);
      v71 = 34;
      position.v(o3,v61,v71);
      draw(o3);
      v70 = 130;
      move.obj.v(o3,v61,v70,150,f46);
    }

    if (v64 == 60)
    {
      print("starting o4");
      get.posn(o1,v61,v62);
      v71 = 34;
      position.v(o4,v61,v71);
      draw(o4);
      v70 = 130;
      move.obj.v(o4,v61,v70,150,f47);
    }

    if (v64 == 65)
    {
      print("starting o5");
      get.posn(o1,v61,v62);
      v71 = 34;
      position.v(o5,v61,v71);
      draw(o5);
      v70 = 130;
      move.obj.v(o5,v61,v70,150,f48);
    }

    if (v64 == 70)
    {
      print("timer end reached");
      v61 = 0;
      v70 = 0;
      v62 = 0;
      v64 = 0;
    }
  }
}

if (isset(f45))
{
  print("o2 done");
  reset(f45);
  erase(o2);
}

if (isset(f46))
{
  print("o3 done");
  reset(f46);
  erase(o3);
}

if (isset(f47))
{
  print("o4 done");
  reset(f47);
  erase(o4);
}

if (isset(f48))
{
  print("o5 done");
  reset(f48);
  erase(o5);
}

return();

Every time through the v64 counter, I got a sequence similar to "starting o2", "timer end reached", "starting o2", "o2 done" which made o2 disappear as soon as it was redrawn at the top of the screen. After the next "starting o2" it would fall down the screen normally again.

This was due to the v64 counter running constantly, even though o2 should not have been restarted until its erase code was executed.

[poe42147]

To stop it from... erm... crapping itself, you have to define the stepsize, so o2 is off the screen before the timer reaches 70...

I've had a play with you code and it's wacky   ha ha I couldn't get it to work at all.

After i set the stepsize it went real crazy for some reason, so I'm still having a play with it, trying to use some of the old, some of the new... I'll let you know how it goes, thanks.

[Joel]

When I set the stepsize of all the objects in the code I posted to 2, the code worked fine for me. The problem may lie elsewhere in the logic. Without more of the code, I can't help you with that, though.

You'll naturally need to adopt the code I posted to suit your needs -- but ultimately the code I posted is the code you posted. The scaffolding is probably different, because I had to make it run in a junk AGI Studio project. My room numbers and view numbers are likely different than yours. Other than that, it's exactly the same. The only thing I actually added to your code was the print statements and display statements to tell where the objects were.