[T-Bone]

Hey guys been a while since I asked a question here in reference to robotics. Guess im starting to forget a few things.

So here is my problem, I'm trying to use an IF command with two counters to detect if they equal unique values and if that is true to go to a given label. For instance here is what I'm trying to do (that obviously doesn't work):

If "('Counter1'=7 and 'counter2'=3)" = 1 "youdidit"

What is the proper way of doing this?

[ThDPro]

T-Bone, on 28 February 2015 - 01:47 AM, said:

If "('Counter1'=7 and 'counter2'=3)" = 1 "youdidit"

What is the proper way of doing this?

if "(('counter1'=7)a('counter2'=3))" = 1 "youdidit"

[T-Bone]

Perfect! Thanks

[Otto Germain]

Huh.

Well I learned something new today.

[Graham]

You guys may be interested in checking out the tutorial I did on expressions a little while back. YouTube Tutorial on Expressions It explains this concept in detail plus a few more. My game uses expressions like this:

if "((('&$butpress&&_action2&'=1)a('&$butpress&&_up&'=0)a('a_hover'>0)a('rocket'=0)a('roll'=0)a('falling'=0)a('jump'=0))a(('&$butpress&&_left&'=1)o('&$butpress&&_right&'=1)))" = 1 then "top2"

Which means if the action button is pressed & the up button is not pressed & servo has the hover ability & servo is not using the rocket ability & servo is not using the roll ability & servo is not falling & servo is not jumping & the left button or the right button is pressed, then goto "top2"

Without these expressions Servo wouldn't be possible, there are just to many variables to account for with all of these different abilities.

I learned how to use expressions from the MZX-Wiki article on them: MZX- Wiki, on Expressions

[Old-Sckool]

heh... butpress

I'm curious to know why your button variables are of the form '&$butpress&&_left&' rather than a simple 'left_pressed'

This post has been edited by Old-Sckool: 01 March 2015 - 09:55 AM

[GetDizzy]

Likely so that keys can be globally rebindable. I've used similar before (though I think it was Alice's code)

[Dr Lancer-X]

i presume old-sckool meant why they were named in such a way, with two parts of the variable name controlled by other variables ($butpress and _left) rather than just using a straight counter, which would be just as rebindable. i'm assuming there's a deeper abstraction taking place here

[T-Bone]

Its funny how using expressions can save you dozens of lines of code. Lots of robots to go back and optimize lol

[Graham]

Old-Sckool, on 01 March 2015 - 01:55 AM, said:

heh... butpress

I'm curious to know why your button variables are of the form '&$butpress&&_left&' rather than a simple 'left_pressed'

Like Lancer & Insidious said. I mostly did it like this for cutscenes. During normal gameplay, "$butpress" is set to "key" and "_left" is set to whatever number the player wants left to be. During a cutscene however, simply setting "$butpress" to anything else, say "control", and the player loses control of the robot. Then a script can be run that sets "control&_left&" to 1 until Servo reaches a desired X position, at which point "control&_left&" is returned to 0 and he stops walking.

This post has been edited by Graham: 01 March 2015 - 03:56 PM

[Dr Lancer-X]

Ah, fair enough. The only issue I can see with that is that you're restricted to mapping only one key per input-- but of course if you change your mind you can just change $butpress to something else when the player is in control and write to those counters based on input.

[T-Bone]

Would the following work?

if "(('mboardx'=<23)a('mboardy'=<13))" = 1 then "scene"

With equal more or less than... in each contained expression?

[ThDPro]

T-Bone, on 04 March 2015 - 01:24 AM, said:

Would the following work?

if "(('mboardx'=<23)a('mboardy'=<13))" = 1 then "scene"

With equal more or less than... in each contained expression?

Yes, but <= not =<

[T-Bone]

Thanks! Very helpful. Can't express how much work I got ahead of me changing my robotics throughout all my games. So many label jumps just to conduct one system of expressions.

I'm also going to give Graham's video a look.

This post has been edited by T-Bone: 04 March 2015 - 07:19 PM

[ThDPro]

I feel like this is something that should be more made to be more obvious in robotic. I mean, it's there in the help file (and more importantly for some people, the wiki), but that only does so much. It's not the slightest bit intuitive to expect there to even be a thing that does what binary operators do, especially for someone new to mzx, or even OLD to mzx who got used to not having something that did that. I mean, I only realized you could do this after making some five games.

On the note of things not being intuitive, there's a whack of things like this. Subfolder access comes to mind, along with that, reading folder contents. Just a couple days ago, mzxrules of all people asked IRC how to read the contents of the root folder, and I basically just took a few educated guesses into a robot to eventually get

set "./" "fread_open"

I'm sure someone else knew that this was the case, but how are we (those who didn't develop the current version(or are lancer-x)) supposed to know that? Is it in the wiki? (just check, I don't think so)

I guess what I'm saying that we kinda need a new mzx encyclopedia...? I dunno what I'm saying really. I just wish it were more approachable on the whole.




Huh, just found this in the help file while digging through for refernce to directories, doesn't even matter a little bit, thought I'd mention it for blahblahblah reasons.

Quote

"&SHOT.WAV&6F#_+C-C"

The above will play SHOT.WAV at 48KHz (F-sharp, 6th octave)
if digitized sound is on, OTHERWISE it will play the normal
shooting sound of "+C-C".

I think that's supposed to be 4.8kHZ, what with us not being able to hear above 20kHZ.

[Graham]

My policy lately is, when I discover a shortcut or more efficient way of doing something, I utilize it going forward. I don't go back and redo something that works fine, unless it's causing a problem. I'd rather not spend time redoing something that already works when I could be working on the next leg of the project.

Maybe the code you've done is causing lag or is buggy and cleaning it up would help, or maybe it's not a huge burden to fix (although it sounds like it is). But if being a perfectionist is going to slow you down and delay the project, is it really worth it?

Edit:had to read what I wrote to realize I'm full of it. This is my new policy. Haha

This post has been edited by Graham: 04 March 2015 - 08:09 PM

[ThDPro]

Graham, on 04 March 2015 - 12:05 PM, said:

My policy has always been, when I discover a shortcut or more efficient way of doing something, I utilize it going forward. I don't go back and redo something that works fine, unless it's causing a problem. I'd rather not spend time redoing something that already works when I could be working on the next leg of the project.

Maybe the code you've done is causing lag or is buggy and cleaning it up would help, or maybe it's not a huge burden to fix (although it sounds like it is). But if being a perfectionist is going to slow you down and delay the project, is it really worth it?

Totally agree. I would never advocate redoing working code unless... well, those things you said. Furthermore, I'd never advocate perfectionism in MegaZeux, cause part of the fun for me at least is finding a way to make imperfection seem good, or at least good enough.

Mostly, I said that because I am certain that every single mzxer has had that moment where they learn a new thing and think to themselves, "Hours... DAYS of work... That I could have done with a single line in 2 minutes.... So much wasted time..."


Redoing code after you've gotten it to work seems pretty silly to me as well, I can't say as I've ever done that when it wasn't entirely necessary. Sometimes I didn't even do it when it WAS. Domination comes to mind.

EDIT: Bwahhahah!

This post has been edited by ThDPro: 04 March 2015 - 08:23 PM

[T-Bone]

Quote

Maybe the code you've done is causing lag or is buggy and cleaning it up would help

Precisely and I'm already discovering how to fix several bugs with just compounded expressions. It also just makes everything a lot more neater and easier to find. Won't be fixing all past games, just the ones that still contain bugs and require improvements.

Using expressions with sprite counters... has been of unimaginable help.

This post has been edited by T-Bone: 05 March 2015 - 01:31 AM

[Old-Sckool]

I don't think a new mzx encyclopedia is necessary. freading directories is a relatively new mzx feature (2.84), and it was just a small oversight on lach or whoever wrote up the documentation.

If it really bothers you, update the wiki

[ThDPro]

Old-Sckool, on 05 March 2015 - 12:38 PM, said:

I don't think a new mzx encyclopedia is necessary. freading directories is a relatively new mzx feature (2.84), and it was just a small oversight on lach or whoever wrote up the documentation.

If it really bothers you, update the wiki

heh, that's the problem, it doesn't bother me, or anyone else cause we already know most of these weird ass eccentricities of mzx. for someone to actually learn these things, they would have to look into other people's code, and I've seen some of our Robotic nightmares... They 'aint exactly reader friendly. I can't remember the last time I saw KKairos actually comment something.... Or myself for that matter.

OH RIGHT! another good example of things no one would know given the help menu is the trick where you set something like

change char id 20 "(255)"

to make stillwater any char you want while it keeps its environmental properties. I think lache taught me that like 3 years ago, and I still use it all the time.

[Graham]

this is reminding me of a discussion from when I first joined the community in 2012. It was about how to make MegaZeux more attractive to new users (or less likely to scare them off). I can't find the tread now but it focused on making things easier to find and learn, lessening the learning curve. It's what prompted me to start doing the video tutorials on YouTube. I've also read the entire help file and virtually every MZXWiki entry. I think I'm more proactive than most people are willing to be, but the resources are there. The answers to all questions are there, but some you have to look carefully to find. But maybe it does need to be easier, I mean MegaZeux has gotten more complex over the years. Well, you can still start at the same simple point we did years ago. Now you can go do many more things than we could in the beginning though. And newer users don't have the advantage of having new things added slowly over the last two decades, like most of us. I remember when a new version would come out before the help file was updated regularly and my primary way to stay abreast of changes was to read the included update log. Okay, I've rambled long enough. I just wonder what else can be done to make usability better, make the learning curve not as steep. Do the videos help? Not for most of you, obviously, many of you are more experienced than I am. But do they help new users?

[Dr Lancer-X]

i feel like i had the advantage of being pretty involved with development, although i rarely did any myself, but i basically got introduced to stuff as it was added and i had a good idea of the motivations behind the new features and how they were intended to be used etc. which helped a lot. honestly pretty much the only feature i ever managed to miss was spr#_swap. i wasn't the only one though!

the other side of knowing what mzx has is how to use it effectively, and that's something that can only be gained through experience. thankfully i was good at starting projects and having them die, which meant i coded fundamental engines many many times and with practice got better ideas of how certain things should be done. if you look at modern shooty games i've worked on (the TIs, nt(n), termination, taoyarin, ataraxia etc.) in the order of their development, there's a bunch of common concepts (sprite enemies, projectile engines etc.) that appear in all of them and as a result i've had a lot of time to refine the basic approaches behind those, and where the typical trouble spots are (e.g. deleting projectiles) and how to avoid problems caused by them. shooty stuff doesn't appeal to me as much as it used to-- i think i'm still on an rpg binge and i'll need to make at least one more game to get that out of my system.

what i'd like to see is more developer postmortems. you've learned lessons in the development of your game, so now that you've finished a game, why not get it off your chest with a postmortem thread, because some of this information could be usable by other people. i should write more myself. i made an attempt with the red postmortem thread, although i think there was actually a ton of stuff i wanted to go over but forgot by the time i finished.

[Graham]

Lancer-X, on 05 March 2015 - 02:37 PM, said:

the other side of knowing what mzx has is how to use it effectively, and that's something that can only be gained through experience. thankfully i was good at starting projects and having them die, which meant i coded fundamental engines many many times and with practice got better ideas of how certain things should be done.

Ditto, I mean I started a lot of projects that died. I feel like all of them have been in preparation for the game I'm making now. They've always been a variation on basically the same game, refined more with every iteration. The difference being, I've yet to complete a game.

Quote

what i'd like to see is more developer postmortems. you've learned lessons in the development of your game, so now that you've finished a game, why not get it off your chest with a postmortem thread, because some of this information could be usable by other people. i should write more myself. i made an attempt with the red postmortem thread, although i think there was actually a ton of stuff i wanted to go over but forgot by the time i finished.

Postmortems are a great idea! I was thinking about doing some similar stuff, but like you said, while it's still fresh in my head. Once I've finished explaining the basic systems of MegaZeux in the tutorials, Sprites, strings, subroutines, SuperMZX modes, files access, etc. I thought I'd try to explain some different game design theory stuff, using my game as an example. So those could include debugging, building a complex engine, good game design vs bad, the order of execution of code (reverse send and the like) and how to set up a sprite based side scroller.

[CJA]

Lancer-X, on 05 March 2015 - 05:37 PM, said:

what i'd like to see is more developer postmortems. you've learned lessons in the development of your game, so now that you've finished a game, why not get it off your chest with a postmortem thread, because some of this information could be usable by other people. i should write more myself. i made an attempt with the red postmortem thread, although i think there was actually a ton of stuff i wanted to go over but forgot by the time i finished.

I really liked your red postmortem and thought it was a stellar idea. There are a bunch of reasons why I like it, such as...

We can see where you're at when making the game. Those that can't express themselves as well in MZX can often feel intimidated after playing games like this. By sort of being on the level and real about what you did and why you did it, the developer can seem a lot less like a wizard and a lot more like a person that has just spent some time learning how MZX works and also general programming practices.

Another good thing is, well, what I just said: general programming practices. It's really great that we get to discuss algorithms that were used in different parts of the game. The kitschy MZX hacks are awesome to talk about, as are general CS algorithms and how they apply in a MZX environment. It's also nice to remember that the things from the "real world" of development apply to MZX development.

This is probably the same as the first reason, but it sort of demystifies the connection between the game and the amount of prowess needed to do something like this. Simple things, like talking about how you started and what inspired you, can become inspirations themselves.

Finally, it's going to be something great for YOU to look back on, probably!

[T-Bone]

I was actually going to start doing small tutorials on how to achieve better graphics with MegaZeux many moons ago but that was actually before the other colour modes came out with MZX. Once that happened I felt there was no longer a need to teach people how to optically trick people into seeing more colours than you were actually limited with.

[Dr Lancer-X]

T-Bone, on 06 March 2015 - 05:04 PM, said:

I was actually going to start doing small tutorials on how to achieve better graphics with MegaZeux many moons ago but that was actually before the other colour modes came out with MZX. Once that happened I felt there was no longer a need to teach people how to optically trick people into seeing more colours than you were actually limited with.

i dunno, i think they could still be useful. smzx limits you in other ways and that clean mzx look is hard to beat. your stuff looks pretty great and i'd be interested in seeing the techniques you use

[T-Bone]

I actually still have a notepad floating around for all the key areas I had intended to cover. I just also couldn't figure out which medium to present them in. Document, MZX File or video.

Quote

Once I've finished explaining the basic systems of MegaZeux in the tutorials, Sprites, strings, subroutines, SuperMZX modes, files access, etc. I thought I'd try to explain some different game design theory stuff, using my game as an example.

I would be really interested in this.

This post has been edited by T-Bone: 06 March 2015 - 07:49 AM

[Graham]

T-Bone, on 05 March 2015 - 11:48 PM, said:

I would be really interested in this.

Great! I've done two videos on sprites. I have to do another one or two more, then I will release them all at once. The videos are coming along. Have you looked at the video on expressions yet?