Fetching monster position (CSBwin)

[beowuuf]

Apologies if I'm being stupid, but am I missing the way to fetch the position of a monster in a standard DSA like you can the party position?

I'm having a stab at the simulation of fusing Chaos (or Order!). After aborting a fuse attempt in the party attack filter (if the attack is against a Lord Chaos/Order), I have it send a signal to a seperate DSA that will then check if Chaos/Order is surrounded, etc and potentially emulate a fusing. Of course, for that I need to know where the critter attacked is actually standing. I used zyx's monster HP idea to keep the monster's ID number alive after the attack, but now don't know how to fetch the position in the new stand alone DSA

[Paul Stevens]

You cannot find a monster from its ID. I would have to
search the dungeon and that is simply too much to ask.

The attack filter provides the monster's location. I have
designed a way for a message from one DSA to another
to carry with it parameters. It sounds like that would be
useful because you could send the monster's location to
the 'seperate' [sic] DSA.

[Paul Stevens]

Look out! The Help in CSBuild is wrong. There should
be a fourth parameter: the delay.
(location type num delay . . . )

[Zyx]

The monster can only be 1 tile away from the party, this gives 4 tiles to check to find it.

[beowuuf]

Right, just looked through some previous posts, couldn't see the way though I remembered it being discussed (filters interrupting other DSAs)

The attack filter provides the monster's location

Not the party attack filter though? I'm also not sure which command you mean - is it the &MESSAGE? If so then why is there not another parameter for the starting array position? Or does it take the 'live' values, so just needs to know the number of words of the parameter, and isn't taking stored values?

The monster can only be 1 tile away from the party, this gives 4 tiles to check to find it.

Was this to Paul or me? I must admit, I'm starting to lean towards simply infering the monster positon directly from the party position in the party attack filter and storing the x,y,z and ID values in a group of gigglers!

[beowuuf]

Dear lord, my eyes are starting to go. How do you do this each night Zyx?

Right, I combined a party/char fetch in the attack filter to generate results for a case statement to create the position of the monster, then finished off storing the ID and the z, x and y in a group of four gigglers. Whew.

If there is some nicer method than the one I am using (which may not work) that would be great, otherwise I now have the correct information to use in the other DSA.

Lol, so next question... I can tell where the party is blocking Chaos/Order, I can tell if there are walls around him (like the DM engine I think pits, stairs, doors etc should read as empty) - am I missing the obvious way to tell if a cell contains a fluxcage? : )

[Paul Stevens]

Not the party attack filter though

Why is that? I thought that it did.

is there not another parameter for the starting array position

Have you read the documentation? It sends/receives via
the PARAMETERS, not the array. You must use &PARAM@/
&PARAM! to reference them.
http://www.dianneandpaul.net/CSBwin/doc ... guage.html

[Paul Stevens]

I combined a party/char fetch in the attack filter to generate results for a case statement to create the position of the monster

That's terrible. ALL that information is sitting in the
attack parameters. You can send them, AS IS, to your
second DSA with a single word!!!!!! Namely '&MESSAGE'.

Edit: The goal is to do things quickly and easily, not to
dream up complicated and time-comsuming methods.

[Zyx]

>Dear lord, my eyes are starting to go. How do you do this each night Zyx?
Shhh... Paul Stevens works for a powerful maffia of opticians... just buy new glasses and be quiet. Or else they will give you nasty wallsets problems to solve.

With your methode, you don't need to store anything except the monster ID. Since you will call your DSA only when you tried to fluxcage lord chaos/order, do the code to find the X and Y of the monster on this DSA, not on the PartyAttackFilter.

However there is a simpler way I think... parameter 2 and 3 or PartyAttackFilter are X and Y of the targetted monster...


A fluxcage is a cloud. Use a F command I would say, and if it finds a cloud, try a &TYPE on its ID to know if it's a fluxcage. (use the trace to learn which type number is a fluxcage).

[beowuuf]

Party attack filter:
0 Character Index of atacking character
1 Attack Type ( See Attack Types )
2 ID of Monster Under Attack
3 Type of Monster Uner Attack ( See Monster Types )
4 Skill Number
5 Stamina Cost
6 Experience Gained (Many attacks modify this)
7 Disable Time (Many attacks modify this).
8 Needed Mana

Parameters that are computed prior to Attack call to the Filter
9 Damage to monster
10 Decrement Charges flag.


Yes, I've been reading through the documentation first, then throught the CSBuild help for the newer commands. I just meant, for this sending parameter variables between DSAs, do you use the &MESSAGE? And I just got confused about what was being sent

So for example the PARAM for monster movement is 7 words, so to send the &MESSAGE would it be something like:
LA L1 L7 L3 &MESSAGE
And then the 7 parameters of the monster filter would be sent to the DSA at 'A', which would start at line C0 (in this case) after a delay of 3, right? And I could pick this message up and manipulate it using &PARAM@ in the new DSA just like a filter?

[Paul Stevens]

Something has gone wrong.
0 character
1 attacktype
2 attackX
3 attackY
etc

http://www.dianneandpaul.net/CSBwin/doc ... ilter.html

Where did you get your list? It needs fixing.

Your example is correct. But NOT like a filter. A Filter does
not receive a message. A filter is like a subroutine of the C++ code
that I wrote. Same language. Looks the same from your side
of the table. But normally the primary output of a filter is
not a mesage to open doors, etc but rather the manipulation
of the runtime's internal variables (the parameters) in order
to modify the behaviour of the runtime engine.

[beowuuf]

Would the fluxcage always be the last item (depth 0)? This is what stopped me from thinking of using F like that - that and trying to understand everything else. I must admit my brain must have shut down, it currently seems that I'm being told to sent out a message without the right info, and that I can do the calculation in another DSA when all the info for that is in that filter. I think I am missing something obvious or misunderstanding something hugely.

And is the parameter malliable if it is not destined to be used again by the filter itself ? So can I just create a four word parameter then send it off?

Also, embarrassingly I didn't notice both the monster ID and type ID are in the party attack parameter... hmm... that was a wasted &monster@ call...

[Paul Stevens]

Would the fluxcage always be the last item (depth 0)?

No. You must not assume such things. In fact, there could be
more than one fluxcage there! Or a fluxcage and a poison cloud.
Or etc.

being told to sent out a message without the right info

The first six parameters of the PArty attack filter are exactly
what you want to send to your other DSA. Unmodified.

And is the parameter malliable

You should not change the attack filter parameters unless
you want to modify the results/effects of the attack. You can
modify anything that will not affect the attack. Is that
what you mean?

[beowuuf]

Hmm, I think my browser is caching the old page then! I followed your link and it is the same as I have been viewing (through the DSA page) Dammit!

Ok, in THAT case yes the &message would give me the position stuff and the monster ID and make this so much easier without the need for gigglers. And that monster type ID bit even removed a call.

[beowuuf]

For the parameter being malliable, I meant could you truncate it or alter it as you saw fit when passing it on - I think the answer is no then, as I originally thought. You pass on the attack filter parameters unmolested in their original form (character attacktype attackX attackY etc...) and not (charatcer attackX attackY)

[Paul Stevens]

If you want to molest them then &PARAM@ them, molest them,
send them on, then &PARAM! them to put them back in their
virgin state. Common programming practice when the Maker
has not provided the best tools for the job. Like Windows
programming or DSAs.

[beowuuf]

Lol, the list still seems the same when I follow your link! And I've flushed the cache. Can someone provide me with the parameter number for monster ID and type? Cheers

Interesting, I remembered that you could actually fuse Chaos without a Fluxcage if you trapped him, but no, you do need either fluxcages or stone walls around him or else he will teleport away (the party isn't counted as a blocker). But I'm going to count the party as a blocker anyway

I fired up the dungeon before I went to bed, and while obviously nothing was filtered since I have the wrong parameters being checked, then at least nothing crashed either. No solution for the fluxcage thing yet...

[beowuuf]

ARGH! I know what's wrong - at the bottom you have defined the structure of the parameter, and I ignored it as just being another attack break down

struct ATTACKPARAMETERS
{
i32 charIdx;
i32 attackType;
i32 attackX;
i32 attackY;
i32 monsterUnderAttack; //0 if none
i32 monsterType;
i32 skillNumber;
i32 staminaCost;
i32 experienceGained;
i32 disableTime;
i32 neededMana;
i32 unused; //damageToMonster;
i32 decrementCharges;
i32 activateMonster;
i32 userInfo[10];
i32 dataType; // = ADT_*****
ATTDEP attdep;
};

Below that you have then verbally explained the parameters, which is what I was going by, and it had missed out the X/Y bit and the final datatype entry - do'h! If I were paying attention I could have questioned why you would calculate stamina cost and experience gain in the pre-attack. Of course, it knocks my numbering allocation totally too - I was allowing for 21 parameters, but there are 22 with the last datatype stuck on the end

Edit: Wow, funny how the code for a call to the party info to find position, call to the char info to find attack facing, case statement to use these to create the position of the monster, then allocation of all this information into a set of gigglers can be removed for four little coded words. Mmmm, so neat!