<div dir="ltr"><div>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.</div><div><br></div><div>And I do agree that 5000 local NPCs is more than enough.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><span class="gmail-im">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.</span></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>To clarify: I admit that it just doesn't matter much, so go whichever way you think is best.</div><div>I find overthinking/worrying about there being a better way really takes the fun out of implementing features. </div></div></blockquote><div><br></div><div>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 >:)<br></div><div><br></div><div>---</div><div>James<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Aug 23, 2020 at 11:20 AM Ralph Versteegen <<a href="mailto:teeemcee@gmail.com">teeemcee@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 24 Aug 2020 at 03:09, Ralph Versteegen <<a href="mailto:teeemcee@gmail.com" target="_blank">teeemcee@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>(Oh no, too many words from me again)<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 24 Aug 2020 at 01:57, James Paige <<a href="mailto:Bob@hamsterrepublic.com" target="_blank">Bob@hamsterrepublic.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">I feel like adding a new pool argument to all those commands is the easier way to go.<div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div></div></blockquote><div> </div><div>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)<br></div></div><div class="gmail_quote"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto">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)</div></div></blockquote><br><div>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... :)</div><div>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.<br></div><div>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).</div><div><br></div><div>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.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto">But I am still open to having my mind changed :)</div></div></blockquote><div><br></div><div>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 :) <br></div><div><div>createnpc(npctype(1,2), x, y)<br></div><div>createnpc([1,2], x, y)</div><div>createnpc("enemy/3", x, y)  # A named pool<br></div><div><div>createnpc("enemy/plip", x, y)  # Probably what other game engines would do<br></div><div><div><div>createnpc("::plip", x, y)  # Global scope<br></div></div></div></div></div><div>createnpc(2g, x, y)   # A unit, compare "wait(2 sec)"</div><div><br></div><div>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.<br></div></div></div></blockquote><div> </div><div>To clarify: I admit that it just doesn't matter much, so go whichever way you think is best.</div><div>I find overthinking/worrying about there being a better way really takes the fun out of implementing features. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div></div><div><br></div><div>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).<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat., Aug. 22, 2020, 10:42 p.m. Ralph Versteegen, <<a href="mailto:teeemcee@gmail.com" target="_blank">teeemcee@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>(I could have sworn we discussed this previously, but I can't find anything on the mailinglist or SS)</div><div><br></div><div>That would be great!</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div>(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?)<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 23 Aug 2020 at 06:21, James Paige <<a href="mailto:Bob@hamsterrepublic.com" rel="noreferrer" target="_blank">Bob@hamsterrepublic.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">I was thinking of starting work on global NPC definitions soon.<div dir="auto"><br></div><div dir="auto">I believe I will add an "NPC pool" number to each NPC instance which tells which pool of NPC definitions it uses.</div><div dir="auto"><br></div><div dir="auto">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)</div><div dir="auto"><br></div><div dir="auto">NPC references and ids will still work the same, but there will be new get/set NPC pool commands for full control.</div><div dir="auto"><br></div><div dir="auto">I am cautiously optimistic for an easy implementation<br><div dir="auto"><br></div><div dir="auto"><br></div></div></div>
_______________________________________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org" rel="noreferrer" target="_blank">ohrrpgce@lists.motherhamster.org</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer noreferrer" target="_blank">http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org</a><br>
</blockquote></div>
_______________________________________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org" rel="noreferrer" target="_blank">ohrrpgce@lists.motherhamster.org</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer noreferrer" target="_blank">http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org</a><br>
</blockquote></div>
_______________________________________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org" target="_blank">ohrrpgce@lists.motherhamster.org</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer" target="_blank">http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org</a><br>
</blockquote></div></div>
</blockquote></div></div>
_______________________________________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org" target="_blank">ohrrpgce@lists.motherhamster.org</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer" target="_blank">http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org</a><br>
</blockquote></div>