Castle Paradox

[Camdog]

Can they change during the course of a game? Specifically, if I 'destroy npc' one of my NPCs, is it possible that would change the reference numbers of the other NPCs on the map of the same ID? That appears to be the behavior in custom, and there are some strange things that happen in some of my projects that would be explained by this.

If this is the case, is there way around this? Any permanent reference I can get to an NPC copy that will always be accurate?

[Moogle1]

What are you doing specifically? I haven't done anything that kept track of NPC refs for awhile, but it's been my experience that they don't change.

Regardless, you may be better off using npc reference(id, count) instead of storing the reference locally.
_________________

Slime Salad :: Independent Game Design

[Camdog]

I'm storing a series of bullets in a list, which grows upon the addition of new bullets, and destroys the bullet and removes the corresponding list item when the bullet moves out of bounds.

In the game loop, I iterate through the list, moving and disposing of the bullets as needed.

The list code works dandy when I'm dealing with plain integers, so I don't think it's losing the NPC references at any point. During the game, firing a single bullet works fine; it travels across the screen and disappears as appropriate, and this can be repeated ad infinitum. However, when multiple bullets are on the screen at the same time and one is eliminated, some of the npcs representing the bullet stops, some move at double speed, and some behave as normal. If the references are getting shuffled during a 'destroy npc'. it makes sense that the references stored in the list would sometimes be pointing to non-existent npc copies, would sometimes have a few references pointing to the same copy (hence the speed up as the npc is moved two or more times in the game loop), and would sometimes behave normally.

It's certainly possible the list code is screwy somewhere, though I tested it pretty thoroughly.

[Bob the Hamster]

No reference shuffling happens.

an NPC reference should remain valid until the map gets reloaded.

The only thing I can think of that might be related to your problem is the fact that after you destroy an NPC, its reference number can be recycled by later create NPC commands.

Can you tell us more about your script? (or maybe even post it?)

[TMC]

(Actually, npc references aren't shuffled in Custom either. It's the copy number that changes)
_________________
"It is so great it is insanely great."

[Camdog]

Sorry guys, I've once again posted my question prematurely. The issue was with my list code (a simple case of forgetting that calling the delete function with the default argument eliminates the last record in the list, not the current one. sigh) It just seemed that this explanation fit so well. I guess it was partially correct, since the super fast bullets were a by-product of reference re-use... anyway...

I do plan to post the code, soon. I hope to put together a pseudo-object oriented library for people to use. (In case you hadn't noticed yet, I'm talking about a hamsterspeak implementation of a linked list.) I just want to make sure I have some working proof of concepts in some example games first. Thanks for thinking about this!

[TMC]

Pseudo object orientated? I look forward to seeing it.

Have a look at this thread: Arrays vs. Linked Lists, where you'll find incredible amounts of discussion and scripts.

You might not want to hear this, but...

When arrays and dictionaries/associative arrays/maps are implemented (and for once, I think that this isn't too far off), I plan to add commands to wrap the use of these for common structures like queues and heaps. I am thinking about how a linked list should be implemented.

Perhaps I should optimise the internal implementation of arrays of length maybe <= 3 to make Lisp's list implement an efficient possibility. The thought makes me a bit queasy though.

I plan to implement associative arrays using a B+Tree (with a multimap variety), so that O(n) in-order traversal allows them to be used in creative ways.
_________________
"It is so great it is insanely great."

[Pepsi Ranger]

I may be slightly off subject (and several months late) with Camdog's post, but I just wrote a script that confirms that NPC References and Destroy NPC commands do affect each other.

I assigned ten treasure boxes to the same NPC type, but used an NPC reference stored in ten different variables to separate each one.

The script calls a "destroy NPC" function after a treasure box is "pulled" (through animation and all the whatnot).

An autorun script is supposed to memorize through globals which boxes were pulled and which are still active.

This works like a charm except for one problem: The copy count shifts after the selected NPC is destroyed.

Case in point:

The first time out, I assigned individual references to variables.

[TMC]

[Bob the Hamster]

How about if the NPC placement mode in the map editor allows you to assign a name to a specific already-placed NPC. That could be exported to your HSI file as a constant for the NPC's reference.

Although I'm not sure if it would be better to format the constantants as map 5 NPC: Dumpy the Mutt which is more specific...

or NPC: Dumpy the Mutt which is cleaner-looking and easier, but might be prone to confusion if accidentally used while you are on the wrong map :P

[TMC]

If you want to expose NPC references in HSI files, we also do it directly in Custom.

I vote for "Map XX NPC:Name", otherwise you can't give two NPCs on different maps a throwaway name like "left guard", which seems undesirable.

Perhaps it would also be a good idea to optionally encode the map number into an NPC reference for checking (maybe only in NPC references in HSI files, if the "NPC:Name" scheme is used), say new NPC ref = NPC ref + (1 + map) << 16.
_________________
"It is so great it is insanely great."

[msw188]

Wait, where are you going to assign the names? The only issue here is with multiple copies of the same NPC ID, so you'd have to be able to name them from the NPC-placer. And where would you see them? There's not really room for a name in NPC-placing mode.

Honestly, all of this sounds like more trouble than it's worth to me. It might be helpful in a limited number of cases, but there will be other chances for confusion. If the author deletes an NPC in custom, he will need to re-export the hsi, and re-compile and re-import the script, in order to not screw everything up. This is at least as counter-intuitive to me as the current scheme. The author will also be in trouble if they accidentally put the NPC in the wrong place - deleting the NPC in question and re-placing it will also necessitate a lot of things outside of custom. I think the best thing to do would be to simply try to be as clear as possible about the constancy of references, but the dynamics of copy counts.
_________________
My first completed OHR game, Tales of the New World:
http://castleparadox.com/gamelist-display.php?game=161

This website link is for my funk/rock band, Euphonic Brew:
www.euphonicbrew.com

[TMC]

[Bob the Hamster]