[T-Bone]

Yah.... I use sprites quite a lot and have a couple rather large ones... however I would never need any larger than 255 x 255. Anything that big would be considered an overlay to an entire stage. If I were to do that I would compose that with various sprites blocked together.

[Lachesis]

T-bone: level-encompassing sprites for parallax or etc., though you should just be able to make those screen width and have their refx move

Anyway, fixing the infinite ASK loop is easy: when you're holding ESC, make the "Quit playing?" prompt ignore ESC key presses until the user releases ESC. My interfaces IN MZX have been doing things like this for years

of course this depends on my memory being correct about holding ESC when stuck in a message box loop bringing up the Quit playing? prompt

This post has been edited by Lachesis: 10 June 2011 - 07:33 PM

[zzo38]

Another possibility, is that in testing mode, check for events every 10000 commands or whatever in Robotic codes, and make the keyboard handler check for some keys (perhaps using CTRL+BREAK) to set some global flag to tell it to terminate message box loops and robotic command loops and that stuff

[T-Bone]

I like both ideas. Also what happens if you hit ESC during an ASK command? Does it go to the label "no" or does it just go to the next line of code under the ask command? I'm at work so I can't test this. Be nice if prompts could be layered. Like if an ASK command is prompted, the player can either press yes or no to do their various actions AND if he presses ESC, rather than exiting the ASK command... it will open up the quit game prompt on top of the ask command. I think that would be a perfect fix.

I actually like both ideas you guys mentioned as well. Control and Break as also far away from eachother on the keyboard... we be rare that they would accidentally get hit together.

Lachesis, idea is good too. You mean so like if I'm holding ESC and the quit box appears i could hit yes while holding ESC?

This post has been edited by T-Bone: 10 June 2011 - 09:20 PM

[Dr Lancer-X]

T-Bone, on 11 June 2011 - 07:17 AM, said:

I like both ideas. Also what happens if you hit ESC during an ASK command? Does it go to the label "no" or does it just go to the next line of code under the ask command?

It jumps to the 'no' label. Anyway, this still has the problem of it not being easy to get out of a deeply nested game loop. The cleanest thing I can think of is to use setjmp/longjmp to set an exit point on testing and jump to it if an abort sequence is typed at any event loop.

[Old-Sckool]

Why not re-map all of ESC's in-game functionality to a different key

[Lachesis]

Name a key combo that MZX doesn't already use or isn't a system key combination on various OSes and that isn't a pain in the ass (no CTRL+ALT+SHIFT+TAB+F12)

This doesn't fix the issue, anyway, it just means you'd have to hold down a different key to attempt to break from the infinite menus. The issue that needs fixing is the ESC menu's rather stupid behavior of closing immediately when you press ESC (defeats the purpose in situations like this). I'd have it delay paying attention to ESC keypresses until it's sure the repeat delay is over, and then wait until it's sure ESC has been released before allowing ESC to actually do anything. Alternatively, don't let ESC close the ESC menu at all

As for busyloops, implement the above fix and additionally cap COMMANDS at 20,000,000 or something. For most people, any settings higher than this will be like waiting a cycle or more anyway

[Dr Lancer-X]

I disagree about capping COMMANDS. If people want to use the high value, fine, it's no biggie to just kill MegaZeux's process if you screw up.

[Lachesis]

What if someone else screws up and then releases it

edit: I'm not sure that's ever happened to me, most of the unescapable busyloops I run into when playing other peoples' games are due to MZX bugs

This post has been edited by Lachesis: 15 June 2011 - 04:09 AM

[Dr Lancer-X]

That's only really happened once, and it was worse because it was an infinite series of inter-board 'teleport player' commands - it was in a DoZ a few years back.

[Lachesis]

I'll say one thing in favor of ridiculously high commands, though: I stopped making busyloops! and started adding failsafes to places I thought would get busylooped

[Jeep Dragon]

Has someone already suggested a board option to allow a board to be restored to its original state every time the player reenters? I know that one can use the :justentered label on robots or probably load board files. It would be nice to be able to have that feature without requiring any coding.

[Dr Lancer-X]

That would be a useful feature, actually, since it has plenty of legitimate applications and perfectly restoring a board to its former state is not necessarily trivial.

[Lachesis]

Request thirded, sounds like something I'd use.

[T-Bone]

Lachesis, on 14 June 2011 - 10:40 PM, said:

Alternatively, don't let ESC close the ESC menu at all

That's what I've been trying to say... this is a must! If ESC opens the quit menu... why does the same key close it? Its annoying lol

[Dr Lancer-X]

I like ESC closing the quit dialog because it makes it instant and easy to close (plus it's what I'm used to anyway)

My suggestion is to require pressing ESC to close the quit dialogue - i.e. it won't close if you're holding ESC down

[Lachesis]

Well, that's what I originally said but it got ignored

[Dr Lancer-X]

it's okay, all the suggestions posted in this thread are ignored

[Lachesis]

I know :(

[smilymzx]

This should be in another version of MZX:

- Fix the bug where Sharks and Fish do not go around in goop

The following should be done as a additional MZX element:

Centipedes: another base off ZZT, Hard to make in robotics!**


** I think that since Lyon is coming to windows with source code, that I must not do MZX anymore if it is not going to happen, but I (or we) can take it and fork it as much,

[Baby Bonnie Hood]

I can't remember if sharks used to be able to move in goop or not. There are games that have sharks sitting in goop immobile, so I'm puzzled.

[Terryn]

BUG TRACKER

The aforementioned shark goop bug has already been noted and fixed. Fish didn't move in goop beforehand, so that's not going to be addressed.

[smilymzx]

Terryn, on 25 June 2011 - 06:12 PM, said:

The aforementioned shark goop bug has already been noted and fixed. Fish didn't move in goop beforehand, so that's not going to be addressed.

Ok, So Testing it right now

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!

That is all,

[Lachesis]

I have a feeling that if Labrynth of Zeux can be simulated in Robotic, then ZZT should be able to be simulated as well. Look, SaxxonPike just did all of the work for you, already! All you have to do is convert it from VB to Robotic :p

edit: The flaw of every single robotic implementation of centipedes to date is that everybody tries to make them physically robot-based. A single off-screen controller robot with overlay-rendered segments would at least be able to interact with terrain (default bullets would pass through unless you feel like littering the ground with spaces, but why are you using default bullets), the player, and other robot-based enemies. You'd assign each segment to part of a chain at runtime and process segments from the start of the chain downward every cycle, breaking the chain when the player walks into it or shoots it.

edit 2: on second thought, you might be able to hack in default bullet interaction by dumping non-mobile single-shot built-in enemies beneath the segments and checking for their presence the next cycle, but I don't know how well this would work in practice.

This post has been edited by Lachesis: 26 June 2011 - 07:54 AM

[Old-Sckool]

Why the hell is there no local counter to fetch a robot's name? This would make it very easy to be able to write a reusable script to fetch a robot's resources.

[Lachesis]

ROBOT_NAME. Doesn't work with Rn.<counter> but you can't get n without the robot's name anyway unless you're

1) Storing it in a global counter or something, but then you could just store the name in a global string too
2) Iterating through robot IDs, and in that case you should probably be storing the objects in memory and iterating through them in a single controller robot.

Please read the robotic manual before posting requests

--POINT OF ADVICE--
Requests work better when you aren't like "WHY THE HELL ISN'T IT THE WAY I WANT IT TO BE I'M ENTITLED HERE"

This post has been edited by Lachesis: 16 July 2011 - 04:58 AM

[Old-Sckool]

Lachesis, on 16 July 2011 - 12:49 AM, said:

Please read the robotic manual before posting requests

fffffff¹²

I didn't notice it, as it was listed under string counters and #mzx is dead.

[Lachesis]

The way the String Counters section is set up seems a bit questionable to me, too. I think there should at least be stubs linking to String Counters in the relevant sections

[Lachesis]

File subdirectory counters:

mod "music/basket.mod"

. "ugly"
set "$MUSIC" "music/"
mod "&$MUSIC&basket.mod"

set "MOD_PATH" "music/"
mod "basket.mod"

set "MOD_PATH" "&$userDefinedSoundtrack&"
mod "basket.mod"

[Dr Lancer-X]

Why do we need a counter that saves you.. 0 lines of code?