I am writing some simple C plugins to manipulate frames and am finding that Pro Motion can get a bit confused if I send it modified frame pixel data while the project is in Tile Mapping mode.
In this case the frame’s pixel data that I send does not match Pro Motion’s understanding of the current state of the tileset and tilemap, and the displayed image gets out of sync with the internal representation, even when “Sync Mode” is enabled.
This may or may not be considered a “bug” as such, but it definitely gives the user some unexpected behaviors.
It is quite probably a good idea that sending an image from a plugin doesn’t suddenly add a bunch of new tiles to a project, but I can also imagine cases where I would actually want it to do so … this seems to be a perfect thing for the “Sync Mode” setting to control, but I don’t seem to have any way to change that setting from a plugin.
Anyway … is there some way that my plugin can determine that the current project is in Tile Mapping mode, so that my plugin can display an error message instead of causing this undesired behavior?
Also, for plugins that want to create a new layer, whether the project is Tile Mapped or not, is there some way in the plugin interface to make the new layer be the top layer so that its contents are visible?
When I create a new layer in the plugin, the layer seems to always be created at the bottom of the stack, and so it is not visible without my maually rearranging the layers in Pro Motion.
Please note, this behavior is easy to reproduce with the official DDETest.exe plugin.
Just open a Tile Mapping project and make sure that “Sync Mode” is turned on, and that “Allow New Tiles” and “Modify Existing Tiles” are set.
Open the DDETest plugin. You can just double-click on the .exe to run it, you don’t need to add it to Pro Motion’s plugins.ini.
Execute the “RECEIVEFRAME” plugin command.
The image is transferred to Pro Motion and appears on your screen, but … the new tiles are not added to the tileset, and if you go to paint over something in the image, then Pro Motion ignores the transferred image itself and retrieves the tile that it thinks should be there, but isn’t.
This image shows what happens when I paint a single pixel into a tile.
well, both are bugs
The plugin should work the same way as when drawing, not destroying any tile map data.
And adding a layer should also work the same way as when adding one in the UI.
Will fix with next update.
-Jan
P.S.: Great to see that there are people using this old plugin interface. Wanted to introduce a new one, but did not find the time yet
I would like to write a plugin that can create an overlay for a Tile Mapped project that can be used to signal game-engine conversion problems with the Tilemap … just like we used to BITD.
This would be usefile for meta-tiled maps on PC Engine/Megadrive/SNES retro projects where you’d set Pro Motion to use 8x8 tiles in order to take advantage of tile repetition and use Pro Motion’s “sync” feature, but the game engine itself uses 16x16 or larger meta-tile groups (made up of references to the individual 8x8 tiles).
Well, I original bought version 4.0 of Pro Motion back in 1999, so it’s about time that I finally wrote a plugin!
Yes, if you were going to try to make Pro Motion truely multi-platform, since Embarcadero’s Delphi is supposed to support that these days, then you’d have to replace the Windows-only “DDE” method with “pipes” or something like that.
Anyway, part of the reason for writing those simple plugins was to provide examples of just how easy it is to create a Pro Motion plugin, either with, or without using a Dialog Box as a UI interface.
You’re welcome to put them in your plugin example file if you wish, the Boost license on them is about as permissive as you can get.
What I have in mind is more a HTTP based approach where PM listens on a TCP/IP port for commands. Data transfer is just done via GET/POST and JSON, maybe RESTish overall. These technologies are widely spread today.
Could need some input on most important commands to include. If you would like help me on that, then it would be great if we could continue discussing by email
Please consider carefully before opening up Pro Motion to an HTTP-based attack vector for little reason.
The nice thing about a pipe, especially a non-named pipe, is that you know exacly who you’re communicating with (i.e. the plugin that the artist just explicitely executed).
Any global listener opens you up to malicious actors, and as the evolution of the internet has proven over the last 30 years, there are a lot more of those around than anyone would have imagined back in the days when Pro Motion was first created.
Thanks for the advice!
Indeed, security is a thing and there will be some key that is passed to the executable that is started, so that it has to provide that key when talking to the server port. The server port will only be there as long as the plugin is executed.
Also, the socket must be localhost only so that it can not be accessed from the outside. That means, an attacking process would then need to run on local machine. If that is the case, it would not need to attack PM to gain local access. It already has.
But in addition I will also do some research how pipes work (never used them) and if there are any benefits over local server using http protocol.
Pretty excited that something like this is coming. I’m thinking i can do some minimal interface helpers when this becomes available. But who knows later on?
If PM opens the possibility to stream and/or send data out via the API as well, the lowest hanging fruit i could think of right now is that this could lessen the friction to posting on social media or a portfolio website.
