[Ohrrpgce] Global NPC definitions

Sun Aug 23 19:29:31 PDT 2020

On Mon, 24 Aug 2020 at 05:04, James Paige <Bob at hamsterrepublic.com> wrote:

> 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.
>

If you do go for single ID numbers, I suggest something like npcid = 5000 +
pool * 1000 + id, to stop the ID numbers growing large. A limit on the size
of a pool would be pretty inconsequential if you can just switch to the
next.

>
> 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.
>
That's a good idea.

> 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 >:)
>
Yay!

>
> ---
> 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
>>
> _______________________________________________
> 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/20200824/c0e8c045/attachment.html>