[Freeciv-Dev] Re: (PR#14443) city walls not visible (effects problem)

["Per I. Mathisen" <per@xxxxxxxxxxx>]

<URL: http://bugs.freeciv.org/Ticket/Display.html?id=14443 >

On Thu, 17 Nov 2005, Jason Short wrote:
> A big part of the ugliness is it's difficult to tell where the problem
> is even going to crop up.If you do a wrong query it can happen.  But
> how are you supposed to know what queries are right?It's in the
> documentation, but there is currently no compile-time or run-time
> detection of errors.Run-time detection would be easy enough (though
> tedious) if each effect type told which query function it was to be used
> with.However there may be a more elegant way to merge query
> functions...or to add a "needs_unit" flag to an effect type to show it
> can only be used with a query function providing a unit.

Run-time detection is necessary.

> 2.Use the attached patch that changes the way unit* req queries work.
>  In this patch if no unit is given the req returns TRUE not FALSE.This
> is basically a hack to get around the problem (the problem is such
> queries should not be called at all).However it would solve the
> city-walls problem, potentially with unforseen side effects.One
> forseen side effect is that coastal defense and SAM batteries will be
> drawn as city walls.

I think this solution is fine. We should be changing the way coastal and
SAM work anyway.

> 3.Change city_got_citywalls to check building presence not effect
> presence.This is almost certainly a good idea anyway.  However it
> still doesn't solve the underlying problem.

How would this not be a regression to B_WALL and B_CITY that we have
worked so hard to leave behind?

> 4.We could add checks inside the reqs (NOT effects) code directly...if
> a reqs check is done and the target is not given, we could crash or
> print an error.However this might have unforseen side effects as well
> since it's not clear to me that these queries are /always/ invalid.

I do not understand this one.

> No matter how you slice it the biggest problem is always going to be the
> AI.Solving individual issues in the core code is pretty simple (fix#3
> is probably right in this case) but in the AI code you have to be really
> careful about what queries you do.

Fix#3 would be nasty to the AI, but I do not see why the other solutions
should be. As long as we know how to do the queries, we can use virtual
cities and virtual units and so on to do the queries, as we do so often
now already.

  - Per