[Lachesis]

It makes the code more readable, so it's just "filename.ext" instead of "GHSDFHUIASHDFIUAH&^$^@&@&^@&%$@^&#&#filename.ext"

I get sick of those ampersands, you know

edit: I also forget to add that bit from time to time and it saves me an extra testing session after having to go back and fix it

This post has been edited by Lachesis: 23 July 2011 - 07:11 PM

[Lachesis]

A built-in debug log. Messages would be appended by . "!LEVEL! Debug text" and could be viewable in-game perhaps as a part of the F6 or F11 functionality (what does F5 do in-editor? That's another possibility). . "!ERROR!" condition stuff could even optionally have the log pop up automatically or whatever. Before some smart-ass idiot says something about using FWRITE, remember that you can only have one file open for reading OR writing at any time, which may already be used in the code I want to debug, and that adds the extra step of going to look at an external file when this would be much more convenient integrated directly into MZX itself. *"" and WAIT 20 that I have to go back and remove manually when I'm done is getting old.

This post has been edited by Lachesis: 06 August 2011 - 03:28 AM

[ajs]

One way to implement this would be to build MZX -mconsole on windows and patch SDL to write stderr/stdout to this console. Running MZX would start a console window, then the SDL window would appear. This used to be how debug builds worked; I haven't built MZX on Windows in debug recent enough to know if it still does. This would probably require that there was a third executable file built in this mode (mzxdebug.exe or something).

On Linux/MacOS the user could start the program from the command line and the shell would be used automatically.

People have asked for "debug comments" before, I think it's a good idea (in lieu of a real debugger, like Revvy's). In the longer term much more information could be added to the log than just user messages.

--ajs.

[Lachesis]

I haven't treaded anywhere near far enough into MZX's inner workings to know what that would entail... is it simple enough to make it into 2.83b?

[increpare]

I was reading the megazeux is dying thread and wrote the following in response, before realizing that this thread was probably a more appropriate place for it.

-------

I'm going to step in here and offer some Opinions (without having any personal intention of following them through, unfortunately. I have big big big big piles of respect for the mzx maintainers - I was really impressed with how well it works, and the whole infrastructure that's in place for the community is really impressive). The most important things, to me, as someone outside the megazeux community who was thinking of making games in it are

1: no/few bugs (the current lion crash bug is a deal breaker for me - other than this I've really been impressed with its stability)
2: easy way to export stand-alone builds (or alternatively and more farfetchedly, a flash/javascript exporter). It was pretty easy to rig the mac version of Megazeux to launch a single game. It would be great if there was an "Export mac,linux, and windows standalones" command somewhere in the editor.

If these were in, I'm pretty sure you'd get people regularly making games in jam situations ( Ludum Dare and Klik of the Month in particular). Being able to distribute executables is more or less a necessity for use in these ecosystems.

It may end up becoming a bit more niche as time goes on, but it's a really beautiful engine - I'd love to see more people using it, and would happily encourage people to do so if it was stable and the exporters were in place. ANSI-appreciation is definitely not a thing of the past - one of the main forums I frequent has just had this thread come to prominence.

Supporting an engine is hard, often unappreciated, and frequently lonely work - for what it's worth I love what you're all doing here. I think it's really special.

<3

[Lachesis]

Creating a "stand-alone build" can already be done, though perhaps not as intuitively or cleanly as one would like, and would have to be handled manually for each platform... you'd remove the megazeux binary from the build, rename mzxrun to [game name], and set the default world in the config file to [game name].mzx, which sounds like what you mentioned above. I believe you'd also have to make the MZX source available with your game. I think the idea of a real way to export executables has been discussed in the past but with nothing particularly conclusive... it's a lot more unwieldy than having a platform program and a library of games that can be run from it at any time. I understand your point of view, though.

I also seem to remember a recent post noting that the lion crash is an SDL bug that's out of ajs's hands at the moment something or other.

[asgromo]

Quote

it's a lot more unwieldy than having a platform program and a library of games that can be run from it at any time.

The unwieldy solution done as well as possible that better suits user biases, use cases, etc, always beats the graceful solution "done right".

[Dr Lancer-X]

There's no need to distribute the source with the game if it's unmodified, you just need an offer to make it available. Hopefully MZX already comes with the information on how to get the source code but anyway...

It is, of course, easy enough to distribute a 'standalone' MZXrun that will run a given game. You can also easily provide it with a unique icon using a standard windows resource editor (and afaik MZX, at least on Windows, fetches the icon out of the resource to use for the window) The only thing lacking is an automatic tool for doing this for you. I don't think it necessarily needs to be a part of MZX itself though- surely an external tool, possibly one provided with MZX, would be sufficient? If we can create one that even makes a nice NSIS installer for the game that would be even better.

I have no clue about packaging games for other platforms as I've not done it so if I were to try and make something like this it would most likely be win32-only. It would be nice to have a cross-platform tool that produces packages for all platforms, sort of like renpy does.

[Lachesis]

asgromo, on 21 August 2011 - 03:01 PM, said:

The unwieldy solution done as well as possible that better suits user biases, use cases, etc, always beats the graceful solution "done right".

Of course. I meant to infer that that was the reason that no real solution had been implemented, besides general lack of outright demand -- we rarely get anybody from outside the community asking for it and almost everybody inside the community is content with it the way it is. That doesn't mean that it shouldn't be done, though, and I was not trying to say that it shouldn't. There are probably a few non-community people who'd like this feature but simply haven't asked. This is the sort of thing that would extend our user base, even if just a little.

[increpare]

Lancer-X, on 21 August 2011 - 09:13 PM, said:

It is, of course, easy enough to distribute a 'standalone' MZXrun that will run a given game. You can also easily provide it with a unique icon using a standard windows resource editor (and afaik MZX, at least on Windows, fetches the icon out of the resource to use for the window) The only thing lacking is an automatic tool for doing this for you. I don't think it necessarily needs to be a part of MZX itself though- surely an external tool, possibly one provided with MZX, would be sufficient?

Absolutely. OSX icons are their own format, but they're separate files that're just located in one of the application bundle subdirectories. For OSX you also will want to modify the info.plist xml file to change the application name. I'll have a look see if I can figure out how renpy deals with icons in a cross-platform manner.

Quote

If we can create one that even makes a nice NSIS installer for the game that would be even better.

Might just be the circles I hang about in, but for smaller games, people have a definite preference for zips. (Renpy does zips for windows/mac, and .tar.gz (maybe tar.bz2, can't remember) for linux).

This post has been edited by increpare: 21 August 2011 - 10:12 PM

[increpare]

renpy makes it all look quite tractable - I've pasted the relevant code from distribute.py here. (icon stuff is the most complicated/arcane in it,).

"If you want to change the icon for the executable file, you'll need to save your icon as "icon.ico" (exactly), or icon.icns for Macs, and place it in the game's directory (NOT in the "game" folder, just above it). Ren'Py should replace the packaged ".exe" file automatically when you make your distributions. If not, you will need to manually replace the icon using some sort of resource explorer. If you are using OS X and have installed Xcode, the Icon Composer utility can generate both icon.ico and icon.icns for you."

So it seems that on osx it can do both, if you have random software installed, but otherwise it requires you to do both manually. Not particularly elegant. But if it's good enough for renpy, then maybe it's acceptable here. (A search brings up that the ever-pleasant devil library has both ico and icns output support).

Quote

I have no clue about packaging games for other platforms as I've not done it so if I were to try and make something like this it would most likely be win32-only.

Forgot to reply - I'd be willing to help out with a template for the mac one. No idea about linux. It'll need some icon muddling stuff that I don't understand yet, modifying a text file, and copying folders. When you say win32-only, you mean the packager, or the targets, or both?

[ajs]

One advantage of using the megazeux binary instead of the mzxrun binary is that you get the updater -- MZX can be configured in config.txt to point to a server of your choosing, and the format of the update information is fairly simple. An example is here:

http://updates.mzx.d....uk/updates.txt
http://updates.mzx.d...83/windows-x64/
http://updates.mzx.d...64/manifest.txt

This is a great way to ship beta versions of your game to people -- it enables them to update the game and game files automatically by pressing F7. All you need is some web space.

--ajs.

[nooodl]

Alt+D should really give a confirmation dialogue.

[Lachesis]

ALT+D seems like its functionality should be limited to the palette editor alone. I didn't know you could even do it outside of the palette editor.

[Lachesis]

Quote

20:30:08 <Lachesis> what'd be more useful is a thing that replaces itself with the counter being set
20:31:00 <Lachesis> especially if the counter being set is $butfuk&$derpderp('loopcount')&.&LOCAL27&
20:31:36 <Lachesis> who wants to write THAT more than once, nobody is who
20:32:47 <Lachesis> so what you'd be able to do is set "bhsdfjhbsdfjk22" "(@-1%2+1)" or whatever

The @ in the bolded sample code would be replaced with the current value of "bh...k22". When you're dealing with string indexing, expressions to calculate what counter you want to modify, writing the same counter name more than once gets old pretty fast, and a shorthand for it would be nice I guess though I don't know how easy/hard it'd be. While INC/DEC/MULTIPLY/DIVIDE/MODULO work in this regard for pretty basic operations, I find myself not being able to use them a whole lot.

This post has been edited by Lachesis: 21 October 2011 - 02:44 AM

[Scarmiglione Malebolge]

Why not add (emulated) AdLib tracked music format as mods, in .RAD files? (See Reality ADlib Tracker, you will know what I mean). There are great programs for tracking AdLib OPL2 Music, they work great in dosbox. I recommend the emulators by Ken Silverman and Tatsuyuki Satoh. For .RAD files you got a pro -- they are sorted by orders, just like mods. Adding such support will greatly ease composition, as I say, one can't fiddle with samples as one can with FM synths. Ask on the VOGONS (Very Old Games On New Systems) fora, it is a great place to start your quest.

The pros:
You get that vintage sound and iMUSE-like interactivity (you can never have the iMUSEness with OGG and WAV)
You are less dependent on the Amiga tracker formats and (shudder) samples.
The cons:
PLAY MOD SAM # won't work with such modules.

[Old-Sckool]

Add an option to the config to auto-hide the help bar for the robotic editor, and change the Alt-H functionality in the robot editor so that the Help bar remains hidden for as long as the user is editing the world (at least).

[ThDPro]

The config already has that unless my editor is magic.

[Lachesis]

Line 348 in my version of the config file... the option is called "robot_editor_hide_help", set it to 1.

edit: Misread the second thing, but it's still just nitpicking

This post has been edited by Lachesis: 18 December 2011 - 03:45 AM

[zzo38]

Lachesis, on 07 September 2011 - 02:47 PM, said:

ALT+D seems like its functionality should be limited to the palette editor alone. I didn't know you could even do it outside of the palette editor.

In the DOS version of MegaZeux, and in my forked version, ALT+D outside of the palette editor does not reset the palette, instead it toggles to use default colors when placing objects on the board (such as c06 for chest/sign, c0e for money, c04 for dragons, etc).

(But I agree the ALT+D function in the palette editor should be limited to the palette editor)

(If you want the codes, you can ask me for it, and fix it if you do not like it)

This post has been edited by zzo38: 25 December 2011 - 05:57 AM

[zzo38]

smilymzx, on 25 June 2011 - 07:19 PM, said:

I know centipedes are not going to be easy, But wanted to port a few ZZT games, the problem is with support for centipedes in robotics never work properly!

Yes, there are some difficulty to port ZZT game to MegaZeux, since it is a different system. Some things would have to be done manually but the fork version I made might help I even wrote some example of ZZT gem code and ZZT key codes so that it can learn how work. But in general you are not really supposed to port ZZT game to MegaZeux (just post the ZZT file instead it help better; that way is known for sure is the same game!!). (There is no need to add additional elements to MegaZeux; I made up the way to add your own individually for each game)

[smilymzx]

With MZX being a GCS that is getting old, and requests will be rejected every single time, Why bother?

EDIT: The Post Lachesis made made a lot of sense, as I figured to let it go until time goes by enough!

This post has been edited by smilymzx: 27 December 2011 - 07:05 AM

[Lachesis]

The requests that aren't terrible do not get rejected, they just haven't been added because the slow state of development at the moment. Lack of reply doesn't mean the features have been rejected, it just means ajs hasn't gotten around to it, yet. It might be good if someone went through this thread (lolilover, terryn or I) to compile a comprehensive list of unanswered requests so it's easier for ajs to go through them, though.

edit: Here's another idea: how does a tracker project for feature requests sound?

This post has been edited by Lachesis: 27 December 2011 - 07:08 AM

[smilymzx]

Lachesis, on 26 December 2011 - 10:57 PM, said:

The requests that aren't terrible do not get rejected, they just haven't been added because the slow state of development at the moment. Lack of reply doesn't mean the features have been rejected, it just means ajs hasn't gotten around to it, yet. It might be good if someone went through this thread (lolilover, terryn or I) to compile a comprehensive list of unanswered requests so it's easier for ajs to go through them, though.

edit: Here's another idea: how does a tracker project for feature requests sound?

Sounds Awesome,

I will also remake a list of my current and future requests (in the order of High to Low priority) in one textfile for use in that tracker feature.

This post has been edited by smilymzx: 28 December 2011 - 03:27 AM

[Lachesis]

The point is actually to have a separate tracker thread for every individual request. That makes it easier to catalog them and reply to each one individually. Once the initial wave of requests gets cleared through it won't be as bad as it sounds.

[Lachesis]

From this point on, the administration would prefer it if you direct your feature requests to:

The New Feature Request Tracker

Thank you! : )

I'm still looking into changing some things management-side, so in case the tracker shits the bed, I'll leave this thread open. Like with bug reports, it makes it a lot easier for us if you keep it one request per thread in the tracker. That's right, your own special request gets its own thread now!

[Frobozz]

Lachesis, on 28 December 2011 - 03:37 AM, said:

From this point on, the administration would prefer it if you direct your feature requests to:

The New Feature Request Tracker

Thank you! : )

I'm still looking into changing some things management-side, so in case the tracker shits the bed, I'll leave this thread open. Like with bug reports, it makes it a lot easier for us if you keep it one request per thread in the tracker. That's right, your own special request gets its own thread now!

But if we do that, won't that make the Tracker part of the site get more activity than the forums?

[Dr Lancer-X]

To be fair, that's not exactly a high bar.

[Lachesis]

Ideally, yes.

[Lachesis]

if you have any small feature requests to make, go ahead and check out the Feature Request project in the Tracker. no stuff like "make 3d mzx!" or "make netmzx!" or anything that's already been shot down, implemented, or approved