Need help for items wich are usable on the map

I'm stuck. I want to include a Boomerang in my game the Pumpkin Warriors.
I'm not that good in plotscripting and wanted to ask how I can make a Boomerang wich can do the following:

-If you press the B button it will be thrown in the direction you are looking

-It can get you Items from far away (Items are made with NPCs)

-It starts a battle if you hit an enemy with it (enemys are also NPCs)

Have the script create an npc that paces. Then have it delete itself when it hits the player. You'll also need to run a loop to check for monster and item collisions.

It's a fairly complex script, if you don't have a good grasp on how to get it started your best bet might be partnering up with someone that does. Otherwise I doubt things will end up the way you want them.

I think this is a very complicated script that you are looking for. I don't think the OHR is an ideal platform for these types of mechanics (overhead Legend of Zelda type 'items'). Slices might make this easier than it once would have been, but it will still require a lot of scripting expertise. Consider the following questions:

1. What happens if the player uses the boomerang, then moves? Is the boomerang supposed to be able to move diagonally to make its way back to the player?
1a. If the answer to that is yes, is it supposed to pick up items/trigger enemies on that diagonal path as well?
1b. If the answer is no, what happens if another NPC triggers the player while the boomerang is 'away'? Should the player be allowed to trigger a menu while the boomerang is 'away'?

2. What happens when the boomerang hits a 'wall'? Should the boomerang be able to recognize some 'walls' as passable, such as passing over water that the player cannot? What happens when the boomerang hits a non-enemy npc? Should it stop and come back, or pass through? What if it hits something on its way BACK instead of on its way OUT? It should be able to distinguish this case, right? And just pass through no matter what...? Or can the player actually 'lose' the boomerang?

3. Do enemies have similar 'items'? How are they handled in relation to the player's 'items'?

These are complicated questions that a correct script will have to address and answer in coding-form. This is on top of the 'basic' questions like how far the boomerang should travel if it doesn't hit anything, and ensuring that the player hitting B twice doesn't magically throw two boomerangs.

I pointed all this out because I think it's important (if you're new to the OHR) to realize just how many detailed questions need to be answered to script something OTHER than an RPG in the OHR. Again, all of these questions CAN be resolved with plotscripting, but it will be a LOT of time and effort. On the other hand, there may be other engines out there that handle these things automatically for you; ie the engine assumes you want 'Zelda-style' behavior, and programs it for you beforehand.

---

I am Srime

I read what you guys just wrote, and realized that it is really hard to program a fully working boomerang. I'm now thinking about a shovel, wich can remove special "blocks" like sand. I thought about disguising some NPCs as blocks and just sort of set tags on with the shovel, but then again, it would remove every NPC/Block wich is influenced by this tag. Is this easier to do it right, harder, or the same difficulty as the boomerang?

This sounds like a much easier plotscript to arrange, and I think we on this board will be more willing to help you through learning how to script something like this. As a general rule, the more independent motion there is in a script, the harder it usually is to work in the OHR. This shovel example features no movement at all, so it sounds like a good starting point. The boomerang had to move away from the player then back again, and the player could have maybe moved in the meantime. Much harder to find people willing to help with something so complicated.

To get you started, here's how I would plan a script like this:

1. When a player presses the 's' key, the game should check to see if he/she has the shovel, and if so, attempt to use it. This will be an on-keypress script. Checking for the shovel will be easiest with a tag. If the player doesn't have the shovel, the script should probably end here and do nothing.

2. If the player has the shovel, perhaps a graphic should be displayed showing the player 'digging'. This graphic might best be a slice attached to the hero (this is something I don't know very much about). While showing the graphic, the player should NOT be able to move.

3. While the graphic is displayed, the script should check the x,y coordinates of the player and see if there is anything to dig there. This will probably be easiest by either having a special group of tiles in the tileset that are always 'diggable', or by having a special NPC for places to dig (like you were thinking - but as you noticed, tags don't seem best here).

4. What kinds of things need to happen during a 'successful' dig? Should the maptile graphic change? Should a textbox come up saying that the dig was successful? Only when an item was found? Are buried items supposed to be predetermined in custom.exe, or 'random' like in the SNES Zelda game? This might seem like a lot of questions again, but I think they're much simpler questions than the boomerang questions.

---

I am Srime

Both of these aren't really that hard to do. My question to you, frogman, is what exactly are you really looking for here?
I could explain how both of these can be done with a fair amount of ease. But, either of them are a bit too much to simply script out to a relative newcomer for basically nothing in return. I'd also like to point out that you'd likely want to have at least a few of these types of scripts in a completed game of this type.

This is why you should look for a good scripter and convince them to help you with your game or try your hand at learning scripting yourself (it's easier than you think) Otherwise, you're just going to be working with bits and pieces of the mechanics that you actually want in your game.

Hm, maybe Spoonweaver is right. I just feel like the boomerang script has a lot more to account for. On the other hand, I think the shovel script could be one that we could help you with to learn about how to script things yourself. This is assuming you've read the basic plotscripting tutorial. On the other hand, if you are trying to avoid learning how to script things yourself, then you will probably need a dedicated scripting partner for scripts of this type.

---

I am Srime

If you make the boomerang stop the player from being able to move, that will remove a lot to account for in scripting it.

---

My pronouns are they/them
Ps. I love my wife

Thanks for all of your replies, and I'm happy to say that I found a friend of mine who is actually very skilled in plotscripting.
It's also a good idea to stop the player from moving whilst the boomerang is being thrown.

If you guys have some more time for me I would be very happy if you can teach me how to script the shovel. But I really don't want to annoy you.

heh, scripting friend fall through?
it happens.

Well, there are a lot of ways you can go about doing the shovel. An item can be designed to run a script when used. This would be when the item is used from the item menu. If you wanted it to be usable through a specific button, that would be a slightly different script.

But, let's see if I can help you. I'll assume you're not very familiar with scripting at all.

so first you need to state your script header. This includes things like



Next you'll want to read the maptile. That's this command

You'll want to make the x into herox(me) and the y into heroy(me). The layer can be ignored.

That will return what tile number you're standing on. Now you have to do something with that. We do that with an IF/THEN statement.



Here we've run digdigdig (which is a new script we'll make in a second) if the tile you're on is tile from your tilemap. (not tile 0 which is top left tile on the set.) IF it's not tile 1 you're standing on a sound is played instead. This should be an error sound to tell the player you can't dig here.

Next you cap this script off with an;


Then start the next digdigdig script with a


(we use script here to start instead of plotscript so this one won't show up in the editor as selectable. this one is only for use within another script. scriptception)

We need to suspend the player here so they don't run off while their character is digging. Players are always trying sneaky things like this. We put a suspend player command here and then just before we end the script we'll use the resume player script. We can't forget the resume player script because without the game will stop playing after we dig.


now we start the digging sequence. This is should start with an animation. We do this by changing the hero sprite with this command;
set hero picture (who,picture,type). When used for our purposes we ignore the type so it goes tot he default of the walkabout type. We use me to mean the leader of your party, and we'll set the picture to picture 2 for a little bit. this picture can be changes to what ever you want the first frame of the digging animation to be. Then we'll wait a bit with the wait(time in ticks) command; set the hero's picture to the sprite changing command again, which I'll call picture 3 for now; we'll wait a bit longer with the wait(time in ticks) command again. last we'll reset the picture to complete the animation. It'll look like this:


now we'll select from a random set of textboxes to show the player. The textboxes can give items, set tags or even just say, nothing was found. We'll do this here with the showtextbox(textboxnumber) command, a variable, the random command, and a switch/case/do command.
to put skip the explaination it looks like this:


lastly, we change the tile we've dug. We do this witht he write map block command. We're going to use tile 2, it's likely you'll want to change this number to something else. All you need to do is change the 2 towards the end of the following piece of code.


We're about to end the script. Remember how I said not to forget the resume player command. This is where it goes.


Thats the end of this second script and thus the end of the whole thing. you cap it off with an end command and set to compiling the script, importing the script, setting an item to run the script and finally testing the script.

Here's the complete code, please read the above post before using it. This code is free to use for anyone and the above post is free to copy and post elsewhere as well.
Knock yourselves out.

I just wanted to chime in to say that there's no point giving in to mediocrity if it's possible to accomplish exactly what it is you want to accomplish. As Spoonweaver says, there are people here who can help you get to the place you want to go. It might not be easy; it might even be less simple to understand the process required to get there. But, if the engine is capable of doing what you want, then don't try to substitute with something easier just because it's easier, if what you really want is not the thing that's easier. All the best artists, scripters, etc. got to where they are today because they didn't settle for mediocrity, or what was easier.

This isn't to say that you shouldn't practice with smaller things. You totally should. But don't stop yourself from implementing the bigger things if they can be implemented. Just learn and practice as you go. Trust me, if I can script, anybody can. I'm a programming idiot, yet I've pulled off some ridiculously ambitious stuff just because I knew the engine could handle it.

So, you're biggest job isn't to learn how to script a shovel or a boomerang. Your biggest job is to find out what the engine can and cannot do. Then decide if it's better to keep your boomerang or downgrade to a shovel.

---

Place Obligatory Signature Here

Well Spoonweaver's script is an example for a possible shovel action (although there should almost certainly be a suspend player somewhere to prevent the player from moving around). But you (Froginator) haven't really indicated to us what precisely you want the shovel to do. If you do want to learn to start writing your own scripts, I think it's important for you to work out in your mind precisely what you want to happen during the script. See my 4th point in my other reply.

I noticed in your original post about the shovel, you said you wanted it to "remove" sand blocks. It's hard to be sure what you mean by this.

PS: I haven't scripted anything in ages - don't the case blocks need their own parentheses?

I'm not sure if this is necessary.

---

I am Srime

I don't think the Boomerang is as difficult to make as everyone is making it out to be. I'd personally create an NPC, and also allow the player to freely walk around while the Boomerang is out. Here's how I'd do this:

When player uses Boomerang, check that they go it.
Next, create an NPC that has all the frames a working Boomerang should have in front of the player.
Set up a global variable that tracks the Boomerang. It might also be a good idea to create a specialize Boomerang NPC on every map you would like the Boomerang usable on, and keep the NPC# the same for every map to make it easy to reference.
NPCs can store internal values, so you could use these to store the state and a timer variable in.
Then use the set timer function to control the actual Boomerang, for this you would have 2 options, you can either set the timer to a specific time you want it to go away from the player. Say you want the Boomerang to fly 1 second away from the player, then come back. Your other option would be to run it on interval to check the status of the Boomerang, like if it hit something on the way. Looking at what you want, you'd want to use the latter.
This script should check the NPCs X and Y position, and check both the tile and a possible NPC in front of it. You can then react upon the tile or NPC accordingly.
Once the Boomerang has flown far enough from the player, simply set the NPC to "chase mode", and voila! The Boomerang will basically chase the player where ever she or he might run. You may want to turn off wall checks for the NPC if you want it to fly through walls like in Zelda.
Then use the timer script to see if the Boomerang is back on the player, then delete it and turn off the timer, etc...

Come to think of it, I really wish NPCs had their each-step script, that would make this sort of thing easier... Maybe I'll look into the source code of how the player on-step script works and implement the same logic for NPCs.