[Ohrrpgce] Global NPC definitions

Sun Aug 23 10:03:51 PDT 2020

Hmm... Okay, I guess having globalness encoded into the NPC id number isn't
as bad as I was thinking, and the trade off of not having to add a new
argument to those script commands is nice. I was imagining the global NPC
editor numbering things 0, 2, 3, 4, 5 and i didn't want to do 2000 + id or
5000 + id but now I realize there is no need for me to worry about that.
Displaying an NPCs number as 5000 in the global editor will be super easy.

And I do agree that 5000 local NPCs is more than enough.

Now, in fact, I *am* planning to change NPC references so that they are no
> longer values -1 to -300. (With a backcompat bit, of course). I was even
> wanting to do it soon, along with remapping slice, menu and menu item
> handles, all to exclusive ranges of large integers that people won't
> accidentally use (which is unbelievably common with menu handles) as step
> one towards types. Such a backcompat bit could disable global NPCs.
>

I like the idea of this change. I think that NPC references should stay
negative. I think that will simplify things a lot, and it also means that
(if I do go with 5000+ for global NPCs) that there will be absolutely no
reason for that backcompat bit to disable global NPC support.

To clarify: I admit that it just doesn't matter much, so go whichever way
> you think is best.
> I find overthinking/worrying about there being a better way really takes
> the fun out of implementing features.
>

I have already started the implementation (Yay! Fun!) and I'll continue to
weigh the approaches as I go. You'll know which method I chose when you see
the commit messages I guess >:)

---
James

On Sun, Aug 23, 2020 at 11:20 AM Ralph Versteegen <teeemcee at gmail.com>
wrote:

>
>
> On Mon, 24 Aug 2020 at 03:09, Ralph Versteegen <teeemcee at gmail.com> wrote:
>
>> (Oh no, too many words from me again)
>>
>> On Mon, 24 Aug 2020 at 01:57, James Paige <Bob at hamsterrepublic.com>
>> wrote:
>>
>>> I feel like adding a new pool argument to all those commands is the
>>> easier way to go.
>>>
>>> It doesn't break any scripts, it just means the scripts need to be
>>> updated to start working with global NPCs. For local NPCs the scripts will
>>> still work exactly the same.
>>>
>>> But with pool id encoded into NPC id, doing that math becomes a
>>> permanent burden of NPC scripting. I feel like I would inevitably have to
>>> write wrapper scripts to get/set the dissected the NPC pool anyway.
>>>
>>
>> You wouldn't be doing any maths when writing scripts. You go to the NPC
>> editor, see "NPC ID 2001" for one of your global NPCs, and write "create
>> npc (2001, x, y)". I don't think it could be simpler. I can't think of any
>> reason to want to split an ID into ID/pool, but there could be scripts for
>> it and a "get NPC pool" command (I don't think "set NPC pool" makes sense
>> -- shouldn't that be "change NPC ID"?). Maybe if pool 1 are all your
>> enemies, pool 2 are all your interactive objects/items, etc? If you want to
>> organise NPCs like that, maybe what we actually need is a way to do so that
>> can be applied to local NPC types too... (not to mention all other data)
>>
>> It would also mean that we would be adding a hard cap on NPC definitions
>>> per map, which we don't currently have. (Though I have no idea what the max
>>> number of NPC definitions is in a single map that someone has actually used
>>> in a real game)
>>>
>>
>> Yes, I'm not too happy about that either, luckily I have a marvelously
>> shocking workaround for you: 0-999=local, 1000-1999=global,
>> 2000-2999=local... :)
>> That was a joke; a much better solution to just use, say, 0-4999=local,
>> 5000+=global to make the limit even more unreachable, and if anyone ever
>> hits it then they can just use global NPCs instead.
>> If negative numbers weren't NPC references, then we could use those for
>> global IDs (and could even split it into pools -1-1000, -1001--2000, etc if
>> wanted).
>>
>> Now, in fact, I *am* planning to change NPC references so that they are
>> no longer values -1 to -300. (With a backcompat bit, of course). I was even
>> wanting to do it soon, along with remapping slice, menu and menu item
>> handles, all to exclusive ranges of large integers that people won't
>> accidentally use (which is unbelievably common with menu handles) as step
>> one towards types. Such a backcompat bit could disable global NPCs.
>>
>> But I am still open to having my mind changed :)
>>>
>>
>> So am I; there are many other alternatives too. I'm approaching this from
>> the PoV of what we would do if we had types in HS. Then I think an NPC type
>> should be referable to as single value/object without needing two different
>> arguments. I think some of the following attempts are pretty yuck, but
>> won't say which :)
>> createnpc(npctype(1,2), x, y)
>> createnpc([1,2], x, y)
>> createnpc("enemy/3", x, y)  # A named pool
>> createnpc("enemy/plip", x, y)  # Probably what other game engines would do
>> createnpc("::plip", x, y)  # Global scope
>> createnpc(2g, x, y)   # A unit, compare "wait(2 sec)"
>>
>> OK. I'm ready to conclude that I'm trying way too hard, and if you wanted
>> numbered pools, either separate id/pool script args or mashed into one
>> integer are probably the best.
>>
>
> To clarify: I admit that it just doesn't matter much, so go whichever way
> you think is best.
> I find overthinking/worrying about there being a better way really takes
> the fun out of implementing features.
>
>
>>
>> Incidentally, I have an npcnames git branch for naming NPCs and referring
>> to them with constants like npc:Bob. I didn't finish because I wasn't sure
>> that it shouldn't actually be name:Bob or :Bob (like in Lisp), or "Bob"
>> (wait for strings first) or $"Bob" (translate to a special constant string
>> ID).
>>
>>
>>> On Sat., Aug. 22, 2020, 10:42 p.m. Ralph Versteegen, <teeemcee at gmail.com>
>>> wrote:
>>>
>>>> (I could have sworn we discussed this previously, but I can't find
>>>> anything on the mailinglist or SS)
>>>>
>>>> That would be great!
>>>>
>>>> However I'm concerned about the addition of a pool number to the script
>>>> commands. At least readnpc, alternpc, createnpc, npccopycount, changenpcid
>>>> and npcreference would need to gain a 'pool' argument, and many scripts
>>>> using those or getnpcid would potentially need to be updated if you start
>>>> using global npcs in a game, which is a problem for reusable scripts like
>>>> pixel-walker, dwimmerplatformy and SS101 which would need updating.
>>>>
>>>> The alternative, which is to encode the pool number in the NPC ID (at
>>>> least as seen by scripts, not necessarily internally) would avoid all of
>>>> that work, complexity, and breakage, and I don't see much downside. For
>>>> example pool_id = pool * 1000 + id. The map editor and NPC debug mode would
>>>> need to show the combined ID too.
>>>> (I feel like 1000 is too low a limit but 10000 is too many digits to
>>>> squeeze into tight spaces (npc placement mode). Maybe * 2000, etc?)
>>>>
>>>>
>>>> On Sun, 23 Aug 2020 at 06:21, James Paige <Bob at hamsterrepublic.com>
>>>> wrote:
>>>>
>>>>> I was thinking of starting work on global NPC definitions soon.
>>>>>
>>>>> I believe I will add an "NPC pool" number to each NPC instance which
>>>>> tells which pool of NPC definitions it uses.
>>>>>
>>>>> The per-map NPC definitions will be pool 0 and the global ones will be
>>>>> pool 1 (with the option of adding more global pools for organization)
>>>>>
>>>>> NPC references and ids will still work the same, but there will be new
>>>>> get/set NPC pool commands for full control.
>>>>>
>>>>> I am cautiously optimistic for an easy implementation
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Ohrrpgce mailing list
>>>>> ohrrpgce at lists.motherhamster.org
>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>>
>>>> _______________________________________________
>>>> Ohrrpgce mailing list
>>>> ohrrpgce at lists.motherhamster.org
>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>
>>> _______________________________________________
>>> Ohrrpgce mailing list
>>> ohrrpgce at lists.motherhamster.org
>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>
>> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20200823/39b162f5/attachment-0001.html>