Hey Trent, Thanks for your wise words. --- Trent Piepho <xyzzy at speakeasy.org> wrote: > 1. Anywhere where me_p is called, it is first > initialized to something > sane at the beginning of that function. Dunno if > this is necessary, but > it doesn't hurt. > > This is not what you are doing. You are defining a > new local variable > called me_p that is overriding the global one. Bad > coding style. If me_p > is getting called before it is initialized in > socket.c, you should figure > out why and fix it. Thanks for clearing this up. I wish I knew programming. But I really don't. I'll try removing these local variables and see if it starts crashing again. I have a feeling, it won't. > 2. Anywhere where me_p->closest_pl or p->closest_pl > is NULL'd out, I > re-wrote the code so it leaves it alone. > p->closest_pl = NULL. > For some reason, once this is done, closest_pl > stays NULL for the > rest of the program until you kill the program and > restart it. > > It's clear that setting closest_pl to NULL means > something, that the player > isn't near a planet. Setting it to some random > planet will just make the > bot make mistakes. What would be the correct thing > to do, would be to fix > the bug in closest_planet() that makes it fail, > rather than just making > random changes with no clue what effect they will > have. Been reading through that code. There's no reason why closest_pl should ever get set to NULL. There's ALWAYS a closest planet. The reason closest_pl gets set to NULL is because the enemy player cloaks, and so the client has no information. It sets it to NULL instead of some possibly dubious planet. I think leaving stale information such as this should actually be to the bots advantage. The code change, makes it so it just leaves it alone instead of setting it to NULL. > > BTW, the bug in closest_planet can fix be fixed > thusly: > --- update_players.c.old Wed May 17 20:52:41 > 2006 > +++ update_players.c Wed May 17 20:50:11 2006 > @@ -1320,7 +1320,7 @@ > > { > register k; > - register struct planet *pl, *rp = NULL; > + register struct planet *pl, *rp = opl; > register d, mdist = INT_MAX; > > if(opl && (mdist = ihypot((double)(j->p_x - > opl->pl_x), > Hey! I think that would work! I should add that in too! > Sorry, I'm too lazy to install yet another revision > control system. no problem. > 3. Replaced all instances of mfprintf with regular > fprintf. mfprintf > causes SIGSEVs, but I don't know why. Function > looks fine to me, but it > extensively uses parameter overlloading, it's tough > to debug. So > just don't use it!!! > > It probably has to do with it using varargs instead > of stdargs. You > should convert it to stdargs. Heh. I wish I knew what you are talking about. I don't know enough about c to know how to fix this. > 4. Added some code somewhere to check "pl" is good. > Every once in a > while, this turns into NULL for unknown reasons. > The situation clears > itself after a while. > > Again, find out why it's set to NULL, and fix that. I plan to do that, as I am sure there are some consequences (even though they don't crash anymore). I originally did the same thing to test for NULL'ness for me_p->closest_pl. And just avoid the SIGSEV. This resulted in bots that started to not report where they wanted to take their armies to. > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/listinfo/netrek-dev >