Re: Tutorial campaign

[The Fox <thefox@xxxxxxxx>]

> 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.

In event.h I read:

  short e_tdata[3];             // trigger data
  short e_data[3];              // event data

It looks like it can be quite easily expanded (with quite destructive 
effect on backward compatibility). 

I'm not sure how does the program load/store/save/process events but 
imagine that you load the "x1/y1;x2/y2;x3/y3" as a string and process 
it in the Event::CheckTrigger like this:

unit_in_place = 0;
while (we can fetch another coordinate pair from the string) {
	fetch_coords(x, y);
	if ((x == unitX) && (y == unitY)) {
		unit_in_place = 1;
	}
}

Is it possible?


> > 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.

I have an idea for solving (very similar to previous one):

Have the unit definition as follows: Infantry/3/6 and process it in 
Execute so that infantry of size 3 and experience 6 (*) is created. Or 
am I completely wrong?

 
> > 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.

Well, this was completely my fault. Now I realize that even the order 
in .src (not just the event id) does matter.


> > 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).

Well, actually... It would be useful only in tutorial and perhaps in 
few specific missions. If it's really non-trivial to implement, we 
should discard it.

Andrej
____________________________________
RAMMSTEIN, 22.02.2005 o 20,00, Bratislava Incheba, 
Info: 0904 666 363, http://www.xl.sk