Reply to Re: PyDink player demonstration
If you don't have an account, just leave the password field blank.
February 13th 2013, 03:59 AM
shevek
Thanks for the feedback! I'll reply to every suggestion twice, because PyDink has two target platforms: it can compile things into a real DMod, which can be played with Freedink or any other "old" engine, and it can be played natively in the player that this video was made from.
The compilation is bound to the limits of the original engine. The native player is not. However, because I want to support compiling to a DMod, the editor has some limitations.
the game was properly paused
Compiled DMods can't fix this.
For my engine, it is already done, and it is one of the reasons I didn't implement editor_type() for temporarily killing a sprite yet; I want this to work properly as well.
Fixed missiles would be cool
I didn't do anything about it for compiled DMods; it would be good to implement your script as part of the compilation.
My engine doesn't check for collisions with text sprites; I think death sprites are not nohit, I'll change that. I don't think my engine has the speed problem.
You mentioned something about the editor converting scripts? A script converter from DinkC to ShevekC would be an awesome addition if this doesn't already exist. I realize a reversed converter that goes from ShevekC back to DinkC would probably not be possible, but that is fine.
It's the other way around. When compiling, I convert from PyDinkC (I like it better to name the engine than the author
) to DinkC. I originally planned to write a script decompiler as well, to allow converting DMods to my file format. However, that is often not possible and I would have to support goto for it, which I really don't want. So I dropped that idea. This means that the following are possible:
- A DMod made with my editor can be played with my engine and compiled to a normal DMod and played with other engines (and edited with other editors, although I wouldn't recommend it; generated code is not nice to read).
- A DMod made with an other editor can not be played in my engine. I do have a decompile script, which builds a world with tiles and sprites from it. I'm planning to add hardness as well. However, it does not decompile the scripts, so these have to be rewritten before it can be played. Still, this is a great debugging feature, because my editor can jump to warping/warped to location (I never used wde, but it is a feature I missed in dinkedit).
Adding a delete savegame() function.
Good idea. I still have to implement saving. I want to implement a feature that saves are abused for as well: inter-instance communication. I want to add a config file which can be read and written by dmods, which can contain things like "player has seen this ending".
Make it so sp_kill_delay() works in weapon functions to get rid of the attack delay.
I'm not really sure what that function is supposed to do, and if I find that useful at all. I don't think I have implemented this delay that is supposed to be killed.
Thanks for the feedback.
The compilation is bound to the limits of the original engine. The native player is not. However, because I want to support compiling to a DMod, the editor has some limitations.
the game was properly paused
Compiled DMods can't fix this.
For my engine, it is already done, and it is one of the reasons I didn't implement editor_type() for temporarily killing a sprite yet; I want this to work properly as well.
Fixed missiles would be cool
I didn't do anything about it for compiled DMods; it would be good to implement your script as part of the compilation.
My engine doesn't check for collisions with text sprites; I think death sprites are not nohit, I'll change that. I don't think my engine has the speed problem.
You mentioned something about the editor converting scripts? A script converter from DinkC to ShevekC would be an awesome addition if this doesn't already exist. I realize a reversed converter that goes from ShevekC back to DinkC would probably not be possible, but that is fine.
It's the other way around. When compiling, I convert from PyDinkC (I like it better to name the engine than the author
) to DinkC. I originally planned to write a script decompiler as well, to allow converting DMods to my file format. However, that is often not possible and I would have to support goto for it, which I really don't want. So I dropped that idea. This means that the following are possible:- A DMod made with my editor can be played with my engine and compiled to a normal DMod and played with other engines (and edited with other editors, although I wouldn't recommend it; generated code is not nice to read).
- A DMod made with an other editor can not be played in my engine. I do have a decompile script, which builds a world with tiles and sprites from it. I'm planning to add hardness as well. However, it does not decompile the scripts, so these have to be rewritten before it can be played. Still, this is a great debugging feature, because my editor can jump to warping/warped to location (I never used wde, but it is a feature I missed in dinkedit).
Adding a delete savegame() function.
Good idea. I still have to implement saving. I want to implement a feature that saves are abused for as well: inter-instance communication. I want to add a config file which can be read and written by dmods, which can contain things like "player has seen this ending".
Make it so sp_kill_delay() works in weapon functions to get rid of the attack delay.
I'm not really sure what that function is supposed to do, and if I find that useful at all. I don't think I have implemented this delay that is supposed to be killed.
Thanks for the feedback.
