[Mod] Simple Shooter [0.6.1] [shooter]

[stu]

found a bug, if you place a torch on grass and then shoot the grass with a rifle, the torch will float until you break it with your hand.

I am not sure if there is anything I can do about that but I will look into it, thanks for the report.

[rubenwardy]

Are you using dig_node or whatever, the one to dig a node as a player?

[stu]

Are you using dig_node or whatever, the one to dig a node as a player?

It is currently using remove_node so that is why the torch does not drop, however, something tells me there was a good reason for not using dig_node. I just cannot quite remember what that was =)

BTW, since you are, probably, the biggest user of this mod (CTF) I'd be interested to know how you feel about bruno's idea to split it into a modpack. https://github.com/stujones11/shooter/pull/22

[rubenwardy]

• A sniper gun with a scope - possibly using zoom
• Faster bullets

[stu]

• A sniper gun with a scope - possibly using zoom
• Faster bullets

A scope gun using zoom is on my todo list for the next release but afaik fov_zoom is still an in-dev feature.

Faster bullets should already be possible to some extent by tweaking the levels. However, I do plan to further optimise the bullet physics, possibly using the 'new' ray-casting methods over my current Lua implementation. I need to do some careful profiling to see exactly how that effects performance. Once again, this relies on in-dev features so like some of my others mods, development is pretty much on hold until the next MT release.

[rubenwardy]

Oops, my previous post was quite rude. I just copied and pasted what a player asked me for without adding a message. No rush anyway, thanks for this great mod

[stu]

Oops, my previous post was quite rude. I just copied and pasted what a player asked me for without adding a message. No rush anyway, thanks for this great mod

lol, no worries, I just read it as a simple feature request but did wonder if you had perhaps missed a part. I did not think it was rude, I know that's not your style :)

[stu]

Re: faster bullets, looking back at the code, I think that the bullets are already pretty fast. Essentially the speed is determined by the`SHOOTER_ROUNDS_UPDATE_TIME` config and the individual gun def `step` size. So with the default update time of 0.4 and a step-size of 50 the bullet effectively travels 50 nodes in 0.4 seconds. In reality, however, if the target is less than step-size distance away then the hit is almost instant (as far as it can be).

This makes me wonder if your player was either (a) experiencing the effects of server lag or (b) is referring to the bullet animation, which is simply a particle effect and has no relation to actual hit response time. I guess I should at least make the particle velocity relative to the step/time.

[Stix]

i play ctf and know for a fact the bullets are slow, at long range (20+ meters) you can easily dodge them, so you have to aim where the enemy will be, not where they are.

[HONEYBOOBOOCHILD]

What is the max ranger for bullets?
I see "range=" in "guns.lua" but it seems like the range is limited to somewhere around 100 nodes.

[LMD]

At first : Thanks for this great mod. The best about it IMO is the Crossbow, I like how you made the arrows :)
At second, if I get you right, your weapons haven't got instant hit, but instead are just very fast(better solution) ? But you are using vectors. => You are using recursive minetest.after(shotspeed,check_hit) or like that ?
Or am I wrong ? Are you using globalsteps ? AFAIK minetest after is better...
Thanks in advance, I'm currently working on another firearms mod...

[stu]

Version Update: 0.6.0

Now updated for Minetest version 5.0.0

• Reduce effective shotgun range by ClobberXD
• Crossbow texturing update by doyousketch2
• Separate weapons and api with help from BrunoMine
• Remove hard mod dependencies other than 'default'
• Update and document shooter api
• Replace deprecated minetest api methods
• Use `minetest.raycast` for hit detection

Planned features for the next release include:

• Optional HUD effects mod
• Optional custom player mod with more realistic shooting animations
• Voxel styled 'mesh' weapons
• More interesting shot effects

[Lone_Wolf]

Version Update: 0.6.0

Now updated for Minetest version 5.0.0

• Reduce effective shotgun range by ClobberXD
• Crossbow texturing update by doyousketch2
• Separate weapons and api with help from BrunoMine
• Remove hard mod dependencies other than 'default'
• Update and document shooter api
• Replace deprecated minetest api methods
• Use `minetest.raycast` for hit detection

Planned features for the next release include:

• Optional HUD effects mod
• Optional custom player mod with more realistic shooting animations
• Voxel styled 'mesh' weapons
• More interesting shot effects

Awesome, Great mod

[BrunoMine]

New shooter
https://forum.minetest.net/viewtopic.php?f=9&t=22418&p=347068#p347068

[ANAND]

Great to see v0.6.0 finally released. Great work, keep it up! :)

I see great potential in the new `on_hit` callback, and can be used for some very interesting effects.

I understand bullets were slow because of the fact that collision-checking used to happen only once every 0.1s. I haven't seen the code changes in this area yet, but now that shooter uses Raycast, is it possible to make them faster? Or are they already faster and I just haven't noticed it yet? ;)

[stu]

Great to see v0.6.0 finally released. Great work, keep it up! :)

I see great potential in the new `on_hit` callback, and can be used for some very interesting effects.

I understand bullets were slow because of the fact that collision-checking used to happen only once every 0.1s. I haven't seen the code changes in this area yet, but now that shooter uses Raycast, is it possible to make them faster? Or are they already faster and I just haven't noticed it yet? ;)

Thanks, I am really not sure about the speed issue, using raycast may improve matters in multiplayer a little but fundamentally it works almost exactly the same as before except previously it compared the dot-products of each player/entity position. It was the caching of those positions that made it a lot less accurate, however, it has always been pretty fast.

As I mentioned a few posts up, you can speed things up generally by reducing the `shooter_rounds_update_time` You can double the speed of all guns by setting this to 0.2 instead of the default 0.4, so long as this is not less than the dedicated server step it should be fine. Alternatively, you can increase the 'step' of the individual weapons to cover more distance in the same amount of time.

To be honest I am really no expert on firearms, the default speed seems okay for me but I welcome any contributions to the project if you think you can improve the realism.

PS: I fixed a crash caused by Rubenwardy's commit =D My own fault for not reviewing thoroughly enough or testing, fortunately it was after the release tag anyway.

[ANAND]

Ah I didn't know about that post, thanks for letting me know. Also, thanks for the tip about step and shooter_rounds_update_time.

... (b) is referring to the bullet animation, which is simply a particle effect and has no relation to actual hit response time. I guess I should at least make the particle velocity relative to the step/time.

So the bullet travel animation isn't in sync with the actual response time? From my experience, I think that animation is perfectly in sync with the response time, because the player is dealt damage only when the bullet particle reaches them, irrespective of their distance.

[stu]

Version Update: 0.6.1

• API updates and bug-fixes
• Improve bullet particle velocity
• Add global entity damage coefficient
• Use per-player camera height
• Allow multiple shots per round and optional spread
• Add `get_weapon_spec` method by @rubenwardy

So the bullet travel animation isn't in sync with the actual response time? From my experience, I think that animation is perfectly in sync with the response time, because the player is dealt damage only when the bullet particle reaches them, irrespective of their distance.

If is was then it was purely coincidental. I have now made the particle velocity a function of `step` and `rounds_update_time` with a little factoring for latency, however, this may need some further tweaking, I'm not 100% sure yet.