Cygwin Tcl/Tk on Trial

Cygwin Tcl/Tk on Trial

[Eric McDonald]

After examining the facts of the case, I am hereby judging the Cygwin 
Tcl/Tk implementation to be unsuitable for use with Xconq.

It is found wanting because it does not provide an usable set of 
substitute functions for X11. Although some X11 functions can be faked 
with dummy implementations, such as is already done with 'XSetTile', 
'XFlush', and 'XSynchronize', there are others which cannot be faked so 
easily, such as 'XPutPixel' (from 'X11/Xutil.h'). The Cygwin Tcl/Tk 
implementation neither implements these functions (AFAICT), nor provides 
headers for them. And, of course, it is unacceptable to mix Windows 
Tcl/Tk and X11; the resulting Frankenstein does actually start (I tried 
it on a whim), but crashes the moment it calls one of the functions from 
the Cygwin X11 library.

By contrast, both the MinGW32 Tcl/Tk implementation and ActiveTcl 
provide their own X11 headers (and thus implementations as well), and 
both are completely usable by Xconq.

If the Tcl/Tk interface was to become independent of any direct accesses 
to X11 functions, we could then utilize the Cygwin Tcl/Tk as well. 
However, since that is not the reality, I am not going to make any 
further efforts to help Xconq build with Cygwin Tcl/Tk. I think it is 
sufficient that we already have two native Windows Tcl/Tk 
implementations that Tkconq can be built with.

Eric

Possible movement improvement

[Brian Dunn]

Both mplayer.c and iplayer.c have the following:

	    /* Try moving sideways. */
	    if (probability(80)) {
		dx = task->args[0] - unit->x;  dy = task->args[1] - unit->y;
		fact = (flip_coin() ? 50 : -50);
		x1 = unit->x - ((fact * dy) / 100);
		y1 = unit->y + ((fact * dx) / 100);
		if (inside_area(x1, y1)) {
			DMprintf("%s blocked, moving sideways to (%d, %d).", unit_desig(unit), x1, y1);
			net_push_move_to_task(unit, x1, y1, 1);
	    	}
	    }

This is called when a unit is blocked and could not perform a move_to task.

If I read the code correctly, it seems to only allow two of the possible four directions to be tried.  I have seen units get stuck behind 'C' shaped obstacles, and this may partly explain why.  A proposed change would be:

	fact = (flip_coin() ? 50 : -50);
		x1 = unit->x - ((fact * dy) / 100);
fact = (flip_coin() ? 50 : -50);  /* this line is new */
			y1 = unit->y + ((fact * dx) / 100);
	
This may allow the unit to try any of four directions randomly.

If this change makes sense, it will need to be in both mplayer.c and iplayer.c.


Brian

Re: Possible movement improvement

[Hans Ronne]

>If I read the code correctly, it seems to only allow two of the possible
>four directions to be tried.

>I have seen units get stuck behind 'C' shaped obstacles, and this may
>partly explain why.  A proposed change would be:

Right. Units getting stuck behind obstacles was a well-known problem with
the old move code. This was fixed by Peter Garrone's path-finding patch,
but since we reverted it (because of sync problems) we are now back to
square one :-/.

>	fact = (flip_coin() ? 50 : -50);
>		x1 = unit->x - ((fact * dy) / 100);
>fact = (flip_coin() ? 50 : -50);  /* this line is new */
>			y1 = unit->y + ((fact * dx) / 100);
>
>This may allow the unit to try any of four directions randomly.
>
>If this change makes sense, it will need to be in both mplayer.c and
>iplayer.c.

The reason for trying only two directions, if I remember Stan's argument
correctly (this has been discussed on the list before) is that he wanted to
keep the general move direction forward. So units can sidestep but not
backtrack. Which will trap them behind a C-shaped obstacle, as you noted. I
see no strong reason not to try out your patch, however. Have you tested it
yourself (in more than one game) and were you happy with the results?

Hans