FFX 3.2 carrier attacks with cones ?

[stumpy]

This is something I should know, but it doesn't look like I do, so...

Can carrier attacks (swapping stun for some other state) work with cones for built-in characters? More accurately, I know that they do work, but the carrier also seems to affect other attacks when they cause stun. Is that what is supposed to happen?

For instance, all the recent Superman discussion made me think that I wanted to change from having a cold damage attack and a freeze attack, to just a cold damage attack with a chance of freezing the target. My Superman is a built-in character. So,

• I set up a cold damage cone with stun in FFEdit.
• I went to the FFX Control Center and selected that character and that attack and set the swap from stun to frozen in the Character State Customizations.
• I start the game and run the Power ID generator in the Rumble Room.

And it works. At least it works for that cold cone attack. When the targets are stunned, the stun is swapped for frozen.  Beautiful! :)

But, I started noticing that his melee attacks that occasionally stun are also causing their targets to freeze. I thought for built-ins, that wasn't a problem because each power has an individual power ID. (And, I checked and they do; there are separate entries in ffxpowerids.py for each of his melee, beam, and cone attacks.)

So, am I doing something wrong or just misunderstanding the limits of the carrier attacks for built-ins?

[yell0w_lantern]

If you don't know, I'm not sure anyone will...

[stumpy]

Ha, thanks. I have a pretty good handle on the basic concepts but I haven't spent much time digging through the carriers and swaps code. People like Épiméthée are more familiar with the innards of that part of FFX than I am. If it weren't a lazy Sunday and I was trying to get this to work for my little niece, I would probably start hunting myself (which I may have to do later on), just to see if the stun carriers are registered and handled in a way different than the other state change swaps.

I was just hoping someone might know offhand.

[apfarmakis]

Cones swap just like beams if I recall.

[stumpy]

That was my understanding as well. As far as I can tell, the game generally treats cones just like wide, penetrating beams, so it makes sense that they would work the same for purposes of swaps.

But, I am still unsure why my cone stun-to-frozen carrier seems to be causing all of that character's stuns (e.g. his melees) to swap to frozen.

[TaskMasterX]

I thought it should work as well. Does it work correctly if the power is a beam instead of a cone? Do other swaps work correctly with cones? Maybe you found a bug with the Stun Swap for Built-Ins, or a bug with swaps with cones.

EDIT: Now that I actually took some time to think about it, State Swaps work differently for "area-wide" effects, like when trying to simulate a exposivie projectile or area attack. These swaps usually trigger a hex area power and then swap the hex for the actual chosen swap. Since Cones act the same way, and can affect more than one target, when you target a foe, only that foe would come under the frozen swap via a successful stun and any other targets would be stunned and not get frozen. Because of the way the code is working, it only places the swap on the target selected, and not the other targets that get hit within the cones effect. I'm not sure if this is the real issue your driving for an answer too, but from what I've learned, I don't think cone swaps would work properly in the first place.

[stumpy]

Actually, cones really do seem to work similarly to penetrating beams. (I would bet money that IG started with it's beam code to develop cones.) So, the cone carrier attack affects all the characters stunned by the cone. I've tested that. And, since the same thing works with penetrating beams that hit more than one character, it sort of follows. Area attacks (and probably explosive projectiles, which are sort of area attacks centered on the projectile object to the game) don't work like beams, straight projectiles, and melees because the game doesn't allow us to create event 21 sinks for them that work right. Same deal with direct attacks (which is why we usually fudge them using beams with the right FX). At least that is my understanding.

Anyway, I may have been telling this story the wrong way. I want to make it clear that the carrier attacks with the cones are working fine; the swap for stun is working and working for all affect targets in the cone. The problem is that the carrier swap is "bleeding" over into other powers (Kal's melee attacks, in this case), which I would not expect, at least not for a built-in. I think my earlier post made this sound like a cone problem, which I would guess it isn't, really. I just described it that way because I started out by creating a cone carrier attack.

I am wondering if there is something odd about the way my character's melees are being registered (which should be "not at all", since they have no FFX modifications). I have been playing this in the Rumble Room, but I will have to test it in a campaign mission to really do any analysis of the swap registration sinks and see what's going on. It could easily be that there is something wrong on my setup or that I've bumped into an odd bug that doesn't hit often.

[Epimethee]

Interesting bug. And no, I don't have anything remotely close to an answer, just the obvious questions.

If you have more than one stunning melee power, does it always occur with the same one?

Otherwise, if you change the cone to a beam, does it still occur? Or if you create identical powers with different names (and power IDs)?

[stumpy]

Interesting bug. And no, I don't have anything remotely close to an answer, just the obvious questions.

Too bad. But, at least it looks like we are thinking along the same lines:

If you have more than one stunning melee power, does it always occur with the same one?

He has two melee powers, both with stun and both have their stun swapped out.

Otherwise, if you change the cone to a beam, does it still occur??

Yes.

Or if you create identical powers with different names (and power IDs)?

Yes.

I am going to try and find some time to do a little testing tomorrow evening.

[Failed_Hero]

Umm just an observation, but stun is a generic attack and if it bleeding into Kal stun melee's it is most likely because the stun/freeze swap affects all stun attacks for that character.  Is it causing other characters to  freeze characters with a stun attack?

[stumpy]

Umm just an observation, but stun is a generic attack and if it bleeding into Kal stun melee's it is most likely because the stun/freeze swap affects all stun attacks for that character.

That's what I am saying is happening. It should only happen for the one attack, but it is happening for his other attacks that stun.

Is it causing other characters to  freeze characters with a stun attack?

No.

[Epimethee]

Thanks for the answers, Stumpy. So it's not related to cones. To continue in my obvious/silly questions pattern (sorry, can't test it myself for the moment):

Does it occur only if the swap is set to freeze? if set to another primary state? if set to a secondary, generic or FFX state?

Anything weird in your FFX_CARRIERS_CUSTOM? How old is the captain? What's the colour of Napoleon's white horse?

[stumpy]

I don't think it's limited to just freeze or even just primary attacks (I just got home, so I've only had a few minutes to test).

So, umm, AAAARRGH! It looks like it's happening with squad heroes that are spawned with the game's internal (and infernal) CUSTUM_TEMPLATE_# templates. I should have checked this earlier, but that appears to be it. Unfortunately, when that happens, they get their own set of powers and power ID numbers that we can't determine.

I noticed this by using my character in the first campaign mission, by spawning him at the console from his template. He worked perfectly: stun from his cone swapped to frozen and stun from his punches stayed as stun. Then, I went back to the RR and took him in as a squad hero and he was having the old trouble (punch stun swapping to frozen), so I did the obvious thing and checked his template. Oops, it was a CUSTOM_TEMPLATE_#. When I spawned him from the console (the same built-in I had chosen during squad selection), he worked fine again.

Maybe, when that happens (I haven't checked), they are treated by FFX as customs, where their state swaps are the same, regardless of which power induces the state. In other words, just as a custom character can't have a hex beam power that swaps to crystal cage and a hex punch that doesn't. The same thing is happening with stun, which I assume is what we'd expect.

Interestingly, this doesn't affect built-ins run by scripted AI because that uses Trigger_Power() with the actual FFEdit powers (not the internal powers the game uses for its CUSTOM_TEMPLATE_# characters) and we have the power IDs for those powers so they can be registered for event 21 sinks properly.

(Come to think of it, we could probably do the same thing for customs run by scripted AI, by generating the power IDs for any of the melee or ranged 'zzz#' power slots they are using...)

I am actually sort of surprised this hasn't come up before. I haven't tested thoroughly to make sure, but I suspect it would happen whenever anyone uses any built-in (or presumably a custom) in their RR squad who has more than one melee or ranged power that does stun and where one of them has a carrier. I can see how it would have slipped by for other, non-stun, swaps because it's more rare that a character has two melee or ranged attacks that cause a state change where one of them is swapped and the other isn't. (E.g. El Diablo has a hex beam swapped to flame cage, but none of his other powers are hex.)

I think we might deal with this in future FFX versions by looking at the real templates of any built-ins spawned at RR mission start with the CUSTOM_TEMPLATE_# templates (before even bothering to initialize their scripted attributes) then destroying them and re-spawning them from their actual (FFEdit) templates.

[stumpy]

I think we might deal with this in future FFX versions by looking at the real templates of any built-ins spawned at RR mission start with the CUSTOM_TEMPLATE_# templates (before even bothering to initialize their scripted attributes) then destroying them and re-spawning them from their actual (FFEdit) templates.

Sorry to bite my own post, but I just tried the above approach and I had forgotten that FFEdit heroes spawned outside a campaign have their power levels set to zero. Not totally unplayable, but that much nerfing is a pretty big problem for the Rumble Room...

Unless we have some way to get the right power IDs for the 'custom_template_#' heroes, I don't see a simple fix.

Shoot. This bugs. Not only is it a little coding problem that may be tough to solve, but I thought I had found the perfect way to do Kal's supercold breath; to wit, sometimes it just causes cold damage and sometimes it causes cold damage and freezes an opponent. I've only designed like two characters that make use of swaps of any sort and my second attempt, where it really helps a power fit my conception of it, uncovers a bug in the system. :banghead:

[Epimethee]

You're at IG:

1. Create the campaign code and the built-in character format, using a not-quite-logical system.
2. Create the custom character system and use a very different character format from the one you already have.
3. Modify the campaign code a lot to create the MP code, and change the whole character generation system to (I guess) prevent cheating.
4. Change the MP code to create the skirmish version.

These guys were working hard under a budget and a deadline, so it's quite understandable... but still &?%$#@! frustrating (for example, the number of fun attributes we can't do because they won't work in all cases...) – even five and half years after, we're finding new issues with it. Though me too, I'm surprised it took this long to find this one.

Maybe we should just kill hero files and skirmish mode and re-implement them using a custom campaign. :>

I think we might deal with this in future FFX versions by looking at the real templates of any built-ins spawned at RR mission start with the CUSTOM_TEMPLATE_# templates (before even bothering to initialize their scripted attributes) then destroying them and re-spawning them from their actual (FFEdit) templates.

Sorry to bite my own post, but I just tried the above approach and I had forgotten that FFEdit heroes spawned outside a campaign have their power levels set to zero.

In addition, wouldn't heroes in the villains squad and vice-versa cause problems? EDIT: Probably not. After all, shapechangers are already set this way.

Not only is it a little coding problem that may be tough to solve, but I thought I had found the perfect way to do Kal's supercold breath; to wit, sometimes it just causes cold damage and sometimes it causes cold damage and freezes an opponent.

There might be a crude workaround. You could set the attack to do freeze only (or cold damage only) and use regMLOGDamage() plus getColdResistanceValue() to generate the other attack as appropriate. Admittedly, regMLOGDamage() isn't hooked to the FFX carriers system, so you'd have to use custom code (not that it'd be an issue for you!). More importantly, I need to finish my mlogreader patch so regMLOGDamage() actually works (I haven't forgotten you, Jason!)

[stumpy]

Maybe we should just kill hero files and skirmish mode and re-implement them using a custom campaign. :>

You may be joking, but I have been tempted on several occasions to see if we could do the Rumble Room as a campaign mod. That would get us around many of the problems we are seeing which derive mostly, as you note, from the fact that IG added so many hacks to campaign mode to get the other features. The big problem is that we have so few UI scripting hooks that we would essentially need to have a big app that gets run outside the game to set things up (choose your baddies, RR mode, etc.) and then start the game. That would get very cumbersome. But, the temptation to get around silly things like the 'custom_template_#' nonsense and to have things like save games in a RR session would be very nice. Combined with some of the freeroam concepts (e.g., how do you choose a map? Just click on a portal and the RR mission restarts on the right map...) and it would be pretty cool, except for all the quitting-and-restarting the game and not having the nice in-game character editor and RR combo to use as an easy hero design and prototyping tool.

BTW, I kinda like HERO files and the RR is great. I like the idea that a hero might not have a power up to level 3 before buying another power at level one, etc. But, it's very frustrating dealing with campaign built-in heroes given a 'custom_template_#' template that show up with powers at level 3 except for the last one at level 1, then the _extra built-ins that show up with all powers at level 1, then heroes spawned from their actual templates showing up with powers at level 0, etc. It's almost like some of that mess had to be done deliberately and I can't figure why. I mean, I know IG never anticipated DrMike2000 and the rest of us doing the fancy things we have with python, which was basically there just for mission scripting. But, you'd think that a call to Object_Spawn() in the RR would produce the same character as in the campaign. They should have thought of that, right? :wacko:

I think we might deal with this in future FFX versions by looking at the real templates of any built-ins spawned at RR mission start with the CUSTOM_TEMPLATE_# templates (before even bothering to initialize their scripted attributes) then destroying them and re-spawning them from their actual (FFEdit) templates.

Sorry to bite my own post, but I just tried the above approach and I had forgotten that FFEdit heroes spawned outside a campaign have their power levels set to zero.

In addition, wouldn't heroes in the villains squad and vice-versa cause problems? EDIT: Probably not. After all, shapechangers are already set this way.

Right, and, for this particular problem, I don't think there is any need to respawn the RR villains (those chosen on the enemies list) since M25's AI uses Trigger_Power() for them with the FFEdit powers, we know the power IDs for those guys and the carriers work fine, as best I can tell. The only enemies-related issue (aside from the level nerfing) I see with respawning the squad heroes that we'd have to use the AI_MakeIntoHero() stuff to make sure the powers that work based on the game's internal teams (like hypnosis, rally, etc.) work right.

BTW, I tried turning on the controller MLOG module, since it seems to register a sinkTrigger with a large (vaguely power ID-ish) number when a character is about to use a power. But, whatever it's doing, that number doesn't turn out to be a power ID, as best I can tell.

I even tried adding bugs (bad values for range, etc.) to the powers in FFEdit, hoping that when one of the 'custom_template_#' characters used its copied version of the power, the internal name for the power would show up in the log and we could snag it. Then we could work the power ID-grabbing magic and (with a quick call to loadPowers() to reset the powers to be bug-free) we'd be on our way. But, the errors that show up in the log file are given their actual strings.txt names, if you can believe. Criminy, foiled at every turn!  <_<

[Epimethee]

You may be joking, but I have been tempted on several occasions to see if we could do the Rumble Room as a campaign mod.

Actually, only half-joking. Let's say I've been tempted too; that would have been a pipe dream for FFX 4. :P

Life is too short... Bullet? Microwave? Déjà Vu? Time Master? Lend me your powersssssss! (Of course, the most useful powers would be Déjà Vu's Clone Target: I'd use it on the whole FR community, then we'd be a large enough market to get a FF3 and get it the way we want.)

The big problem is that we have so few UI scripting hooks that we would essentially need to have a big app that gets run outside the game to set things up (choose your baddies, RR mode, etc.) and then start the game.

Something like Alex's EZ Danger Room, say?

That would get very cumbersome. But, the temptation to get around silly things like the 'custom_template_#' nonsense and to have things like save games in a RR session would be very nice. Combined with some of the freeroam concepts (e.g., how do you choose a map? Just click on a portal and the RR mission restarts on the right map...) and it would be pretty cool...

Some day, I'll finally start working on that Patriot City mod... someday... when I'm old and senile and nobody remembers what a PC game is, let alone FF.

except for all the quitting-and-restarting the game and not having the nice in-game character editor and RR combo to use as an easy hero design and prototyping tool.

Hmmm. [Fantasy mode ON]Maybe with virtualisation we could have two instances of FF running?[Fantasy mode OFF][command refused: Fantasy mode still ON]

It's almost like some of that mess had to be done deliberately and I can't figure why.

Ah-ha! Conspiracy Theory! ;) Personally, I just think different persons did different parts in a hurry... hey, does it really look like something coherent enough for a conspiracy? :P The entries in the FF scripting manual which were never implemented tends to support this hypothesis.

BTW, I tried turning on the controller MLOG module, since it seems to register a sinkTrigger with a large (vaguely power ID-ish) number when a character is about to use a power. But, whatever it's doing, that number doesn't turn out to be a power ID, as best I can tell.

Nice idea; I had a look at this tantalizing module, just for the sake of masochism. My first-glance guess is that the numbers correspond to a controller event type (move, idle, ranged attack, etc.) for each character; if I'm right, they don't give any useful info not available in the text output. E.g.:
00:20:02.34: FF: controller:(form_1) Starting TRG_MOVE controller
00:20:02.34: FF: controller:(form_1) sinkTrigger 353199364
00:52:29.29: FF: controller:(g1) Starting TRG_MOVE controller
00:52:29.30: FF: controller:(g1) sinkTrigger 384170028
00:20:20.76: FF: controller:(hero_0) Starting TRG_MOVE controller
00:20:20.76: FF: controller:(hero_0) sinkTrigger 354989860
00:24:16.41: FF: controller:(_skraptor_boss01) Starting TRG_MOVE controller
00:24:16.41: FF: controller:(_skraptor_boss01) sinkTrigger 354769612
hero_0 id 17563915
form_1 id is 18153748
g1 id is 18350356

The number could be a mask (?) of the event ID and object ID. As an aside, the game AI is cancelling commands a lot. Still, the module might be useful, even if it's relatively verbose – maybe, to reduce the issue, it could replace the animator module sink altogether?

But, the errors that show up in the log file are given their actual strings.txt names, if you can believe.

I cannot.  :blink:

[stumpy]

But, the errors that show up in the log file are given their actual strings.txt names, if you can believe.

I cannot.  :blink:

Yup. It not easy to get all powers to generate an error that has the power name in it (in any form), but if you create, say, a melee power with lower range set to 0, you will get an error with the power name. In fact, Minute Man's "minute Patriot Swing" had that setting in my DATs (for whatever reason) and when I make him use it in the campaign, the error is "00:15:53.23: FF: ERROR: Melee Power minute Patriot Swing has range 0", but in the RR it is "00:19:43.81: FF: ERROR: Melee Power strike for freedom has range 0". I supposed that is a useful thing in that people trying to read the logs don't have to figure out whatever (likely gobbledygook) internal name the game invented for that power. But it doesn't help us out.  :(

[Epimethee]

In fact, Minute Man's "minute Patriot Swing" had that setting in my DATs (for whatever reason) and when I make him use it in the campaign, the error is "00:15:53.23: FF: ERROR: Melee Power minute Patriot Swing has range 0", but in the RR it is "00:19:43.81: FF: ERROR: Melee Power strike for freedom has range 0".

The use of name itself might not really be an issue; after all, we can find the power by name, can't we ( :wub: datfiles.py)?

I'm probably missing some fundamental detail here but the fatal flaw, if these errors work like the "controller" module, is that the error message will appear every time a character attempts an attack, won't they? And that was the whole point of using power swaps for carriers in the first place: they're used to confirm that the misnamed EVENT_POWER_HIT corresponded to a successful hit on the target.

That's one advantage of regMLOGDamage(): it completely bypasses the EVENT_POWER_HIT/state change system. Of course, the existing regPowerHit() method obviously has quite a few advantages of its own. :)

[stumpy]

The use of name itself might not really be an issue; after all, we can find the power by name, can't we ( :wub: datfiles.py)?

We could use datfiles get the name used by FFEdit (and even get that name working backwards from the string name, if we needed to). But, the FFEdit name isn't where I was headed with that thought. I was hoping to find whatever internal name the game was assigning to the powers it gives to its 'custom_template_#' characters, which I am assuming is different from the FFEdit power it was copied from. (That's an assumption I'm making which is not necessarily true, of course. But, it would explain why our event 21 sinks for the FFEdit powers don't seem to trap the powers when a 'custom_template_#' character uses them.) Once we had the internal power name, we could go through the regPowerUse() trick to find its power ID and then use that for an event 21 sink that would allow us to do our swaps.

I'm probably missing some fundamental detail here but the fatal flaw, if these errors work like the "controller" module, is that the error message will appear every time a character attempts an attack, won't they? And that was the whole point of using power swaps for carriers in the first place: they're used to confirm that the misnamed EVENT_POWER_HIT corresponded to a successful hit on the target.

That would definitely be a big problem. But, I wasn't planning to use the ff.log errors except right at mission start (and maybe if a new 'custom_template_#' characer showed up later) to get the internal power names and IDs, as per above, and then go back to using the method we use now after we have the IDs. In other words, start the mission, spend a few seconds grabbing the new power IDs for any 'custom_template_#' characters with swapped melee or ranged powers, set up the event 21 sinks for the swaps, then go back to ignoring those errors during normal play.

That's one advantage of regMLOGDamage(): it completely bypasses the EVENT_POWER_HIT/state change system. Of course, the existing regPowerHit() method obviously has quite a few advantages of its own. :)

I like regMLOGDamage() (and have been toying with it for other stuff) :thumbup:. I think the present system probably has lower computational overhead (just because the game's internal event sinks are probably more efficient than our pseudo-event sinks) and may be faster, but issues like this make regMLOGDamage() very attractive. And, we could get meaningful intensity data to apply to the swapped effect, too, which I think would be very slick. It would be a big win if we could get back the power that caused the damage (I think now we just get the character that caused the damage, right?). I think, without that, we still need the event 21 sinks to let us know to check that the damage is from a swap.

[Epimethee]

I'm probably missing some fundamental detail here...

(...) But, I wasn't planning to use the ff.log errors except right at mission start...

Epi-, "after", -metis, "wisdom/craftyness" – Epimetheus: he who is wise after the event (by opposition with Prometheus, he who is wise before the event. Or, to keep the pedantic vein and stay in greek litterature, as Homer would say: "D'oh."

I like regMLOGDamage() (and have been toying with it for other stuff)

Me be curious!

I think the present system probably has lower computational overhead (just because the game's internal event sinks are probably more efficient than our pseudo-event sinks) and may be faster

I certainly expect a major performance hit; that's why I wouldn't see it completely replace the existing method, even ignoring the other issues. As an aside, a utility to convert/cache a physical file to a virtual RAM-based one would be nice with ff.log; too bad this doesn't seem to exist.

It would be a big win if we could get back the power that caused the damage

Yeah, this would be very nice. I doubt it can be be done except by unreliable heuristics or maybe by forcing everyone to convert their character's power to allow us to use some trick. Please prove me wrong yet again! ^_^

(I think now we just get the character that caused the damage, right?).

Just the character, sadly, right. But getting areas and directs kinds of compensates.

I think, without that, we still need the event 21 sinks to let us know to check that the damage is from a swap.

Well, if you want the same source effect in different powers to have different carrier effects, yes. But you don't need swaps at all (which is why I suggested you use only the main attack for Supe's fresh mint breath attack). Of course, it messes with play balance, since you're getting effects for free (to compensate, this could be available only when buying a specific attribute).

[Lunarman]

Sry to butt in but this actually made me laugh out loud, not because it's funny. But because I can't understand a word you're saying. 

This is the quote of the year

unreliable heuristics

Anyway, however far you've got good luck. Because as much as I can work out, this may change the future of FFX.

Good luck!

*the madman has now been removed, and you may return to your scheduled thread"