On Fri, 28 Jan 2022 at 09:52, James Paige <[email protected]> wrote:
> > > On Thu., Jan. 27, 2022, 8:40 a.m. Ralph Versteegen, <[email protected]> > wrote: > >> >> >> On Fri, 28 Jan 2022 at 01:07, James Paige <[email protected]> >> wrote: >> >>> >>> >>> On Thu., Jan. 27, 2022, 4:34 a.m. Ralph Versteegen, <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Thu, 20 Jan 2022 at 14:56, James Paige <[email protected]> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Wed, Jan 19, 2022 at 6:49 PM Ralph Versteegen <[email protected]> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Wed, 19 Jan 2022 at 13:49, James Paige <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> So I do have a few other changes related to this one planned. >>>>>>> * An option to make heroes controlled by (random) AI >>>>>>> * A concept of "traitor" which will affect targeting classes when an >>>>>>> attacker is targeting >>>>>>> * A concept of "turncoat" which will affect targetting classes when >>>>>>> an target is being targeted >>>>>>> * Attacks that can turn these effects on and off or set-to-default >>>>>>> >>>>>>> So an enemy with all 3 of Controllable, Traitor, and Turncoat would >>>>>>> function as a hero for that one battle. >>>>>>> >>>>>>> To simulate a classic "Confuse" status, you would have an attack >>>>>>> that turns Controllable off, and traitor on, but don't touch turncoat. >>>>>>> Then >>>>>>> to end that status, use an attack that sets Controllable and Turncoat >>>>>>> back >>>>>>> to default. >>>>>>> >>>>>> >>>>>> I was hoping this meant you were going down this direction :) >>>>>> >>>>>> I'm not sure whether "Traitor" is proposed to swap foes and allies of >>>>>> a target, or just makes everyone count as a foe. Those are two different >>>>>> ways that you might want a Confused status to work, and it seems that >>>>>> these >>>>>> bits would only allow one or the other. >>>>>> >>>>>> What I was thinking was to give each combatant a team (default 1 for >>>>>> heroes, 2 for enemies) and an "acting" team. A target is considered an >>>>>> ally >>>>>> by an attacker if their team is the same as the attacker's acting team, >>>>>> else they're a foe. Also team 0 could mean "independent", with no allies. >>>>>> You probably wouldn't use more than a third team, for "Nature", say when >>>>>> a >>>>>> clan of hyenas opportunistically attack while you're fighting someone >>>>>> else). >>>>>> >>>>>> So Confuse to make someone attack anyone indiscriminately would >>>>>> change their acting team to 0 (so two confused targets still hit each >>>>>> other), and to swap sides you'd change their acting team (although now I >>>>>> realise that means the attack would need to be specific to use by heroes >>>>>> or >>>>>> enemies, unless there was an attack bit like "swap target's acting team" >>>>>> that just set it to the attacker's). >>>>>> >>>>>> Maybe I've overcomplicated it again, while still not adding all that >>>>>> much utility/flexibility (really should work on allowing script hooks for >>>>>> things like this) vs just adding a third Independent bit. >>>>>> >>>>> >>>>> Yeah, I think teams will overcomplicate it for now-- and yes, having >>>>> scripting hooks so people can customize this behavior will be the best way >>>>> to get advanced fancy effects >>>>> >>>> >>>>> I do kinda like the idea of being able to make a confused enemy target >>>>> all, rather than only the opposite side, but I'll have to think if there >>>>> is >>>>> a nice simple way to do that. >>>>> >>>> >>>> Going down the route of bitsets then I don't really see another option >>>> but adding another bitset to make everyone an enemy. >>>> >>>> Now, I'm not pushing for the team IDs idea, but I just wanted to write >>>> something about complexity. Say you add a third bit, or even a fourth ("Foe >>>> to all"). I think that arguably two integer-valued settings are simpler >>>> than 3 bits, because 3 bits is 8 possible combinations, a lot to think >>>> about. And even an 8-way setting could be simpler to reason about than 3 >>>> bits if you don't have to think about any interactions. Complexity of >>>> implementation is usually also secondary. >>>> But in fact after looking at the new version of get_valid_targs I >>>> realised team IDs would actually have been simpler in implementation too. >>>> The bitsets are more complex... in fact I see some mistakes in the code, >>>> which I'll fix: "Dead-ally (hero only)" and "Dead foe (enemy only)" were >>>> meant to be informative only, to warn that those settings didn't make sense >>>> for enemies/heroes, but not to intentionally restrict the targets. >>>> >>> >>> I was actually considering two more bit states-- "Indiscriminate >>> Attacker" to attack both sides, and "Tergiversate Target" to be targeted by >>> both sides >>> >> >> Maybe we need to make more frequent releases so that you can outlet your >> penchant for lexical obscureness elsewise :) >> >> > > Haha! I cannot question the perspicacity of this suggestion! > James, have you already started adding these bits? Because I was cleaning up some other code and realised I needed an is_foe function, which I was going to pull out of get_valid_targs. > > >>> >>>> >>>> >>>>> >>>>> >>>>>> >>>>>>> >>>>>>> Or a classic Berzerk could be implemented with Controllable=Off and >>>>>>> could end with controllable set to default (this would work for heroes, >>>>>>> but >>>>>>> wouldn't do anything meaningful on an enemy) >>>>>>> >>>>>>> This should allow a lot of possibilities, and is all pretty easy to >>>>>>> implement. >>>>>>> >>>>>>> And yes, someone could totally fake 5 or 6 heroes in the party with >>>>>>> this, by using an instead-of-battle script, and adding hero enemies to >>>>>>> the >>>>>>> formation with a script before the battle starts. Definitely not ideal, >>>>>>> but >>>>>>> fine if people want to try it. >>>>>>> >>>>>>> Actually increasing the size of the active party > 4 and increasing >>>>>>> the number of enemies in a formation > 8 is something I definite;ly >>>>>>> want to >>>>>>> do, but it will require lots and lots of cleanup, which is outside of >>>>>>> the >>>>>>> scope of what I am trying to do right now. In particular, there are >>>>>>> tons of >>>>>>> places where the ID range within the bslot() array defines what a >>>>>>> BattleSprite Instance does, so the first step of that cleanup will >>>>>>> probably >>>>>>> be to convert all access to bslot() to a set of accessor functions for >>>>>>> heroes, enemies, attack sprites, and weapon sprites. Then those >>>>>>> different >>>>>>> ranges can be split apart into different arrays, which can be >>>>>>> dynamically >>>>>>> sized when you load a battle formation with 15 enemies in it, or >>>>>>> something >>>>>>> like that. But that is for later. I want to keep the scope of what I am >>>>>>> working on broken down into bite-sized baby-steps to mix a metaphor :D >>>>>>> >>>>>> >>>>>> I don't think we would want to split bslot() into separate arrays for >>>>>> heroes and enemies: being able to index across all of them with a bslot() >>>>>> index is very useful and widely used (eg. targeting) so it would be a lot >>>>>> of work to remove that. Why not just add is_hero and is_enemy attributes. >>>>>> There's a lot of lines of code to change, but each would then be an easy >>>>>> change. Could also start using polymorphism. >>>>>> >>>>> >>>>> Yes, you are right. is_hero and is_enemy attributes are much better >>>>> than what I was thinking of with the accessor functions for bslot. Glad >>>>> you >>>>> said it :) >>>>> >>>>> >>>>> >>>>>> On the other hand, I do want to remove attacks and weapons from >>>>>> bslot() and was considering doing it soonish. Almost all of the >>>>>> BattleSprite data is irrelevant for them, and nearly all of the >>>>>> advantages >>>>>> of having them in bslot are (or will be) gone now that battles are >>>>>> converted to slices. >>>>>> >>>>> >>>>> Ah, right! Those only get used in animations, so the slice is all that >>>>> really matters :) >>>>> >>>>> >>>>>> >>>>>> >>>>>>> Fortunately I think the current features I am adding will not make >>>>>>> any of that later work harder, and might even lead to a little helpful >>>>>>> cleanup. >>>>>>> >>>>>>> --- >>>>>>> James >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Jan 18, 2022 at 8:22 AM Ralph Versteegen <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Wow! That's not a feature I was expecting to see for a long time. A >>>>>>>> nice surprise! >>>>>>>> >>>>>>>> I suppose this is particularly useful for giving the player extra >>>>>>>> actions they can perform in battle. People are going to inevitable >>>>>>>> think to >>>>>>>> use it to get around the 4 hero limit, but it seems really problematic >>>>>>>> for >>>>>>>> that. Or is time to add team numbers to battles, so you can define >>>>>>>> which >>>>>>>> combatants are "foe" or "ally"? >>>>>>>> >>>>>>>> On Mon, 17 Jan 2022 at 14:01, <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> james >>>>>>>>> 2022-01-16 17:01:32 -0800 (Sun, 16 Jan 2022) >>>>>>>>> 39 >>>>>>>>> New enemy bitset "Controlled by Player" >>>>>>>>> --- >>>>>>>>> U wip/bmodsubs.bas >>>>>>>>> U wip/enemyedit.bas >>>>>>>>> U wip/loading.rbas >>>>>>>>> U wip/udts.bi >>>>>>>>> U wip/whatsnew.txt >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Ohrrpgce mailing list >>>>>>>>> [email protected] >>>>>>>>> >>>>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Ohrrpgce mailing list >>>>>>>> [email protected] >>>>>>>> >>>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ohrrpgce mailing list >>>>>>> [email protected] >>>>>>> >>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >>>>>>> >>>>>> _______________________________________________ >>>>>> Ohrrpgce mailing list >>>>>> [email protected] >>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >>>>>> >>>>> _______________________________________________ >>>>> Ohrrpgce mailing list >>>>> [email protected] >>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >>>>> >>>> _______________________________________________ >>>> Ohrrpgce mailing list >>>> [email protected] >>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >>>> >>> _______________________________________________ >>> Ohrrpgce mailing list >>> [email protected] >>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >>> >> _______________________________________________ >> Ohrrpgce mailing list >> [email protected] >> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >> > _______________________________________________ > Ohrrpgce mailing list > [email protected] > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >
_______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
