On Fri, Jan 28, 2022 at 9:47 PM Ralph Versteegen <[email protected]> wrote:
> > > On Sat, 29 Jan 2022 at 15:38, Ralph Versteegen <[email protected]> wrote: > >> >> >> On Sat, 29 Jan 2022 at 07:29, James Paige <[email protected]> >> wrote: >> >>> 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 >>> >> >> Hahah, I have so many branches that are many years old but I haven't >> given up on, I do actually finish one from time to time. The one I'm >> working on now was started over 2 years ago. Some of the major ones I try >> to rebase onto wip every year or two. I probably have close to 100 which I >> intend to eventually finish and merge. Some are actually finished, just not >> tested. Others... for example this cleanup of Game and Custom's startup >> code I did 9 years ago can't realistically be merged, but looks nice, I >> might want to take some ideas and code from it. And this 6+ year old branch >> of innumerable misc changes I just tried to rebase conflicted in 50 >> different files!!! I try to split things up better these days... >> > > Oh, turns out that it was on David's original git-svn import, which I > redid yonks ago. It actually only conflicts in 7 files. Unfortunately my > script error reporting overhaul hasn't been rebased in over 4 years and is > badly conflicted again. > I am kinda amazed and impressed that you can actually keep working on such long branches. That's a superpower :D Still, I am happy to see any of them merge sooner rather than later :D > > >> >> >>> >>> 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 >>> >> _______________________________________________ > 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
