27 replies to this topic

[Matthew]

You cannot continue in every cave while also having only one dmap. You can try the "continue here" option for the screen but its a bit fucky sometimes for reasons I can't remember off the top of my head. This is to say, you either have to disable continuing in the caves or make a separate dmap for each cave. (Or use a continue script).

 

I get what you mean Jared and would like something similar to it. Just another one of ZC's old quirks.

Edited by Matthew, 13 September 2019 - 06:55 PM.

[Lüt]

You have to use the "Entrance/Exit" warp type to set continue points in caves.

If you set a DMap to any level number other than 0 and check the "Continue Here" box, the continue system will start you at the last used Entrance/Exit warp type regardless of what screen number you put in the "Continue Here" field.

So if you're making an 8x16 overworld, you can also have a second 8x16 cave map aligned with that overworld, and use a single cave DMap with "Continue Here" and "Level 10+" and you'll always restart in the cave you were last entered from as long as you used the Entrance warp type to get in.

Granted, this is assuming you're using single-screen caves and not a non-euclidean underworld network with screens that would overlap if placed on the same map. But if you are, the only exceptions to making the entire cave map a single DMap are standard settings like palette/music or if you wanted to give level-specific items like, say, a key/map/compass for dungeon 6.

I basically did the same thing with one of my last updates, except I didn't want the player to continue in the caves, so I used Instawarp With Blackout warp type and unchecked "Continue Here."

[Emily]

You have to use the "Entrance/Exit" warp type to set continue points in caves.

If you set a DMap to any level number other than 0 and check the "Continue Here" box, the continue system will start you at the last used Entrance/Exit warp type regardless of what screen number you put in the "Continue Here" field.

So if you're making an 8x16 overworld, you can also have a second 8x16 cave map aligned with that overworld, and use a single cave DMap with "Continue Here" and "Level 10+" and you'll always restart in the cave you were last entered from as long as you used the Entrance warp type to get in.

Granted, this is assuming you're using single-screen caves and not a non-euclidean underworld network with screens that would overlap if placed on the same map. But if you are, the only exceptions to making the entire cave map a single DMap are standard settings like palette/music or if you wanted to give level-specific items like, say, a key/map/compass for dungeon 6.

I basically did the same thing with one of my last updates, except I didn't want the player to continue in the caves, so I used Instawarp With Blackout warp type and unchecked "Continue Here."

^ LGA3 had 3 mini-dungeon caves, which are all the same dmap; and I used that, because completing the first one gives you a small key to the level, and the second (requiring that) gives the big key for the 3rd Each was like 4-5 screens, IIRC, and you continue at the proper location for all 3 of them with no issues.

[Timelord]

So as it stands, we can't organize DMaps. I think it'd be amazing if we could somehow organize DMaps in the way we want. I think a copy/paste option would also be nice, if possible!

 

Even if you could 'drag and drop' DMaps to change their order, you would still be changing their numeric IDs in the process, which would break all of your warps. 

 

What exactly do you want here? The only thing that I can imagine adding is Select DMap,sorted by Title.

 

Regarding continue points, you certainly do not need one DMap for every cave. There are system methods around your difficulty, there. 

[klop422]

I'd say that, even if you don't need a dmap per cave, it'd still be useful to move dmaps around. for example if you decide to change the order of the dungeons in your quest, or suddenly decide to have another mini-dungeon in your town or whatever. And location in the dmap list doesn't have to correspond to the dmap number - having it function like the string list could work, at least from a user's perspective. I don't know what issues there might be with doing that, though, from the programming end.

[Russ]

IAnd location in the dmap list doesn't have to correspond to the dmap number - having it function like the string list could work, at least from a user's perspective. I don't know what issues there might be with doing that, though, from the programming end.

A rather large one would be that any scripts that reference dmap number would break. That alone makes sure a feature really impractical.

[klop422]

A rather large one would be that any scripts that reference dmap number would break. That alone makes sure a feature really impractical.

I don't know how it works on the back end, but the string list allows you to move the strings around without changing the string number. Other lists (enemies, items, etc.) just change the visual ordering based on alphabetical order. I feel like the Dmap list could do something similar, but that would at the very least need a 'list placement' variable added to each (where the Dmap number would likely just be where it is in the list by default/in all versions til now).

[Timelord]

Pretty much, we can sort by ID (number), or make an alphabetised list. You won't be able to select between the two.

Moving elements would otherwise renumber them, which is not viable.

[Twilight Knight]

How about giving the Dmaps a "weight" property, purely indicating its order in the Dmaps list.

 

I know it's a lot for a small feature, but just an idea.

Edited by Twilight Knight, 18 September 2019 - 01:54 AM.

[NoeL]

I don't see why it'd be so hard to create a "display" array that preserves dmap IDs while not listing them sequentially. This could make for easy sorting and drag-and-drop arranging without breaking anything on the back end. You could even potentially get more complicated and have JSON-style grouping, letting you close/expand whole blocks of dmaps for ease-of-viewing and even have subgroups (like a group for dungeons, each with a subgroup for different floors).

 

You could even (semi)hide the dmap ID altogether and have a "new Dmap" button that automatically assigns it the next unique ID (though you might want to be able to change this for scripting purposes).

 

Not critical improvements, but good QoL stuff nonetheless.

[bigjoe]

Since there are C and V keys in the dmap editor, why not have an M key? This would move the dmap and update all warp references to it as well.

[Timelord]

Since there are C and V keys in the dmap editor, why not have an M key? This would move the dmap and update all warp references to it as well.

It would not however fix script references. The only viable alternative is to change it so that it always lists by name.

[bobby_light]

I think this is what NoeL is suggesting, or similar - why not just add a new "display order" property to dmaps, which is used by zquest for order at design time.  Completely independent from dmap ID.  That way no existing dmap references break.  Only the zquest UI uses the new property, which would default to the dmap ID (assuming it's an int) if not defined.