[Graham]

I just had an idea. What about an option in the game editor, such as pressing 'control' 'R' to jump around to the different robots on board? It could jump to the robot with Robot ID 1 first then 2 and so on. I think it would be very handy, though I have no idea the difficulty of implementing something like this. Just an idea though.

[Lachesis]

Traditionally I think Shift+F2 has generally been relied on for this sort of thing, but I agree that it can be irritating and also won't show robots that have the same FG and BG colors. This feature would not be hard to implement but I'm a little iffy on the details here, for example, how do we know which robot to jump to next if the cursor isn't on a robot? Do we just start over or keep track and jump to the next one? (Answer: start over probably) What if we want to jump to robot #253?

Something that would be easy to do is a popup like Goto (CTRL+G) that works on robot IDs, but it's not as convenient or obvious as what you've suggested. Another idea is that instead of jumping by robot ID we jump by coordinates, from left-to-right, top-to-bottom (more predictable, at least). Even both could be done. I'm open to suggestions and I like this idea in general.

(for future reference there's a Feature Request Tracker here for posts like this)

[Graham]

So I got to thinking how this suggested feature could be more useful. You know how you want to update a robot with a newer coded version say from a different board? you can't just replace it if its on customfloor, you have to erase it, replace the customfloor, then you can place the new version. If this was a find/replace feature like the find/replace in the robotic editor, you could have the robot that will replace the old one in the active (draw) box and select a robot by robot ID or x/y location. Then it would place the new robot in the old one's spot without disturbing customfloor, carrying all parameters of new robot, use the robot id of the old one.

Of course you'd need to know the robot ID you want to replace. I do not know of a way to find a robot's ID in the editor, is there one? I've only recently started to know thier ID by using the f11 debug tool (a real life saver, BTW). I dunno, still thinking. It would solve how to find robot 253 if you could enter the number in a find/replace box.

Sorry about posting in the wrong location. So can I move this topic to the correct spot? I don't see a way.

This post has been edited by Graham: 18 January 2013 - 03:04 PM

[Old-Sckool]

There are already various to keep your code up to date between multiple copies of robots. One way is to save the code into a text file, and use this somewhat bizarre command in each robot that uses the code

SET "File.txt" "load_robot"

You can even put code into subdirectories if necessary and load the file like "subdirectory/file.txt".

Second, a complete overhaul of robotic has been in the works for some years. I believe that one of the features is the separation of code from robots, which would allow for multiple robots to share the same code base, and probably allow you to choose what code file a robot will run.

[Graham]

Loading robotic code is a great idea I hadn't thought of. If robotic was overhauled in that manner, this would be fairly useless.

[Exophase]

How about just bringing up a list of robots on the board and choosing from that to let you start editing the robot (there could also be a button that moves the cursor to it, but the former is normally what you want)? Sure it'd be a little more work than pressing a key to go straight to some robot if the one you wanted happens to be next in the list, but you can usually traverse list dialogs pretty quickly by typing the name.

It could also list the coordinates (and perhaps other attributes like char and color) to try to disambiguate robots with the same name. If MZX is ever overhauled to separate robots from programs revising the list to give programs instead would be the logical step. If Robotic isn't overhauled then an interim step can be made by giving the list manager the option to edit the robot such that when it exits it updates all the robots on the board that have the same name - probably with a dialog that confirms you really want to do this.

I know these days a lot of people like using external text files but I have to imagine not everyone wants to use external text editors for this, or a scratch robot that they manually import and export out of (at least I wouldn't want to do either). Maybe as another interim step the robot editor could be adjusted so that it can work on external text files instead of actual robots? The same robot editor list can have a file dialog button for allowing this. Of course, such a thing is only going to work with debytecode. At this point it could really be more work and more awkward than just doing the program/robot separation, though..

[Graham]

I like the ideas you've presented and it would be great to see something like this. Though I know no one wants to add a feature that may just be obselete when a new version of mzx is released, that's pointless.

Until that day comes I think I'll start using the load robot feature for all the robots that use the same program on every board. I'll keep a robot on my test board that has the program, so I don't have to load one to make changes. Then I can modify it and export it and the changes will automatically be present in all similar robots. That's going to save me a lot of work.

[Lachesis]

Exophase, on 18 January 2013 - 10:08 AM, said:

If MZX is ever overhauled to separate robots from programs revising the list to give programs instead would be the logical step.

I've been planning to kick that forward to 2.85, actually, so we won't even have to wait for debytecode to benefit from it. It's a part of the EBML format move. :>

I was going to optimize program duplicates with a bytecode (2.85) or source (2.90) hash table or similar. There are holes though, like 'what do we call different programs from robots with the same name', probably name_BOARDID_ROBOTID or name_[first number that isn't used] to start with but ehh

[Exophase]

Graham, on 18 January 2013 - 12:38 PM, said:

I like the ideas you've presented and it would be great to see something like this. Though I know no one wants to add a feature that may just be obselete when a new version of mzx is released, that's pointless.

I don't think this feature will ever be obsolete, it'd just need to be adjusted with everything else.

The bare bones idea - making a dialog that lets you pick a robot to edit from the ones on the board - is pretty easy to implement and can probably be done in under an hour.

Lachesis said:

I've been planning to kick that forward to 2.85, actually, so we won't even have to wait for debytecode to benefit from it. It's a part of the EBML format move. :>

I was going to optimize program duplicates with a bytecode (2.85) or source (2.90) hash table or similar. There are holes though, like 'what do we call different programs from robots with the same name', probably name_BOARDID_ROBOTID or name_[first number that isn't used] to start with but ehh

Oh, well there you go then. I wouldn't worry that much about what you name the old programs with the same name and different robots. Are you planning on organizing programs per-board, per-world, or both? However you want to do it, it'd be good if it appears to the user this way.. because I expect that normally people will want a list of programs that's confined to their current board.

Maybe you could do this:

Have a big list of programs each with a 32-bit integer ID and not necessarily unique names. Each board contains an ID list that says what programs are part of that board, in order to help the editor partition it. When you make a new program it gets added to the board list, unless you specify it's a global program. I don't know if there'll be a method for a robot to dynamically change its program via the program's name (I figure copyrobot and the like will go through the robot's name to get the program ID), so in this case the program names would be purely for the sake of editing. But if you do have some method to do this, maybe it could search the names of the programs on the board first, then search the global list for the first it finds.

[Lachesis]

The unique names would be necessary as yes, I'm planning on a PROGRAM "name" command (we still have space for new commands in 2.85 right? ). It wouldn't completely replace LOAD_ROBOT/LOAD_BC but it would cut down on the necessity of it to a large degree. I still like editing my files externally a lot, I wonder if some way to tie a program to an external file from the editor would be worth the effort at all.

As for replacing LOAD_ROBOT/LOAD_BC I'm thinking of a single command represented in source as LOAD PROGRAM from "file" (for new source), LOAD PROGRAM from LEGACY "file" and LOAD PROGRAM from LEGACY BYTECODE "file". This is a very debytecode thing and from the impression I got there's a lot of work to do to get it to the point where I can tear out redundant commands, add new ones in, and get it to compile different commands as the same bytecode or as multiple bytecode instructions, but I haven't given it a close enough look. I was working on a complete internal bytecode remapping several months ago, I'll give it another look and upload it for review one of these days <_<

I do like the suggestion of only showing programs on the board initially and allowing the user to expand it to see every program. It would reduce some of the perceived clutter from imported worlds at the very least and likely go a long way to streamline program selection.

EDIT: the sooner we can IPB and move to SMF, the better/>/>/>/>/>

This post has been edited by Lachesis: 18 January 2013 - 08:39 PM

[Exophase]

You wouldn't need unique names with that command, just a qualifier to load the program from a global list or from another board. Maybe not the latter, that doesn't really sound that useful. If the converted worlds are a little less efficient (ie, have the same program on several boards) that isn't a huge deal.

Of course, names within those lists will need to be unique. There are probably far fewer instances of legacy games that give robots with different programs the same name if they're on the same board.

Unless you can find something worth preserving (and can't be fixed, etc) used load bytecode I say you should just scrap it. I'm not sure it was used at all in anything released. It'd be nice to not need the legacy file command either.. LOAD_ROBOT will almost always have been used with static names and referring to static files, in which case they could just be converted and loaded into the world's program list, since that's what a lot of people were using it for. If you really do need to preserve functionality for dynamically created programs you could have it check if the file exists and is newer than the world, in the robotic.. but that gets pretty messy. I do think that if you want external programs you should make it possible for robots to use them directly instead of having to use a program which is nothing more than a LOAD_ROBOT command. And of course those programs in legacy worlds can be converted to this format.

You're going to have to jog my memory on something.. are you using normal archives for the EBML worlds? And if so, do you plan to have programs as individual text files? I'm just wondering about what work would be necessary to use external editors with internal robots.

[Lachesis]

Unfortunately, Eternal Eclipse Taoyarin actually does use LOAD_BC, and quite extensively. We just recently had issues with EET and validation, that's the only reason I'm aware of it. I don't think anything else uses it.

We might as well keep the legacy source converter around, since we'll always have legacy stuff to convert if we want to support older worlds. It is also inaccurate that LOAD_ROBOT has almost always been used with static files. I have used it for dynamic files before to get around the 65535 size limit, and although that will be easily changeable once we have programs, I can't speak for anything else that's been released in the past decade or so.

I hate hate hate hate hate hate hate the idea of having programs as a per-board construct, honestly. I have full intentions of making them entirely global -- it's less messy overall even if we have to come up with a silly renaming convention for duplicate names. Having programs in more than one place is one of the main issues this is trying to resolve. Programs per-board would be taking a step forward and then another step back.

As for the board lists, what I was thinking is that we can build board lists of programs that have recently been used in the board for user convenience in the editor. Maybe we could even save it with the world, though ajs and I had a chat a while back and we decided that in general, editor metadata should be kept out of the world. In this case it doesn't seem as bad to make an exception though.

Well, since I keep changing my mind about EBML every five minutes (and I'm probably driving ajs and Terryn insane by it), it's hard to say, but at the moment the best path seems to be to make world files have the 29-byte header followed by a zip archive, and the zip archive contains a world EBML, board EBMLs, robot EBMLs, program EBMLs, charset(s), and a 256-color palette (and an intensity palette for save files). At this point the layer data will probably be a part of the board EMBLs (vlayer in the world). The programs need a data structure because we'll probably be saving a label cache, eventually a function cache, and potentially source in debytecode.

On the same note, we'll probably still use MZM3 for now, but I don't know exactly how. I might have to spec it so robots can be saved with a program still just for MZMs.

[Exophase]

Meh, Lancer-X was the one who told me LOAD_BC wasn't used then it turns out he used it Well my memory is kind of fuzzy and he may have said he didn't remember which one he used. If it's just one game it can be dealt with in other ways, especially if those BC files aren't dynamic.

I'm not saying to make programs strictly board-local at all, this is just a name-spacing issue, ie making the name lists hierarchical and giving some precedence to your local hierarchy when searching for names. You could have some kind of scoping annotation to explicitly access programs that have the same name in a different space (global list or different boards). What I was saying before is I don't see much argument for giving support for accessing programs in different boards as opposed to some global list - I think it's perfectly fine to just have global programs and per-board programs, and if the user wants to use a program over multiple boards they put it in the former list. But it doesn't make that much of a difference to make the global list include all the programs. What this means is that you can have programs with the same name in the list, and the ones on the board-local list are given priority. Don't like it? Don't name your programs the same thing. The advantage here is that the world convertor can do that (and therefore won't mangle your robot names too terribly), because legacy worlds don't have explicit program sharing in the first place, much less across boards.

Most programs aren't going to need to be loaded by name in the first place. These things don't sound messy to me, but your call really.. doesn't make a huge difference..

If you're using a zip archive for EBML could you just have boards in subdirectories? You can use that to organize the lists in the editor. You could flatten the list internally wherever you don't want to actually use the board relationship, which if you really want could just be used in the editor's listing. While a "most recently used" view isn't bad I don't think it's a substitute for board-local stuff.. you have to think about this from the point of view from people who have been using MZX as MZX for a long time and give them the ability to design things in an MZX-like way, which implies a board and robot relationship. This isn't just familiarity, that's useful as an organizational construct for a lot of games, and IMO is one of the things that makes people want to use MZX.

Why do you want to make stuff like label caches part of the world file? I agree with ajs that you should keep the editor stuff outside of the world files, if you want to make it persistent just make the editor create its own files for this.

[Lachesis]

If anything, introducing the concept of scope beyond robot LOCAL counters is more alienating towards previous MZX users than keeping the programs in one place. I have a feeling more older MZXers will go "Cool, I can reuse my 'bear' enemy across different boards now, and MZX automatically consolidated them all into the same program!" than "What what whaaaaat is this i just want my board's to have program's" but I think it has a lot to do with how the UI is designed to deal with it, and I have a pretty good idea of how to handle it simply and efficiently UI-wise.

However, in the end, you're probably right that it doesn't matter and we don't need to rename programs. Robots will index them directly. The program command is a new addition so it doesn't affect legacy imports, and you're right, if they want to use it to access a specific program they'd better make sure that program has a unique name. We might want a way of distinguishing programs with the same name from each other in the program list, however.

Essentially, my UI would be the same as the board list except with name-sorted programs (and probably with rename/delete buttons), the first option would be (new program), and the second or last option would be (view all programs) to bring up a name-sorted list of every program in the game.

It wouldn't be just a "recently used" list; it'd be built off of all robots present on the board and possibly contain programs that were also formerly on the board in robots that have since been removed.

Subdirectories wouldn't be a bad way of handling boards and all of their specific robots, I'm sure. Honestly, I've never worked with zlib before and don't know how much work will be needed to implement zips in world files, but I shouldn't think it will be too much effort based on my limited knowledge of the ZIP format. I'm still worrying about future 2.84 releases as of the moment.

I meant saving the label/function caches in the save format, I should have clarified that. Another thing I've been thinking about for the EBML move is reducing the .sav format size by only including boards/robots that have explicitly changed and new programs added from LOAD_ROBOT/BC. Not that I think we'll have much to worry about since raw boards will compress a million times better with DEFLATE than with run-length-encoding, and now programs will be compressed as well.