Small things, does the drag box Y and X scale/position stuff really need different snippets for X/Y? It could just be called Scale/Position, the math is identical except the X/Y letters. In addition, the snippet assumes that you don't name your alterable values (see: Alterable Value >Relative Y Origin Value<), that's like encouraging to not comment your code.

Oh, and although I agree that it was dragonguy who created the snippets, I'd like to claim that I had a little to do with them too (link), although I don't want credits for it.

Oh, and the Doom expression is my creation as well, although it was originally made as a joke: Abs(360*Min(Max(Y( "Point A" )-Y( "Point B" )+1, 0), 1)-(ASin((X( "Point B" )-X( "Point A" ))/Sqr((X( "Point A" )-X( "Point B" )) pow 2+((Y( "Point A" ))-Y( "Point B" )) pow 2))+270))

Worth to mention is that it is only guaranteed to work with integers. Float Y values between 0 and 1 generates invalid angles (it can happen if you're not dealing with object positions).

Ok, thanks for the suggestions.

I can see that it would have been easier to use the "pow" function in that expression. I'll make the changes.

I'm a bit confused though.
I don't understand what you mean about the other mistake. If it says >Object< or >Object 1< or anything like that, then it wants you to enter just an object name. If it says something else, then it wants you to enter a value. You wrote that first expression as an example right, cos mine does use object names?
I don't want to sound argumentative, but I just don't get what you're saying.

Obviously it's less work for me to not have duplicates for object names and values, but it means more effort for the user.

Take the distance example you mentioned. By using the "object" version, the user only has to enter two variables - the objects' names. If they are forced to use the "point" version they have to enter 4 different variables, all of which are more complicated than just a name.

Can I just check - you are entering the values in the boxes in the Snippet Manager, before you copy the expression to MMF aren't you?

The next version I make will also have tooltips for each variable, to explain to the user exactly what they do and the type of thing they have to enter. Hopefully that would help prevent making the mistakes you mentioned.

I agree that it looks a bit clumsy when you have something like "Alterable Value >Angle<(">Object<")" but it makes it easier to use because the user doesn't have to retrieve any values - everything they need to enter is really simple.

Still, I will bear your comments in mind. If you have any suggestions on how to improve the actual app itself I'd like to hear those too.

Again, you've posted while I was typing!

I didn't know any of that about those Drag Box snippets. Like you say, it wasn't me who made them. My apologies for not crediting you with the "doom" expression. I'll rectify that too.

I get what you're saying about the alterable values, and I thought about it myself. It's just that I don't want the user to have to be using "retrieve from object..." all the time - that pretty much defeats the purpose of the app.

You completely misunderstood me about the other problem. It has nothing to do with usage (I understand how it's used), in fact, the other mistake I mentioned is when the snippet creator confuses point snippets with object snippets. In an earlier version, the problem was this:

Between Two Objects - Euclidean (normal).ini
Sqr((>X Point 1<->X Point 2<) pow 2+(>Y Point 1<->Y Point 2<) pow 2)

...and in the process of fixing that, the one with good maths was replaced by the one with bloated maths, so that's how a fix became a fail.

What I suggest is an improvement of the app. Integrate object and value twins into a more advanced single-snippet file with multiple modes for each. That provides a better overview and prevents further mistakes of the kind I've already seen. Since mistakes have already happened at this early stage, I'd doubt it will get easier to manage when more third parties are involved in snippet creation. Only having them in a single file will provide an overview obvious enough for all users to handle. We're talking about a community where 90% of the programmers doesn't even comment code they upload as examples for other people to learn from. Things needs to be carefully organized here.


I can not see that really. Even back in the MMF1 days, I always named alterable values before I started to use them. The snippet only really works for programmers who's not organized enough to do that.


That would be true if people remembered to use the terms correctly. However:

Between Two Points - Approximation.ini
((Max(Abs((>X Object 1< - >X Object 2<)), Abs((>Y Object 1< - >Y Object 2<)))) * 0.941246) + ((Min(Abs((>X Object 1< - >X Object 2<) ), Abs((>Y Object 1< - >Y Object 2<)))) * 0.41)

Here, >Object< does obviously not symbolize actual object names. I'd have expected >Point<.

I see. You'd prefer it to say ">X Point 1<" rather than ">X Object 1<".

Yes, it's usually good to rename alterable values. Here's the problem though...
Take the 360 degree movement expression as an example. The user is having to use MMFs "retrieve data from object" 3 times. The only thing left to add is a "Cos" here or a "*" there. Why bother using a snippet?
Maybe the whole concept of snippets *is* flawed - perhaps we're just better off with a long text file full of expressions, that you just open up in notepad and press "search".

In my own opinion though, I'd rather just enter a name and a couple of letters, even if it means not having the luxury of renameable alterable values.

No, my idea is that if the app features single-snippets with both object and value modes that you can toggle between, you can just select the snippet, chose "object mode" and insert the object name, and get the entire output to paste. I'm talking about a snippet format that would look something like this:

Between Two Points - Manhattan.ini
[Details]
Description=This calculates the Manhattan distance between two objects or points. That is, the distance covered when allowed to move only horizontally or vertically.
[Mode 1]
Mode Name=Objects
String=Max(Abs(X( ">Object 1<" )-X( ">Object 2<" )), Abs(Y( ">Object 1<" )-Y( ">Object 2<" )))
Variable1= >Object 1<
Variable2= >Object 2<
[Mode 2]
Mode Name=Points
String=Max(Abs(>X Point 1<->X Point 2<), Abs(>Y Point 1<->Y Point 2<))
Variable1= >X Point 1<
Variable2= >Y Point 1<
Variable3= >X Point 2<
Variable4= >Y Point 2<

If a snippet only features one mode, the text fields the other mode uses can simply be hidden.

That kind of overview doesn't leave much room for mistakes, does it? Seeing it all at the same time will make it hard for the creator to confuse objects with points (have happened two times), and to have different maths for object/points mode (have happened one time), or replacing the effectivent formula with an ineffectivent one (which have also happened one time).

Anyways, unless there's any further misunderstandings, I've pointed out what I think, I won't bug you any further about it. The reason I suggest this is only because I think the Snippet Manager is so good that it would be best if everything was perfect. As a bribe, I'll send you a paypal donation if you add this feature

Now I get it...

Yes, that's a very good idea.
It seemed before like you had something much more complicated in mind, but I'm sure that was just me being confused again.
That actualy looks very do-able.

Sorry if it seemed like you were talking to a brickwall. I've just had a hardtime understanding - in my defense it is 1am and I'm tired

Don't worry As promised, if you add it, I'll send money by paypal (not that much, but something around $50). Also, don't take it personal that I may sound a bit more harsh than I intended when I debate things at 2am


I just came up with a great solution to that, so now I'll bug you one more time despite that I said I wouldn't.

After all, you do normally remember what you name your values, right? How about: >Name of Alterable Value<(">Object<")? If you add the possibility to fields to have default content, the >Name of Alterable Value< field could have the default string "Alterable Value ?" - all the user would have to do is to either replace the ? with the letter of the alterable value OR erase the default string and write the custom name of the desired value. That works for both users who name their values, and users who doesn't.

You should use the download object to automatically download the latest version

This is AMAZING!

As I said in Gwerdy earlier today....
MMF needs the ability to recognize named variables. That is, you name AltValA "grav", and while in the expression editor you type Alterable value A( "Active" ) instead of grav( "active" ), as soon as you hit ok it will continue and rename AltValA to grav in the expression. This would stop the problem here with the snippets as Nifflas noted.