Hey guys, thanks for the feedback. Sorry that I didn't notice earlier. Had a family issue recently and missed the notification.
I'll try to answer best as I can below.
MrJBRPG wrote:
I noticed that several aspects of the timing, such as shot rate, pause rate, and pause length are recorded in frames after experimenting in play mode, yet the words alone does not make it clear. Perhaps utilizing a tool-tip to describe components can make it more clear.
I agree, its ambiguous. I'll look into making that more clear.
MrJBRPG wrote:
As a stretch goal, maybe also consider the option to switch between time in frames and seconds as toggle.
As it stands it's probably best thought of as delay frames. I tend to think in frames rather than seconds but I'll think more about the suggestion.
MrJBRPG wrote:
I also noticed that the shots can be controlled through button press command with key command, which is great for testing, but might not be useful when using it for a full game because some developer would want to use it with custom control mapping solutions, like Rewired or InControl, for gamepad controllers and more.
I mentioned in the doc how ButtonPress is best for testing. I left the exposed bool up to the user to implement with their own input system, pretty much as you say you ended up using it. I have Rewired but haven't really worked with it much. If I can get it working nicely I'll definitely think about integrating support with VB. Afterall, I'll probably end up using ReWired for my own game, so may as well!
MrJBRPG wrote:
By the way, I wonder what is the difference between regular and Auto Hold on the fire commands, especially with button press and automatic?
AutoHold holds the the firing for an amount of frames depending on the value set in AutoHoldDuration. Probably best described here:
http://neondagger.com/variabullet2d-qui ... ring-shots
MrJBRPG wrote:
I found out that some shot prefabs do rotate, and I did not know until later, within the Shot folder of the scripts, that the rotation speed was actually set higher than 0. You should have a checkbox option, at ShotBase, to disable rotation and colorize settings so it becomes easier to control rotation of particles rather than having to digging too deep into dealing with numbers.
Might be a good idea. I usually prefer to keep things as simple as possible and avoid a ton of check boxes so that's why I default to "0" meaning "off."
MrJBRPG wrote:
I have discovered that when turning on the Trigger Auto Fire when Fire command is automatic, the first shot is done and takes twice as long for shot delay until the next shot, with the correct frequency. It may have something to do with fire bullet cs script under AutoFire which relies on two conditions instead of one, which may explain the cause of the unexpected additional shot delay.
My best guess is this has to do with the engine having a hiccup on play, particularly in the editor. But it could evidence itself in an actual build. Right now there's a WaitForSeconds() set in the BasePattern/SpreadPattern Awake() which I think delays execution by a frame or so. You can add to this value to make sure everything's loaded up and there's no hiccup. The next build should have a Coroutine which allows you to set whatever delay time you want and expose that via a property. I can post it here a bit later as its just a few lines of code.
n0rtygames wrote:Well done on releasing the asset!
My gripes: Object pooling on its own really sucks. I've learned this the hard way. It takes you so far. You don't want to have thousands of bullets which all have their own transforms, sprite renderer and so on. How are you detecting collisions? Does each bullet have its own collider?
I considered making the system based on sprites vs material/shader. In the end I went with sprites because I wanted to preserve as much of an oldschool feel as well as make it dead simple. Also I basically started implementing my game using BulletML and later decided to make my own system, so being happy with the gameobject/sprite model in BulletML I went with that. I benchmarked along the way and was pretty happy with the results using a very old test bench. Notice how Unity improved its collision system dramatically in newer iterations drawing a closer performance gap between particles and gameobjects:
https://neondagger.com/variabullet2d-ti ... test-bench
Bottom line is I would expect 2000+ concurrent bullets with throttling/pooling enabled running under a recent version of Unity on any system within the last 10 years, approximately (?)
And if you remove the colliders, you can probably easily do 10,000+ bullets without a framedrop (according to Unity... I didn't test it as I stopped testing at around 4000 bullets). I figure this might be used by some who want a ridiculous amount of bullets and can roll their own collision detection. Most users I don't think will need more than 1000 bullets at the top end though, probably (?)
n0rtygames wrote:Well done on releasing the asset!
If this was around when I was looking at off the shelf stuff then it would've been an insta buy just to relieve some of the heavy groundwork.
I appreciate that, thanks. I started with it being my own solution and around half-way thought, what the hell, I'll release it and maybe it'll be useful to other people and help fund my own gamedev ventures. Pretty hard to accomplish one of those let alone both!
MrJBRPG wrote:
I wonder if it is possible to implement an option to give users a boolean checkmark for "Allow shooting from nodes"
Good point! I think that's another good suggestion that should end up in the next build