Re: Tutorial campaign

[Jens Granseuer <jensgr@xxxxxxx>]

On 20.01.2005 00:42, The Fox wrote:
> > On 18.01.2005 22:08, The Fox wrote:
> > Ok, this should work now. I've added a new "player" parameter to the
> > unitposition trigger. I'm not sure how to resolve that "or anywhere
> > beyond it" part without using a ridiculous number of events, though.
> 
> Okay, it works now quite nicely. Good work. The "area" problem could 
> be perhaps solved this way: put the checking of "tpos = x/y" into a 
> simple loop so that it can check something like "tpos = x1/y1;x2/y2;
> x3/y3..." and if finds a match, the event will be triggered.

Yeah, well, the problem is that an event has three data slots to store
information and three slots to store trigger information. The
unitposition trigger uses one slot for the position info, one for the
unit (id or type), and one for the controller. There is no space to
store multiple coordinates.

> > > - the depot entrance at 17,12 is conquerable even before it's 
> > > "completed". It has undesirable results, thus we need some sort of 
> > > Disable Shop event or something (or alter the map scenario).
> > 
> > I've tweaked the path finder a bit to make this work. As long as
> > the unit cannot cross the hex you replace the entrance with, it
> > won't get in.
> 
> Great, this is absolutely sufficient for the tutorial mission. It has 
> one drawback. When you double-click on the "not-entrance", you get the 
> "access denied" message or the depot window (as player 2). Well, the 
> depot *is* there.

I'll iron that out, too.

> > > The mines are already in place (I'd really like to be able to 
> create 
> > > units with different squad size and experience).
> > 
> > It's possible but the event already uses all data fields available.
> > That means we would have to cram several values into a single field.
> > Can be done, but will remove compatibility with older releases.
> > (I wouldn't mind too much, but there seem to be people who do ;))
> 
> I'm not sure what do you mean by this. There aren't enough data fields 
> in program or (more probably) we don't have any more qualifiers (like 
> unit or tunit) defined? If so, it's not that difficult to add one more 
> (something like unittype = size/exp), is it?

As I explained above there are not enough fields in the program. Of
course, we haven't defined the qualifiers either, but that's easy to
fix.

> The mission is now almost complete with few minor issues (again):
> 
> - the "area" problem as mentioned above
> - when the heavy tanks stop on the bridge, the following happens: the 
> createunit event is triggered (but not executed), the sethex event 
> triggered by unitdestroyed is executed (because the mine wasn't 
> created) and then the createunit event is executed. 

I'm not sure I understand what you mean. If the createunit event is
triggered, why isn't it executed? How do you know it's been triggered?
Or are you simply saying the execution order is wrong? If so you can
probably fix that by rearranging the events in the proper order in
the .src. I'm not entirely sure right now whether the order is stable
through saving and loading, but we can make sure it is.

> My idea is not to delete the unit when it is destroyed but rather only 
> *mark* it as destroyed. This would probably also solve the removeunit 
> vs. unitdestroyed problem you are trying to solve in another thread. 
> This way I would be able to create a trigger triggered by destroying 
> of not-yet-created unit (by its id). OTOH it would break the 
> compatibility once again :-(.

I think this can be done differently (if I understand you correctly).
I'm still not convinced removeunit is a good idea (or rather, I agree
it would be nice to have, but I'm not sure the hassle's worth it).

Jens