[Dr Lancer-X]

Spectere, on Oct 30 2005, 05:17 PM, said:

If F2_MENU were wiped out, how would you prevent the player from changing the game speed?

You DON'T. That's most of the point =P

Look at that game Nanobot released. Far too slow on the speed he set it to and he set f2_menu to 0 to top it off . I couldn't play it until I changed that

By all means, set the game speed. But don't lock people out of changing it. If people want to change it, they can. If you don't let them it will just irritate them. Let people decide themselves how they will best enjoy your game.

[Spectere]

What I'm looking at are the more competitive games where you shouldn't change the speed. And yes, you can argue "YOU CAN EDIT THE GAME" and, if it's released as a save, "YOU CAN HEX EDIT THE GAME" but it still makes things less convenient.

I guess that is kind of a special-purpose thing, but it's still something to consider.

[Dr Lancer-X]

If people who made these games were as good with judging appropriate speed then I'd say yes.

[Elig]

I like the optional F2 menu. Just because someone can screw their game with it, doesnt mean it's a bad feature. It just means that some people will have to get better at making games. If someone wants their game to run at a certain speed, let them have that speed. If people think that speed sucks, either they wont play it, and maybe the author will change the speed.. Or, the player will be so hell bent on playing the game that he'll change the speed. Either way, it doesnt mean it's a bad OPTION to have. Take Nano's game. If it was too slow, then that's Nano's fault for either not being a good enough judge, or not allowing the F2 Menu. It's not the option's fault that nano wasnt a very good judge of that. He DID have the option to leave the F2 menu in, and he chose not to. If that makes his game bad, then it's his decision that has made it bad.

If someone made a game that they very specifically wanted to run fast, or slow, I dont see any reason to prevent that.

[Dr Lancer-X]

if people think they will enjoy the game more my changing the speed, by all means, let them change it

isn't that the purpose of games after all?

[Koji]

Ummm the purpose of games is to change their speed?... I don't quite follow. =(

[Spectere]

Pretty much all it would do is make this automatic:

:set_speed
set "mzx_speed" to 1
wait 1
goto "set_speed"

...or whatever the counter for the speed is. If the author is willing to write those extra three lines it'll still effectively lock the speed of the game, and there's nothing that can be done about that aside from editing the world.

Locking the speed wouldn't change a thing.

[RoSS]

I used the code Spectere showed a long time ago for Boing! because if the game were any slower, it would defeat the entire purpose of it and make any scores meaningless. I don't think disabling speed changes is such a bad thing. For instance, what if you were writing a music game and had to have exact timing? Changing the speed would fudge everything up.

[Pyro1588]

Koji, on Oct 31 2005, 07:40 AM, said:

Ummm the purpose of games is to change their speed?... I don't quite follow. =(

i think he meant the purpose of games is to enjoy them.

at this point, i don't see any real reason to remove the counter. if an author really wants to abuse the speed, then it is just a matter of setting up a loop. not a whole lot of point to removing the counter, is there?

[paulguy]

What if I want to change volume or turn off music/sound.

[Exophase]

Spectere, on Oct 30 2005, 05:17 PM, said:

Half-agreed with the F2 thing. If F2_MENU were wiped out, how would you prevent the player from changing the game speed?

Also, how about a "config_file" and or "mzx_dir" option? That would allow people to easily set up MZX as a file type in Windows. They could do something like this:

E:\Games\MegaZeux startup_file=%1 config_file=E:\Games\MegaZeux\config.txt mzx_dir=E:\Games\MegaZeux\

Even if it were possible to have MegaZeux search in the executable's directory for the config and font files (under Win32-only, obviously) that would be splended.

That's how it works now (on Windows only), so it shouldn't be a problem. For other platforms you can change the fixed directories in the compile configuration.

Anyway, about this speed stuff... the main reason enter_menu and help_menu were removed were so you could use those keys for something else, although I think help_menu is probably the worst offender in a sense, unless you REALLY need F1 for something else (don't see what the user gains by disallowing people from getting help, but I guess you could give your own help). I don't think they're really there to lock people from changing things, but I don't really know since I didn't add them.

Whether or not the user should be able to change these things is kinda a grey subject. It depends on whether or not you consider MZX games to be self contained or running on top of an obvious virtual machine. For instance look at emulators - they let you change all kinds of things pertaining to how the game is played, including volumes and speed. It's impossible for games to have been self aware of these things, but do people think that they should have been? Furthermore, as far as the audio things are concerned, those are definitely more global settings than per-game settings. I don't think the games should even have access to such a thing outside of module volume (something they control now), which is more of a local thing.

What I could do is remove F2_menu and make it so if mzx_speed is ever set in a game it removes the option to change the speed...

- Exo

[Spectere]

Exophase, on Oct 31 2005, 05:35 PM, said:

That's how it works now (on Windows only)

"Now" meaning 2.81, I presume?

And, yeah, RoSS makes a very good point. Some things do require very strict timing. How about this:

F2_MENU gets wiped, MZX_SPEED causes the speed to get locked when it is set. When it is set, the previous value of MZX_SPEED is saved as a sort of "user speed" setting. When the game is done loading or whatever (*looks at Grunges 2's loading screens*) the game can set the counter back to 0 and the user's preferred speed will be used.

[Elig]

I like the idea of it locking the game speed, and still being able to access the volume menu. The difference between emulated games and MZX games is that an MZX game knows about the speed setting, and the ability to change it. Emulated games really had no knowledge that the speed would ever be alterable. There's a big difference there. Here, we're talking about people knowingly not wanting the player to change the speed, and attempting to prevent the player from doing so. For instance, if the SNES had a speed option, I'm sure that some games would have taken measure to make sure the game was played with a certain speed.. But, whether that's a good or bad thing, I don't know. Is the ability to alter a purposefully slow/fast game's speed a good thing? Anyway...

I like the idea of locking the speed option. Mostly because there's absolutely no reason to lock the entire menu. Specifically, there's absolutely no purpose in limiting someone's access to the sound options. In fact, that could be annoying under certain circumstances Speed is a completely different issue than sound. I can control volume quite a few different ways. Through my speakers, through windows, through my sound card, etc... I cant imagine how stupid a game would have to be to demand to be played at a certain volume. It's just a good internal option to have. However, I should note that the ability to alter the volume something is played at internally could be helpful for various audio effects. Though Ive never heard it used for such...

Also, though I cant remember if MZX_SPEED is read only or not, but if it isn't... You could just record the user's preferred speed manually. There's no reason to add another built in counter, if that's the case.

This post has been edited by Elig: 01 November 2005 - 03:59 AM

[weasel]

Elig, on Oct 31 2005, 08:59 PM, said:

However, I should note that the ability to alter the volume something is played at internally could be helpful for various audio effects. Though Ive never heard it used for such...

I actually used this effect in the underground waterway and the phone room in Silence. Though the scenes in question were both done by making a MOD file of the ambient sound, and adjusting the volume of that through Robot commands...

[Dr Lancer-X]

Like with the board editor, could we have the robot editor remember if it is in alt-h mode or not? I'd like that, but it's certainly not necessary

I dunno how many other people use alt-h anyway

[zombieguy]

An option (or just change it) to have the mouse auto-hide whenever you're not using it.

[Koji]

You mean in the editor? Cause if so I agree, I hate how if you forget about it for long enough you soon mistake it for a character that you didn't want there, and as you chase it, it runs away!!

Not really, but it is a minor annoyance.

[Pyro1588]

alt+h?
*boots up mzx and checks*
oh yeah! now i remember... and i second lancer's suggestion. also if you could add an option in the config file to always be in alt+h mode, that'd be cool.

also, i know people have mentioned using charset-specific chars in windows and them not always working. right now, i have them working in text windows, but they don't work in things like board names. (and yes, i was using special chars in board names. esp. in idiocy 2 =)

[Exophase]

Pyro1588, on Nov 3 2005, 04:31 PM, said:

alt+h?
*boots up mzx and checks*
oh yeah! now i remember... and i second lancer's suggestion. also if you could add an option in the config file to always be in alt+h mode, that'd be cool.

also, i know people have mentioned using charset-specific chars in windows and them not always working. right now, i have them working in text windows, but they don't work in things like board names. (and yes, i was using special chars in board names. esp. in idiocy 2 =)

There IS an option for that in the config file.

- Exo

[Pyro1588]

oh. my bad. the board names thing still stands, though. i like having colorful board names...

[Ter13]

Megazeux is in C++ now, right? Why should there be any limit to the number of sensors or robots?

I mean, just use a mutable array ([*]), and keep track of how many robots there are currently in that array. Better yet, use a collection object.

Anyway, point is: Why have unnatural limitations? If someone deems they need it for a game, why disallow it? I mean, sure, maybe one person may actually THINK they need 10,000 robots, and they probably don't, it's them that suffers from lag when the robot interpreter wants to run through it all...

Anyway, thanks Ex, later!

[Wervyn]

As I understand it, the reason this has not been added yet is because it would require a change to the world format to work. Currently, the only thing that changes between minor version numbers is the save file format (where things like counters and strings are ultimately stored, and thus why their number is effectively unlimited already). Someday, probably, you'll be able to have as many robots and sensors (though why would you want THOSE?) as you need. That's for MZX 3.0, though, and remember that we're still waiting on version 2.81.

"MZX needs to have optional groundlights and spinners."

[Exophase]

All objects have to be linked on the board as an ID. Right now that ID is in two fields, a type and a parameter (so robot in one, ID in the other). For MZX3 I want to combine these into one, so you could have 64k parametered objects (this does impose a new limit on the number of paramered builtins you can have at once). Anything else would require less elegant collision detection and what have you. Anyway, there are a lot of other internal structure things that can't be easily changed without completely changing the way MZX works. Some things were changed with the move to 2.81 but not every aspect of the basic subsystem. Robots are still executed by being scanned from the board, not from the board list of robots (that's how all things are updated)

BTW, this has nothing to do with what language MZX is written in o_O It's technically almost completely C, the only reason it still has .cpp extensions is because of some tricky parts. The biggest thing it's lacking that C++ could provide are STL containers, of course (and I plan to migrate MZX3 to that, but MZX2 will stay C)

- Exo

[zombieguy]

Allow for backups to be saved without the .mzx extension (or with a different extension such as .bak).
Simply because of it looking messy to see 8 .mzx files in a directory when you never really need any of them unless MegaZeux poops on your main game file (which hasn't happened to me since dos mzx). Although, I don't want to take any chances by turning auto backup off.

[weasel]

Easier copy/paste with Ctrl+C/V. And also support for the clipboard, because sometimes it's a real pain to have to shuffle through different text files to get things transferred to and from MZX.

[Wervyn]

Quote

And also support for the clipboard, because sometimes it's a real pain to have to shuffle through different text files to get things transferred to and from MZX.

It's already there. Did you try? It is, by the way, effin' awesome to be able to select text in the robot editor, copy it, and directly paste it somewhere else. Or vice versa. I feel certain this feature was in the changelog, but you know, who actually reads that?

"Also I would like my robot to be able to explode 16, instead of just 15."

[weasel]

Let this be a testament to my idiocy then.

[Ter13]

Can we have the ability to read sprites from the overlay? This would save me some problems here and there. Any hope? Is it already done? Yes? No? Blue?

[Spectere]

The answer, my friend, is "blue."

I don't see any variables for allowing sprites to be referenced from the overlay. I doubt using the +coordinate syntax would work, but you could always try it.

[Ter13]

Nope. No dice this time around.