Re: [palito-dev] /cheat

[Tom Barnes-Lawrence]

On Fri, Aug 15, 2003 at 04:56:57PM -0300, address@hidden wrote:
> 
> Also, it seems you can't see enemy units in the latest (08-14) version.
> :/
> This unit-update code is still very imature and incomplete..

It didn't compile for me, saying:
palito/visual.c: In function raw_menu':
palito/visual.c:719: parse error before loat'
palito/visual.c:720: ' undeclared (first use in this function)
palito/visual.c:720: (Each undeclared identifier is reported only once
palito/visual.c:720: for each function it appears in.)

Looking in the source:
710  void draw_menu()
711  {
712          int i;
713          int icsz2 = icon_size/2;
714          if(menu_owner == NULL) {
715                  if(last_menu_owner == NULL)
716                          return;
717  
718                  // exit animation
719                  float d = client_width - menu_rect.x;


 Ah, the wonders of declaring variables local to blocks. This time,
you've got one after the first statement of the block- I didn't know
any version of C supported *that*...

 Incidentally, why do you keep doing that? Back when I'd been trying to
find the bug with the X version of flush, I was trying to watch what
a for loop did. But I'd put my breakpoint after the loop, and so
when it reached it, those variables that had been written were no
longer available (because they were only local to the for loop).
Boo! Hiss! Boo! And so on. So is there some advantage to doing this,
or is it just a matter of programming style?

 Anyways, swapping those lines around in visual.c made it compile OK.

 Cheers for the link to IWR, BTW. I'll put out a new bugfixy version soon,
but I'll need to discuss heightmaps and stuff before I can do more.

 Tomble