This took my breath away. Very useful, good, little tool.
This took my breath away. Very useful, good, little tool.
To Clickteam Staff: I strongly suggest to add Snippet Manager to the Community Links!
Thanks, I'm flattered
Anyone hasn't downloaded it yet and wants to, the latest version is here:
Anyone who has already downloaded the app, but wants the latest snippets, the download is here:
Dragonguy: I'd really appreciate it if you could take a look at those 3D Engine snippets - see if they work first of all, and if not maybe you could help me understand why. I will also need to write an extra readme to tell people how to use them...
I've also added some snippets to calculate X and Y array coordinates from a fastloop index. This should hopefully make it really easy to load maps etc stored in arrays using fastloops. That was inspired by Pixelthief.
this is great, thanks muddymole. the only thing that could make the tool even greater would be an online database where users can upload, download and rate snippets...
yeah, that would be great...
I found theres a few slight errors in your 3D Engine Math (I compared your Math to the working Math in the 3D Engine of my 3D Game), you had X Position Relative to Camera & Z Position Relative to Camera the exact wrong way round, it should be.
X Position Relative to Camera.Z Position Relative to Camera.Code:Cos(0->Camera Angle<)*(Alterable Value >Z Position Value<( ">Object<" )->Camera Z<) - Sin(0->Camera Angle<)*(Alterable Value >X Position Value<( ">Object<" )->Camera X<)Every other peice of Math you put in the 3D Engine Folder is 100% correct.Code:Cos(0->Camera Angle<)*(Alterable Value >X Position Value<( ">Object<" )->Camera X<) + Sin(0->Camera Angle<)*(Alterable Value >Z Position Value<( ">Object<" )->Camera Z<)
Also- Iv'e figured out how your INI's work so I can now create new Math Snippets.
I have already created an update for the 3D Engine Snippet & I have built a new Snippet which allows you to click & drag a box like in your favourite RTS Games.
More Snippets to come from me.
Dragonguy: Thanks very much. I really appreciate that
The other thing I thought of, is do you actually need all of those?
I'm sure it's not too tricky to merge a couple of them, so all you have are snippets to calculate ScreenX, ScreenY, RelativeZ, and Scale without the "in-between" steps.
lincore: I thought about that, or atleast I thought about making it automatically download my latest snippets. To be honest though, I don't know much about doing online stuff in MMF. Perhaps if I can get some help I'll add that in the next version.
I've thought of a few other modifications I'd like to make, such as tooltips to tell the user what each variable does, aswell as the option to link to a help file for each group of snippets - some complicated ones such as Dragonguys, really need their own detailed help or people won't understand how to use them.
EDIT: I see you just posted while I was typing - I'll take a look at those. thanks again
Well yes they can be difficult to use, I will include a tutorial for each of my snippets in the next release of Dragonguy's Snippets.
Some criticism though. Skip the whole deal about duplicate snippets for objects and values, it only makes simple things more complicated. If I want to use the X position of an active object as a value, I'd simply insert X( "Active" ) as the value.
This also makes it harder to update snippets when an easier expression is found. I've already found a rather huge mistake. For example:
Between Two Objects - Euclidean (normal) uses the nice and simple expression:
Sqr((>X Point 1<->X Point 2<) pow 2+(>Y Point 1<->Y Point 2<) pow 2)
while Between Two Points - Euclidean (normal) uses the bloated expression:
Sqr( ((>X Point 1<->X Point 2<)*(>X Point 1<->X Point 2<))+((>Y Point 1<->Y Point 2<)*(>Y Point 1<->Y Point 2<)) )
In addition to the mistake about having a poorly written expression in the list, don't you spot another? The first one uses values too, while other distance related "Object" snippets reffers to X(">Object 1<") etc. I noticed that this mistake occured in at least one other snippet, so be sure to validate them all again.
Having separate snippets for objects and values fails at many points.
* People might forget to update the math in both of a twin object/value snippet.
* People might forget to use values in Value snippets and objects in Object snippets.
* It's hard to teach people who write snippets what the difference is, and to not make the mistake in the two points I made above. They have already been made after all, and my experience tells me that a lot of people are not careful enough to keep an eye open for these things.
* The ease of use. It's easier to remember a smaller list of snippets, nobody wants to have duplicates of everything (it clutters the list), and everyone who even only knows the basics of how expressions works should understand they can use anything as values, including positions and alterable values of objects.
Although I guess twin snippets for object/value can have it's upsides, the downsides outweight them by far. The only reasonable soliution is if twin object/value snippets can be integrated into a single snippet with a object/value selector. Having the object/value variations as two lines of text next to each other should make it a whole lot easier to keep them in sync.
Looks like I had forgot to get the latest version of the snippets, but as I did, I spotted that the issue with the distance snippet which used values instead of objects was fixed. However, in this case, the maths was replaced by the ones in the bloated expression which used too much parenthesis and didn't take advantage of "pow 2". Even the fix was a fail. This is why I really think the system must change. Oh, and "Between Two Points - Approximation.ini" is still wrong.
Despite my criticism, don't forget the "this is an awesome piece of software" aspect in all this.