I used to keep branches short because I was afraid of merge conflicts. But now it is a habit drilled into me by work.
If a branch isn't ready to merge in 48 hours, I probably have a scope creep problem If a branch isn't ready to merge in a week or two I shouldn't have even bothered creating it, because it isn't likely to land ever Not hard and fast rules, just my rules of thumb :D On Fri., Jan. 28, 2022, 9:39 a.m. Ralph Versteegen, <[email protected]> wrote: > I really wish I could be like that! I really want reduce the number of > branches of unfinished features I have. I have a number in mind after > Ichorescent. > I've finished with battle system changes for the moment, if you want to do > anything. > > > On Fri, 28 Jan 2022 at 16:53, James Paige <[email protected]> wrote: > >> 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 >> > _______________________________________________ > 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
