No, I don't have any un-pushed code right now, so you are free to make changes without worrying about conflicts. I keep my branches short and merge to main often :D
On Thu, Jan 27, 2022 at 7:40 PM Ralph Versteegen <[email protected]> wrote: > > > 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 >
_______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
