Hi Craig, Hm one possibility I only came up with now: what to do if there are units affected by splash damage that are neither set as allies or enemies? Can you add corresponding flags for neutral units that got affected to govern if they got damaged? -----Original Message----- From: ian-reeds-games-bounce@xxxxxxxxxxxxx [mailto:ian-reeds-games-bounce@xxxxxxxxxxxxx] On Behalf Of Craig Brett (Redacted sender "craigbrett17@xxxxxxx" for DMARC) Sent: Friday, March 6, 2015 3:26 AM To: ian-reeds-games@xxxxxxxxxxxxx Subject: [ian-reeds-games] Re: Tactical Battle 2.0 dev 2 is ready Hi Victorious, Okay, good on him for doing it. I still feel like fixing it in the engine at some point though. But if him doing it by script for now gets you guys going then maybe that's better. It wouldn't be hard to implement both, er, I don't think, It does feel a little weird to have it before damage applied and after damage applied, and do you want it for each point individually or all together? And you can start holding your breath about the friendly fire changes. I've implemented them, I just need to fix a bug around splash restores getting caught up in it. Shouldn't take too long, I hope. On 05/03/2015 11:30, Victorious wrote: > Hi Craig, > > Yup, but Carlos has already made the point_max_mod a feature in his > script set for items. He'll probably release it some time soon. > > About the events, how hard would it be to implement both? We'd > probably use the one that triggered after damage was applied. Our > damage reflection would be a % of damage that the defender received, to be > dealt back to the attacker. > Its possible that we may do what you put though, to completely prevent > damage to the defender and have it all bounce back to the attacker, > which is why having both would be nice. For the event that triggered > before reflection, it could work like overwrite damage causers so that > we can either stop it and do other things to the damage before > applying it ourselves or returning false if we weren't doing anything. > Besides reflection, implementing percentages for damage and protection > may be possible with this too, which would be really cool > > -----Original Message----- > From: ian-reeds-games-bounce@xxxxxxxxxxxxx > [mailto:ian-reeds-games-bounce@xxxxxxxxxxxxx] On Behalf Of Craig Brett > (Redacted sender "craigbrett17@xxxxxxx" for DMARC) > Sent: Wednesday, March 4, 2015 3:30 AM > To: ian-reeds-games@xxxxxxxxxxxxx > Subject: [ian-reeds-games] Re: Tactical Battle 2.0 dev 2 is ready > > Hi Victorious, > > Really? I wasn't aware of that. That seems like something we should > either fix or stop people specifying in their item files. I'm sure I > remember looking into something like this before. Was this the one > where you equip an item that increases your health_max or something along > those lines? > > This event that you want, where it totals the amount of damage per > point, would you want it triggering before or after the damage is > applied? If you're doing damage reflection, as I understand it, it > would be set up so that the target never actually receives damage in > the first place. So it's difficult to know when to trigger an event. > > As for disabling friendly fire, sounds like a good feature. I'll see > if I can fit it in the next release, but as it's fairly complex, don't > hold your breath. It may happen, or it may be pushed back a release. > > Craig > > On 02/03/2015 16:04, Victorious wrote: >> Hi Craig, >> >> Thanks a lot for this latest update; the scripting possibilities are >> really exciting. Carlos's already hard at work implementing >> item_point_max_mod (as the one in tb doesn't seem to work last I >> checked), item_equip_effect, item_equip_remove_effect and so on. >> >> When working more on damage reflection, it would be nice if there was >> an event that triggered after each point of a unit has its damage >> totaled up, The event would have the following arguments on it: the >> source unit that dealt the damage, the skill that dealt the damage, >> the target unit that received the damage, the amount of damage, and >> the point that was damaged. This script flag would allow damage >> reflection to work even with skills with multiple damage types as its >> fired after totalling the damage for each type. >> >> Another thing about the damage reflection script is that it wouldn't >> work for us even if the above event was present because of how we >> chose to prevent friendly fire. We had the player's team do damage >> types like fire, ice etc while the enemy did evilfire, evilice, etc. >> The player's team would be protected from fire, ice, electric damage >> and the same thing for the evilfire, evilice etc damage types for >> enemies. Unfortunately, if you're trying to implement damage >> reflection that reflects the corresponding damage type right back at >> you, this approach will obviously not work. It also has other >> drawbacks as well aside from this specific scenario. >> >> Can you consider implementing team awareness into the engine? Some >> suggestions on the appropriate flags: >> enable_global_friendly_fire would be settable in the actual map file >> on a per-map basis, which allows your own units to be damaged by >> friendly fire, basically the current behaviour and should remain >> default. (Maybe no need for this flag)? >> disable_global_friendly_fire would be settable on the map file, >> taking into account team affiliation when calculating splash damage. >> Then for skills that the map creater explicitly wanted to enable >> friendly fire for, there could be an enable_friendly_fire flag for the >> skill. >> >> For skills that have splash_effects, the effect is applied >> indiscriminately regardless of whether the unit is friendly with the >> user or not. You could add splash_effects_friendly to only have the >> splash_effects affect friendlies and conversely for splash_effects_enemies. >> >> The last scenario I can think of is some way of setting affiliations >> for tile effects and terrain. It'd default to none (which is current >> behaviour), user (valid for tile effects, this would be the team that >> the caster was in) and an explicit settable value for terrain. Once >> it has an affiliation, you would be able to control what it did based >> on whether its friendly with the occupant of the tile/terrain or not. >> This last one is probably the hardest to implement i think, and the >> other suggestions above would be more helpful for us in the immediate >> future. >> >> - Victorious and Carlos >> >> -----Original Message----- >> From:ian-reeds-games-bounce@xxxxxxxxxxxxx >> [mailto:ian-reeds-games-bounce@xxxxxxxxxxxxx] On Behalf Of Carlos >> Macintosh >> Sent: Monday, March 2, 2015 8:44 AM >> To:ian-reeds-games@xxxxxxxxxxxxx >> Subject: [ian-reeds-games] Re: Tactical Battle 2.0 dev 2 is ready >> >> wow, can't wait to script TB with these new changes! I'm downloading >> the game right now. I'll probably be releasing some script updates in >> the near future as well. >> >> >> On 3/1/2015 6:38 PM, Craig Brett (Redacted sendercraigbrett17@xxxxxxx >> for >> DMARC) wrote: >>> Hi all, >>> >>> As you may have seen, things have picked up a little with TB >>> development and the result is this latest release. >>> >>> I've been told that the auto-updater probably won't work right this >>> time, so you'll have to download it manually from this link: >>> http://blindaudiogames.com/downloads/Tactical%20Battle%20Dev.zip >>> >>> Extract it to a different folder than where Tactical Battle >>> currently lives (I accidentally tried it and got into a bit of a >>> mess). Then you can copy your map packs and settings folders over to the >>> new place. >>> And it'll be as good as new. >>> >>> Here are the changes in dev 2: >>> >>> 1. Various performance enhancements to help the game run more smoothly. >>> 2. Fixed a bug where pressing Alt+O to switch the output type to >>> screen reader would sometimes need you to alt+tab away and back to >>> the window to get NVDA to read it. >>> 3. Fixed a bug where if a unit died due to an effect applied by a >>> script, we don't accidentally kill them again. >>> 4. Added a shared.RemoveEffect function for scripters to remove >>> effects in a way that will still trigger effect after removed logic >>> and also read out effect removed messages if the effect requires it. >>> 5. Added a unit.DoDamageTo function for scripters that allows a unit >>> to do damage to another unit's point with a given damage type, >>> taking into account modifiers on both the attacker and the defender. >>> 6. Added a unit.DoRestoreTo function for scripters that allows a >>> unit to restore another unit's points, taking into account modifiers >>> on both the attacker and the defender. >>> 7. Added an AllFlags hash to units, skills, items and effects that >>> allows scripters to get the values of the flags as set in the files >>> with map overrides taken into account. >>> 8. Implemented after_item_equipped and after_item_unequipped >>> scripting events. >>> 9. Fixed a potential problem with date and times when downloading >>> map campaigns. >>> 10. Added a new global javascript function, randomSound(string), to >>> let scripters use the same random sound logic that is used in game. >>> >>> As a result of 5 and 6, I also updated my scripts and they're >>> included in this release. My scripts received the following updates: >>> >>> 1. Critical_hit_inflict and Critical_hit_restore now work correctly. >>> They take into account mods on attacker and defender and also >>> correctly kill units when relevant points reach 0. >>> 2. Fixed a bug where skills that had move_other_unit flags wouldn't >>> actually kill units if they removed all their health (or similar) >>> points, and they would then become immortal, since their health >>> point was already at 0. >>> >>> Thanks to Ian for the first two changes and advice on some of the >>> others, as well as for deploying it. And well... creating TB as >>> well, I guess :) >>> >>> I hope you all like the changes in this update. Please let me know >>> if you have any questions. >>> >>> Enjoy! >>> >>> Craig >>> >>> >>>
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
