[ajs]

About a year ago, Exophase rejoined MegaZeux development to start evolving robotic and the robot editor. You can see his proposal and outlined plan here. Due to time constraints/external factors this work was paused around three months later. Much work was done however, with phase 1 of the plan more or less completed. Some high quality documentation was also written and many details worked out. (The name of the source branch this work went into was 'debytecode'; this is the codename being used to refer to these changes.)

I've decided to revive this work and continue development of it as much as I can. What we need right now are people to download an alpha-quality version of MegaZeux, with the changes, and play around with it. Solid bug reports and good feedback on the changes is important. Most of the language changes aren't documented in MZX itself (the help file will require some revision eventually). "Legacy" worlds will be converted to the new syntax on load, which will allow you to experiment with all the various transformations. At the moment the 'debytecode' and 'trunk' builds are totally isolated (though they share the same code base); I do not have any immediate plans to change this.

You can download builds for your favourite platform (except, temporarily, OS X) from here:

http://mzx.devzero.co.uk/snapshots/debytec...240600-978e8ab/

Moving forward I plan to look at the other design phases and continue development. Future changes will inevitably lead to language alterations which will be incompatible with this alpha. Compatibility may or may not be retained, at my discretion. IOW, you probably shouldn't create any epic games using this alpha build. This build will not allow new worlds to be saved over any legacy world with the same name, which should prevent possible accidents.

I hope people will try it out and feed back on this thread. If you find a game that doesn't play correctly in this version, please file a report on the bug tracker. Additionally, if MZX crashes, or you find a bug in the new editor, please also file a bug.

--ajs.

[Maxim]

Much as I like robotic as it is, I'll give this a try and see if I can help at all, with my limited skillset. The thing is, I feel that evolving robotic/the editor to make it more traditional will eliminate any excuses that people have for not making MZX games (lookin' at you, Frobozz).

Thanks again for all you do, AJS

[ajs]

BTW I bumped the release from 1632 to 1634 because I fixed a bug with SFX tables and found a crash affecting some platforms when testing a world from the editor.

This version 1634 will also support updating on the 'debytecode' line with F7/U for as long as the branch is developed.

(For older builds you can switch to this branch with branch pin "Debytecode" (caps are important) and update server updates.mzx.devzero.co.uk)

--ajs.

[Exophase]

That SFX table bug sounds very familiar, like something I forgot to fix back then. D'oh.

At any rate, this should be interesting. :a

[nooodl]

I think mzx_speed got screwed up...? It's not doing anything over here, be it by setting it with a robot or in the F2 menu.

Anyways, this looks pretty swell. (When do I use (variable) vs. <variable>? What are their old-Robotic equivalents? Parentheses look neater.)

[Old-Sckool]

Noodle, (counter) vs. <$string>. Incidentally, if you use ($string), mzx will treat the string as if it has a string literal numerical value. For example, if $string = `622fagz`, then * "($string)" would output 622 instead of 622fagz

Edit: setting mzx_speed works fine for me in 1634

This post has been edited by Old-Sckool: 28 January 2010 - 08:43 PM

[Seventh Shade]

"MZM3s saved at runtime and loaded at "static" time have robots dummied out to customblocks."

If I have a game in the current version loading mzms with robots in them, will they work in the new form of robotic or will it be incompatible?

[Exophase]

Seventh Shade, on Feb 3 2010, 09:29 PM, said:

"MZM3s saved at runtime and loaded at "static" time have robots dummied out to customblocks."

If I have a game in the current version loading mzms with robots in them, will they work in the new form of robotic or will it be incompatible?

Not necessarily, the incompatibility mentioned is limited to loading MZMs which were created while the game was running. I think that "static" time here means either loaded in the editor or loaded to the board with that flag that converts everything to customblocks anyway. So you shouldn't have a problem unless you really wanted to modify those robots. I THINK I made it so you can load them in-game, so you can make a .mzx that loads then saves them.

Could you show some more context from where I said that? It has really been a while >_>

[Dr Lancer-X]

Yeah, that's what it means. Saving MZMs with robots ingame and then loading them in the editor - because the ones saved in-game will not have source code, whereas robots in the robot editor must have source code.

[Maxim]

Tested all of my games in experimental debytecode version. So far only "Fist Full of Entrails" is broken. For whatever reason, enemies get assigned a negative HP and movement delay value. I can't figure out why.

So far this is totally awesome, otherwise. I love how everything has different colors, very good for instant recognition.

[ajs]

I'll take a look at this.

--ajs.

[Maxim]

11:05 <@Wervyn> It doesn't seem to even be getting inside the enemy movement
code. Also this is really terrible.
11:09 < Stephen> it's very badly designed
11:09 < Stephen> i don't know why i did half this shit
11:10 < Stephen> if `(local)e_dmg` > 0 then `enemy-dmg`
11:10 < Stephen> that's where it breaks, i think
11:10 < Stephen> enemy hp just constantly decreases
11:10 < Stephen> without killing the enemy
11:14 <@Wervyn> Yeah.
11:14 <@Wervyn> It's also decreasing the enemy damage by the enemy number each
time.
11:14 <@Wervyn> Somehow numbers are getting crossed.
11:15 <@Wervyn> It's doing the same to the delay.
11:15 <@Wervyn> Or, always going to the delay routine.
11:16 < Stephen> the coding here is a mess, but the program really should be
working by all means
11:16 <@Wervyn> Yes.
11:16 <@Wervyn> I wonder if it has anything to do with using counters like
"8something", which is just...ugh.

*********************

11:25 <@Wervyn> This is really bizarre.
11:25 <@Wervyn> There's no reason it should be behaving like this, and I can't
reproduce a controlled test case.
11:26 < Stephen_> yeah, i tried too
11:26 <@Wervyn> Basically, it's taking the branch every time, but the
conditions are such that it shouldn't.
11:26 <@Wervyn> And whenever I try to transplant that into a test case, it
behaves as it should.

[Exophase]

What was the line in the original robot?

I think this is pretty straightforward: it thinks it's a top-level expression instead of an interpolation. I have to look at the current parsing code to see if there's any handling for this. MZX originally was probably not okay with starting with an interpolation either, but since it was probably originally a && that got converted it would have been OK. If this proves thorny to handle at runtime then maybe these should be escaped. There's some residual compatibility concern from not escaping counters whose names can't be determined to start with counter interpolants or numbers, but I believe there are already some translation issues along these lines that are probably not a big deal.

[Maxim]

UPDATE: Yep. That's what it was.

13:43 <@Wervyn> Okay, figured it out.
13:43 < Stephen> ooh
13:43 <@Wervyn> Or at least, I have a test case now.
13:43 < Stephen> where's it broken?
13:43 <@Wervyn> It's the counter leading the array name.
13:44 < Stephen> why, oh why did i do that
13:44 < Stephen> i mean, i'm sure it'll get fixed, but
13:44 <@Wervyn> No idea, but it's probably good that you did, because it IS a
bug and it SHOULD work.

*******************

set local 5
set `(local)test` 14
:L
if `(local)test` < 0 trigger
wait 1
*"(`(local)test`)"
dec `(local)test` 1
goto L
:trigger
*"Done"
end

13:49 <@Wervyn> Here's some test code.

[Wervyn]

This discussion should really be in the bug tracker. So I put it there. Going to test this case in current MZX now.

"Dance you fool."

[ajs]

Should be fixed in SVN 1637.

EDIT: Fixed it better in 1638. See the bug tracker for commentary, see if you agree with the fix.

--ajs.

[Exophase]

I'll review the changes when I get home too, wanna see what the parser was doing with this.

[ajs]

Bumped release again for bugfixes (inc issue Maxim found).

--ajs.

[Lachesis]

edit: The .deb files in the debytecode folders do not install debytecode. They are just installing normal MZX for me.

[ajs]

Yes, good catch. Although the nightly build script was setting CONFIG_FLAGS (which all other builds use to turn on debytecode), "debuild" (which is used to build the .deb files) was not using CONFIG_FLAGS in the rules script. Additionally, the build script wasn't telling debuild to pass this through from the environment.

Fixed in Git cf3d1c9. I manually kicked the build and fixed binaries are here:
http://mzx.devzero.c...cf3d1c9/ubuntu/

--ajs.

[Lachesis]

Awesome, thanks. I'll try that out when I have my netbook open again.

Also:
18:12:55 <Lachesis> the colors need a little work tho
18:13:06 <Lachesis> like, dark green for labels makes me think of vomit
18:14:51 <Lachesis> um, hey guise
18:15:03 <Lachesis> why are parameters yellow
18:15:12 <Lachesis> Yellow, the second most readable color in the editor
18:15:17 <Lachesis> and you wasted it on parameters
18:15:26 <Lachesis> there's a reason why parameters used to have vomit green

Could the defaults for those be switched before official release

edit: now I see that yellow is in fact used for other things too. My opinion hasn't changed though, the labels should have a more readable color as a default
edit 2: or the editor background should become dark blue
edit 3: ooooohhhhh boy, this crashes trying to load Labyrinth or CoAZ

This post has been edited by Lachesis: 11 December 2010 - 01:26 AM

[nooodl]

What changed since the last debytecode update? How far is this from actually being used to make games? I'd love to use it this DoZ (if i'm even participating hmm)

[Terryn]

If you're talking about the current GIT versions of debytecode, a few major hangs and large bugs specific to debytecode were fixed (e.g. nesting sound effects, expression parsing), on top of the twenty-odd bugfixes that will be in normal 2.82b. I think ajs is planning on getting a new MZX out for the DoZ.

This will be pretty far from being used to make games if you guys never test it :< GET CRACKALACKIN'

[Lachesis]

I already suggested on IRC that we have a QDoZ or a HDoZ with Debytecode, in February.

[nooodl]

The main problem with this is that the parser seems to be more anal about what brackets you use where. Maybe it's just something I'll have to get used to, but it's really awful to be coding something and wondering why your line isn't recognized as a correct one, only to find out later on that you forgot to put backticks around a variable name or used parentheses wrong.

EDIT: also, there's no documentation, right? Importing pre-debytecode Robotic seems to be the only way to find out how things work.

This post has been edited by nooodl: 13 December 2010 - 04:42 PM

[ajs]

Could you give some examples of where bracketing is actually more complicated in debytecode? (I know of some, but they seem like edge cases to me.)

Remember that in the old editor there was no expression validation at all. If your expression was wrong, nothing told you about it until your program failed at runtime. Now you don't get syntax highlighting when the expression is incorrect. Surely that's a huge boon?

--ajs.

[Dr Lancer-X]

'backtick or not to backtick' is pretty much just an exercise in learning to avoid bad symbol names (i.e. names of commands, names with spaces or funny characters in them etc.) Once you manage to avoid that, you basically never have to backtick. They're mostly there for backwards compatibility reasons.

[Lachesis]

Lancer-X, on 13 December 2010 - 12:34 PM, said:

'backtick or not to backtick' is pretty much just an exercise in learning to avoid bad symbol names (i.e. names of commands, names with spaces or funny characters in them etc.) Once you manage to avoid that, you basically never have to backtick. They're mostly there for backwards compatibility reasons.

set offset `cos(angle)`

edit: omgomgmgomgomgmgmgmgogmgomgg this is the best new MZX thing since the port

MeSsAgE rOw 5
//set helloBuddy 2
set helloBuddy (90000)
* "~fThis
string
has
line
breaks
woowoowoowoowooowo
(helloBuddy)"

This post has been edited by Lachesis: 13 December 2010 - 07:53 PM

[ajs]

It's not perfect, but you're comparing that to:

set offset "cos('angle')"

I see fewer characters I have to type.

EDIT: of course there's cos&angle& too, but the trig functions will realistically be used with expressions.

--ajs.

[Lachesis]

Oh no, I wasn't complaining about the debytecode syntax. I was pointing out a case that Lancer forgot to mention (and, a case that pretty much would affect every other line of Robotic I write).

This post has been edited by Lachesis: 13 December 2010 - 08:04 PM