[Ohrrpgce] Global NPC definitions

[Ralph Versteegen]

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

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20200824/f27bc0d2/attachment-0001.html>