[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [palito-dev] /cheat
From: |
Tom Barnes-Lawrence |
Subject: |
Re: [palito-dev] /cheat |
Date: |
Sat, 16 Aug 2003 04:56:20 +0100 |
User-agent: |
Mutt/1.3.28i |
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