[nooodl]

How about changing the MOVE PLAYER [dir] command to MOVE PLAYER "[dirs]" Just like the / command. It'd save a lot of loop commands.

[Terryn]

HappyFoppy, on Feb 15 2007, 11:51 AM, said:

How about changing the MOVE PLAYER [dir] command to MOVE PLAYER "[dirs]" Just like the / command. It'd save a lot of loop commands.

It'd also likely break compatibility. No.

zombieguy, on Jan 15 2007, 11:24 PM, said:

I'm positive it's been explained before why there can't be an Undo button, but I can't exactly remember the explanation. It's possible that it'd just be really hard to add one to MegaZeux, or that people have always just been "nah use backups instead".

ajs was receptive to adding this when I suggested this during "f" sessions, actually. Perhaps it'll get into "g".

zombieguy, on Feb 15 2007, 11:18 AM, said:

Currently there doesn't seem to be a way to stop spacebar from freezing the default player, even if you're not using default bullets at all. This is quite fail on MegaZeux's part.
It'd be nice if in Board Settings - "Can shoot" when unticked would not freeze the player when spacebar is held. There's no reason at all for spacebar to prevent the player from moving if 'Can shoot' is unticked, and it frees up the key for other things (which is why I'm requesting this).

It'd break compat with games that use space for a custom engine designed with this freeze in mind but I otherwise agree. A toggle for this freeze (defaults on per board) would be sensible as opposed to forcing the freeze off in all lockplayer attack instances.

[hob nado]

Okay, this is pretty nebulous and it's not really a proposal or request per se, but I wanted to bring this idea up - what do you guys think about extending the functionality of the default textbox? (And no, this is not just for Zoe Awesome's sake, although that is where I got the idea.)

Anyways, textboxes are ubiquitous in MZX games, and since the advent of the custom textbox as the de facto standard for making a good MZX game (and the fact that custom textboxes occasionally lend themselves to some ugly Robotic) maybe MZX should support textboxes to a greater degree.

Some ideas I had for options we could provide:

* Resize the default textbox
* Reposition the default textbox
* Change the border of the default textbox
* Remove the title line from the default textbox
* Allow game action to continue while textbox is on
* Lock textbox scrolling
* Change the button to proceed through textboxes

Obviously, many of these will have to be designed carefully so as not to break compatibility, but I believe it could still be done in an elegant way. What are your opinions on this? Unnecessary? Useful? Desirable? Too non-MZX-y?

[inmate2993]

Esdemo1, on Feb 19 2007, 06:39 PM, said:

* Resize the default textbox
* Reposition the default textbox
* Change the border of the default textbox
* Remove the title line from the default textbox
* Allow game action to continue while textbox is on
* Lock textbox scrolling
* Change the button to proceed through textboxes

My name is inmate and I support this message.

Seriously though, a few of those ideas are actually good. Kind of reminds me how the old Sivion demo used the default text box and did such a better job than most games do with custom text boxes.

[ajs]

Quote

* Resize the default textbox
* Reposition the default textbox
* Change the border of the default textbox
* Remove the title line from the default textbox
* Lock textbox scrolling
* Change the button to proceed through textboxes

I think all of these are trivially doable. If I have nothing left to implement, I'll consider it. Or you can do it? You've got a CS degree, right? ;-)

Quote

* Allow game action to continue while textbox is on

Having never looked at the code concerned, I have absolutely no idea whether this would be easy or hard. It's also the one most likely to break compatibility, so it's probably a no-no.

The others are really just eye candy and probably very easy.

--ajs.

[Dr Lancer-X]

Esdemo1, on Feb 20 2007, 08:39 AM, said:

* Allow game action to continue while textbox is on

Heh, are you kidding? There's no way that could ever work with existing games. No, no, no.

[hob nado]

Quote

Esdemo1, on Feb 20 2007, 08:39 AM, said:

* Allow game action to continue while textbox is on

<Lancer-X and ajs> NO

Sorry, I should have been more clear - I'm saying make that an option, with the default behavior to still block while a textbox is up, as MZX handles it now. Obviously that would bring ruin upon us all otherwise =)

ajs is right, though, that one could be trouble to code - fortunately I don't see it being essential - while the rest would probably be pretty easy. And yes, although I've never been involved in MZX development, my acquisition of a CS degree is nigh =) I'll take a look at it, maybe implement a demo or something if I get a moment.

[ajs]

(This is kinda orthogonal to your feature request, but I thought I'd clarify..)

MegaZeux's finally reaching a point where fewer crash and incompatibility bugs are being reported. It could even be considered "mature".

From my perspective, I'm not Exo, and I'll only implement things that are very _obviously_ trivial and correct, so as to not introduce more regressions. I don't have the time or the motivation to implement glitz.

So I'm all for _adding_ features, but _changing_ them (as the "send all" bugfix highlighted) is probably just a really bad idea.

If people think they can hack things up faster than I can, by all means do so, send them to me, we'll talk about the validity of the feature or implementation, and I'll either merge it or there will be a mini flamewar. Just try to keep random EXE forks to a minimum. ;-)

Quote

"Given enough eyeballs, all bugs are shallow.'' -Linus Torvalds

--ajs.

[Xx*SaturnineMatthias*xX]

HappyFoppy, on Feb 15 2007, 05:51 PM, said:

How about changing the MOVE PLAYER [dir] command to MOVE PLAYER "[dirs]" Just like the / command. It'd save a lot of loop commands.

set "move_player" "direction string"?

[nooodl]

Embedding loop commands. I dunno if this is possible but I'd like to make it work like this:

loop start
loop start
inc "a" 1
wait 1
loop for 10
inc "b" 1
wait 1
loop for 5

The red parts is the 'outer' loop and the normal part the 'embedded' loop.

*waits for comment saying this is impossible blah blah*

[Terryn]

Use subroutines instead. Same functionality.

[hob nado]

Yeah, MZX loops are a bit weak. You could always use subs like Terryn suggested, or just labels and gotos.

[nooodl]

Waaait, is this thread for _completely_ new things only? I mean like someone could come up with 1 command that takes 50 lines of coding, but then the batch of commands would get even more stuffed.

[Goshi]

Esdemo1, on Feb 20 2007, 08:39 AM, said:

* Remove the title line from the default textbox

. "@ "

And when you want the robot's name back

. "@ROBOT"

I totally agree with Es' suggestion though.

[CJA]

loop start
set "local" to "loopcount"
loop start
inc "a" 1
wait 1
loop for 10
set "loopcount" to "local"
inc "b" 1
wait 1
loop for 5

This post has been edited by CJA: 22 February 2007 - 12:13 AM

[Xx*SaturnineMatthias*xX]

and now for a sensible feature request (unless this is already available but not obvious)

...the ability to send a path to a MZX game as an argument to MegaZeux, which would then open it (for example megazeux /home/mattwin/mzx/caverns.mzx). Not sure if this would work the same way, but the ability to open MZX files from the file manager after MegaZeux has been registered as the progam to use would be cool too.

[ajs]

This feature is already planned for 'g'.

--ajs.

[nooodl]

I know this might never be added, but...

Regular Expressions in string match stuff. *runs for Exo*

[paulguy]

can't you already do

megazeux startup_world=/path/to/world

??

[Xx*SaturnineMatthias*xX]

paulguy119, on Mar 10 2007, 08:41 PM, said:

can't you already do

megazeux startup_world=/path/to/world

??

whether you can or not, it'd be better if MegaZeux could load the world given to it in stdin etc.

[CJA]

A way to let us set the current mod to * without stopping what's playing on that same board (Kind of ruins the rule of *, don't you think)

[hob nado]

Esdemo1, on Feb 19 2007, 04:39 PM, said:

Some ideas I had for options we could provide:

* Resize the default textbox
* Reposition the default textbox...

[etc. etc.]

Prepare for a "duh" moment =)

Textboxes can't be sizable after all. I started working on these features today and ran into a problem that we all apparently forgot about: Since MZX does not do word wrapping in textboxes (and given the way it is, arguably shouldn't) - any time you want to make your game's textboxes smaller, you'll hose all the text you've already written and formatted for the bigger size boxes.

So that pretty much seals the fate of this idea. Oh well.

Edit: Lancer brought up a good point on IRC that you could still resize them vertically, which would be about 50% useful, I suppose. I dunno, though, without the horizontal resizing too I think it'd feel a bit off.

[GetDizzy]

I'd still use it if you could vertically resize and reposition.

[ajs]

Esdemo1, on Mar 23 2007, 06:56 AM, said:

Textboxes can't be sizable after all. I started working on these features today and ran into a problem that we all apparently forgot about: Since MZX does not do word wrapping in textboxes (and given the way it is, arguably shouldn't) - any time you want to make your game's textboxes smaller, you'll hose all the text you've already written and formatted for the bigger size boxes.

That's true, but surely part of the feature is a stylistic element for your game. You shouldn't have to "reformat" anything if you just set the text box size BEFORE you add text, and then add text with the appropriate line length.

It's not as if the user can change the textbox size at runtime, so I still think the feature could be usable.

--ajs.

[RoSS]

Yeah, I agree with ajs here. It won't cause any legacy problems if the default size stays the same. The addition of resizing could potentially be useful; although admittingly a lot of people don't use the [ text box that much these days anyway. Still, it would probably be pretty easy to do.

[Koji]

could someone please fix it so that if you send a robot to a subroutine lable, the robot treats it like a SUBROUTINE, and not just a normal lable

IE

robot1:
:"lol"
* "Blah"
wait 1
clear mesg
goto "lol"
:"#lol"
* "lol subroutine"
wait 10
goto "#return"
* "Wait... WTF?"

Robot 2:
wait 10
sent "robot 1" to "#lol"

test it out... robot 1 will fuck up, when it shouldn't!

The easy fix here is that when you send a robot to a lable, there is a routine outside of the robotic handler that handles sends and repositions the robot to the lable it was sent too, all we'd need to do was add a small chunk of code that would make the send lable advance down the subroutine stack of the robot if the lable had a # preceeding it.

Right now it's the only suverely lacking feature in subroutine handling. IT BREAKS THINGS.

This post has been edited by Koji: 23 March 2007 - 06:24 PM

[Spectere]

I think all that would do is result in an unpredictable code path. There's absolutely no way of telling where #return would take the IP which, I think, could cause a ton of strange programming bugs.

If you really want to do something like that, just set a counter, like this:

. "Robot 1"

:"lol"
* "Blah"
if "r1_dosub" = 1 "#lol"
wait 1
clear mesg
goto "lol"
:"#lol"
* "lol subroutine"
set "r1_dosub" "0"
wait 10
goto "#return"

. "Robot 2"

wait 10
set "r1_dosub" "1"

Not only would it work without question in the current release but it also provides a way of knowing EXACTLY where the code is going to branch, rather than letting MegaZeux sort it all out.

This post has been edited by Spectere: 23 March 2007 - 08:17 PM

[RoSS]

Well you would want #return to go to wherever it was when it stopped, which doesn't seem like that big a deal since it should almost always be a wait (otherwise it'll be unpredictable anyway!). The only issue I can see arising is making sure that if you stop 5 cycles into a wait 10, you should only wait 5 more when you get back to the line. As long as you don't use any variables in the subrountine that you don't want affected outside of the subrountine then you should be fine =P

[Wervyn]

As far as I can tell, this works just fine. Koji's code does exactly what you would expect it to do, no problems at all. I can't get it to print the error code. Really, the only major subroutine issue I can think of is that it doesn't really know how to treat atomic commands that take more than one cycle to complete, like waits or movement strings. I don't know what's wrong for Koji, but I can't replicate the problem.

"Violence AND sex! Something for everyone!"

[Dr Lancer-X]

I know the feature in question works fine, because I have used it many times in the past. You horribly misdiagnosed the problem.