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

Reply via email to