automatic "this." before functions?

[durnurd]

I noticed that when the code generator doesn't recognize a function, it automatically prepends a this. to it.  Is this necessary?

Specifically, I was trying to change a Do TileTouchingIndex into an If TileTouchingIndex, by simply choosing If from the dropdown menu and typing (bool)TileTouchingIndex manually into the box.  This way, I can simply check to see if the player is touching a tile in one step instead of two.  This would work, except it puts the this. before it, so it ends up as if (this.(bool)TileTouchingIndex(17, false, true)) in the code.  So close.

Of course, this isn't the only use I could think of, and I'm not sure if this happens in all cases or if this is just a fluke, but the problem remains, if it does happen in all cases, if your function isn't in the list, for whatever reason, you should still be able to type it in manually and have it work, even if it's not a member of the SpriteBase class.

So, is this necessary behavior, or could it be removed?

[bluemonkmn]

Soo... you're trying to get clever, eh? ... Well, you were on a track to success, but just not clever enough .  If you want to do that in one statement, I think you'd enter it something like this instead:

Type= "If"
Function= ">="
left operand= "TileTouchingIndex(17,false,true)"
right operand= "0"

All the functions are assumed to be methods of the current class, and are sent to the code generator (in the .NET framework) as method invocations on "this".  Because the .NET code generator is designed to generate both VB and C# (and other language) code, it kind of clamps down on the syntax so it knows enough about the code to generate it correctly in different languages.  Obviously (bool) typecasting with that syntax wouldn't work in VB.NET, so that option kind of got "clamped" out of the picture.  But I think you can still get around it if you create the rule as described above.

Of course, this is not the officially recommended mechanism for addressing your problem.  The correct solution is to add a new rule to SpriteBase.cs that simply wraps TileTouchingIndex and returns a bool.  (If that use case is common enough, I could deliver it in the default template.)

[durnurd]

Ah, cleverness.  Yes, That's what I'd go for.  I don't know why, but I just don't like changing the built-in code more than I have to (You can imagine what a time I had writing the .NET web control project).  I suppose it doesn't really matter.  While we're on the subject, how about this:  If you have code handling a specific sprite type, would you put it in SpriteBase and just call it directly from the sprite, or would you create a custom object that accepted that sprite type as a parameter?  The problem I see with the first is that any sprite could call it, and it's really only for one sprite type, while the other presents the problem of the UI not showing all sprites of the given type in the dropdown (which it would if I simply used SpriteBase instead).  Exactly how does one tell the UI to do that?  Of course, I can simply type it in manually (using either this or m_ParentLayer.m_SpriteName, depending on where I call it), but just out of curiosity, and for ease of use later.

[bluemonkmn]

Ah, cleverness.  Yes, That's what I'd go for.  I don't know why, but I just don't like changing the built-in code more than I have to (You can imagine what a time I had writing the .NET web control project).

Could it be because then you can't reset the source code without re-merging your work?

While we're on the subject, how about this:  If you have code handling a specific sprite type, would you put it in SpriteBase and just call it directly from the sprite, or would you create a custom object that accepted that sprite type as a parameter?  The problem I see with the first is that any sprite could call it, and it's really only for one sprite type, while the other presents the problem of the UI not showing all sprites of the given type in the dropdown (which it would if I simply used SpriteBase instead).  Exactly how does one tell the UI to do that?  Of course, I can simply type it in manually (using either this or m_ParentLayer.m_SpriteName, depending on where I call it), but just out of curiosity, and for ease of use later.

Is there anything that suggests that this is possible?  I thought I had implemented this, but apparently not, so if you see anything that makes it look like I did implement this, and just can't find it, let me know .  My intended plan (as a result of this realization) is to add code to allow you to accept a specific sprite type for a parameter on a custom object's functions.  (Well, OK, that part you can already do, but I'm just setting up the context here.)  Then in a plan rule, if a parameter of a specific sprite type is encountered, all the sprites of that type on the plan's map will be listed in the dropdown.  And if you try to use the rule from a sprite definition, "this" will only be an option if it's the right sprite definition.  Does that seem right and complete?

Edit: Hm, since "SpriteBase" parameters only list sprites from the plan's layer, maybe I'll only list sprites on the layer instead of the whole map.

[durnurd]

That seems correct to me, yes.  Now, I am to understand that you will implement this, as you have not yet done so, correct?  I think the only thing that suggests its possibility is that other things have context-correct dropdown menus.

[bluemonkmn]

Yes, I made sure my code won't compile until I'm done implementing it so I won't forget .  (I added a line of code where the new feature will go and left it in an unfinished state.)