ID:260798
 
Would it be possible to add a feature to the map editor that shows an 'X' or similar overlay over dense objects, mobs, and turfs on the map? It would be very helpful in finding little gaps or bugs in maps.
I strongly agree with this, for the same reasons -- sometimes I find myself editing little walls for secret passages or whatnot, but later on I forget where I put them exactly, leading to a long process of finding which one it was..
I find a nice way to do this yourself (unless it's too late) is to make everything undense, then make a density turf with no icon or icon_state. The density tile should show up as a block of checkered and transparent pixels over the tile.
If they would add some procs to save maps as .dmms (as was once spoken of) I could add this into a custom map editor. But I really have no interest in decrypting and rewriting their entire map saving system.
Same goes for getting frame (and other) details for a custom icon editor. Though that one really has no work-around.
In response to Falacy
Falacy wrote:
If they would add some procs to save maps as .dmms (as was once spoken of) I could add this into a custom map editor. But I really have no interest in decrypting and rewriting their entire map saving system.

Surely you jest. It took me a single weekend to figure it out and now I've some nifty map-merging procs.
In response to Fugsnarf
The downside to that is that it would replace every turf you added the density turf to with the density turf. A dense door or gate is no longer a door or gate, just a dense turf. It also wouldn't work very well for objects that are movable.
In response to Foomer
turfs are one thing, objects are another. Turfs are everywhere, while objects you can interact with probably aren't. It's easier to tell what's dense and what isn't when dealing with objs. I would only put the density over turfs.
In response to Fugsnarf
His issue still stands, what happens if you want to interact with the turf below the 'dense making turf'? You can't, because that turf will no longer exist.
In response to Nadrew
Then don't interact with dense turfs, interact with dense objs.
In response to Fugsnarf
It all depends on how the game is setup then. You'd have to design the game with that method in mind if you want to do it that way.
In response to Foomer
That is correct. This is why it might be too late to accept this option for the person who wrote this thread. I don't really know though.
In response to Falacy
Decrypting the map format? That takes about 10 seconds, it's very simple.
In response to Jeff8500
The same for the icon format which he's also mentioned. What a coincidence.
In response to Jeff8500
Jeff8500 wrote:
Decrypting the map format? That takes about 10 seconds, it's very simple.

"aaS" = (/turf/Soul_Society/Water,/turf/Sewers/Water_Over,/obj/Decoration/Shadow{name = "Shadow"; icon_state = "4"; density = 0; layer = 7},/turf/Sewers/Bricks{name = "Bricks8"; icon_state = "BricksR"; layer = 8},/area)

Yea, piece of cake. And that's just setting up the basic format of things. You then have to effectively compile each tile into a relevant string, check if it already exists or not, then setup the 3 bamillion character string that represents the map itself. Not to mention setting it to scale up in characters; only when necessary, but preemptively.
Then as far as reverse engineering it goes, BYOND is pretty faily in its current state when it comes to dynamically creating maps. Especially when it comes to layered turfs of any kind.
And aren't you usually the people spitting out the re-inventing the wheel crap?

Kaioken wrote:
The same for the icon format which he's also mentioned. What a coincidence.

The icon tags in the png are pretty common, and explained in various places around the forums. However, there's no way that I know of to actually access them via DM. Or is there?
In response to Falacy
Falacy wrote:
Yea, piece of cake. And that's just setting up the basic format of things. You then have to effectively compile each tile into a relevant string, check if it already exists or not, then setup the 3 bamillion character string that represents the map itself.

It's not as complicated as you make it out to be, and it's been already done by multiple people in multiple ways in case you haven't noticed. So it is a little, to quote you, "a piece of cake". Just a simple plain-text format, after all, same for the DMF format - they keep those simple so you can work with them.

BYOND is pretty faily in its current state when it comes to dynamically creating maps.

I don't think so, it just could be a little naturally slow compared to other languages, especially with things like random dungeon generation, but apparently you've meant something simpler than that here, but you weren't specific on what you feel is... "faily".

Especially when it comes to layered turfs of any kind.

Those simply don't exist. However, there is absolutely no problem at all with replicating the map editor's "visual turf layering" at runtime at all, if that's what you're referring to.

And aren't you usually the people spitting out the re-inventing the wheel crap?

You indeed don't have to reinvent the wheel if you're going to implement map saving and loading, there are multiple libraries at your disposal for doing just that. =P And yes, Lummox said he's even planning on implementing certain built-in methods to do so for the speed and convenience.

The icon tags in the png are pretty common, and explained in various places around the forums.

Yes, and they're even so simple they don't need to be.

However, there's no way that I know of to actually access them via DM. Or is there?

There isn't a native way to do that, but you were talking about creating a custom icon editor, which I assumed (and you'd typically prefer) was made in another language.
Within DM, you don't need access to the actual DMI format/PNG comments or bother with them, seeing as you have various native tools to work with icons, such as the /icon procs. If you feel those tools lack a certain feature(s), that's one thing, but there's no particular need for the PNG comments to be directly accessible from DM.
In response to Kaioken
Kaioken wrote:
It's not as complicated as you make it out to be...

I pretty much explained it step by step o.O The point is though, if they already have internal systems written to do just that, why do I need to go writing my own external/less efficient ones?
As I said, most of you people rally towards pointless libraries, but when it comes to things like this you seem against it?

I don't think so, it just could be a little naturally slow compared to other languages, especially with things like random dungeon generation, but apparently you've meant something simpler than that here, but you weren't specific on what you feel is... "faily".
Those simply don't exist. However, there is absolutely no problem at all with replicating the map editor's "visual turf layering" at runtime at all, if that's what you're referring to.

Its more or less impossible actually. Creating multiple turfs at the same location during run-time simply overwrites the current one. And for some reason it seems impossible to modify their underlays, thereby creating the same effect BYOND would. So in the system I made, I have a bunch of objects sitting around that should just be turf underlays.
In an environment where you'd want to be able to modify those "turfs" though; something like that would probably need to be implemented anyway.

There isn't a native way to do that, but you were talking about creating a custom icon editor, which I assumed (and you'd typically prefer) was made in another language.
Within DM, you don't need access to the actual DMI format/PNG comments or bother with them, seeing as you have various native tools to work with icons, such as the /icon procs. If you feel those tools lack a certain feature(s), that's one thing, but there's no particular need for the PNG comments to be directly accessible from DM.

If I'm going to go through the trouble of creating some external application that can do everything BYOND can, I'll just make my own version of BYOND.
And the icon "tools" are definitely lacking to a point. Especially for something like this. It was once discussed to add an icon_state_details() (or some similar proc) that could pull all frame (and other) related information from an icon; since that information is currently unavailable, and would be useful in a multitude of situations. Even if the png comments themselves weren't accessible, a simple param string containing them would be fine, and probably preferred.
In response to Falacy
Falacy wrote:
As I said, most of you people rally towards pointless libraries, but when it comes to things like this you seem against it?

Hmm - what the heck is your point here? What do you mean by 'things like this'? Please clarify, as I don't really understand what am I against here, either. ;)

Its more or less impossible actually. Creating multiple turfs at the same location during run-time simply overwrites the current one.

Which is set-in-stone internal behavior which is of course identical at compile-time as well (in the map editor). There's no difference from runtime and compile-time, only one turf can occupy a tile, because a turf IS the tile.

And for some reason it seems impossible to modify their underlays,

Been there, done that, so I'll have to assume you did something wrong.

If I'm going to go through the trouble of creating some external application that can do everything BYOND can, I'll just make my own version of BYOND.

I see we like exaggerating, huh? =P
The point of making a new icon editor would obviously be to make a better, more powerful one, and DM isn't a language too suited to make graphic editors in, let alone powerful ones. So doing it in a language other than DM is a wise choice, not otherwise, and I won't comment on the irrelevant prospect of reprogramming BYOND entirely you pulled out of your [place]. In fact Crashed (IIRC) has been working on a nice icon editor in Python, I believe, which I look forward to.

And the icon "tools" are definitely lacking to a point.

Then make a feature request to expand them, etc. Expanding the /icon datum should have already be on their to-do list for a while, though, but like a feature on the list, who knows when they'll get around to that. Maybe if you give them good, detailed suggestions it'll come around faster.

Even if the png comments themselves weren't accessible, a simple param string containing them would be fine, and probably preferred.

That still won't allow you to actually access the parts of the icon that you want (e.g. frame 3 of NORTH dir of state "attack"), just to know which parts there are. So you'd need an expansion of the /icon interface anyway to do useful stuff with that - which might as well include get-data functions instead of having us need to bother with the PNG comments (as having both would probably make having the comments completely redundant).
In response to Kaioken
Kaioken wrote:
Which is set-in-stone internal behavior which is of course identical at compile-time as well (in the map editor). There's no difference from runtime and compile-time, only one turf can occupy a tile, because a turf IS the tile.

New run-time turfs could always just act like they do from the map editor. Any you add on top of existing ones merge with it. Though making that change now would probably break some games.

Been there, done that, so I'll have to assume you did something wrong.

Dunno. I just made the turf, made the underlay objects, attempted to add them to the new turf's underlays (which didn't work) so instead I just leave them located at the turf.

I see we like exaggerating, huh? =P

No, not really. If I'm going to go through the trouble of fully learning another language, to the point that I can replicate BYOND, I would just make my own.

The point of making a new icon editor would obviously be to make a better, more powerful one, and DM isn't a language too suited to make graphic editors in, let alone powerful ones.

I could (and would) create an icon editing tool with DM that can do everything DM's can. With a few additional features (like a modified palette, multi-state/frame modifications, more user-friendly inputs, animated previews, zooms, etc). For the most part, their icon editor isn't all that bad. It's the map editor that needs major advancements.

In fact Crashed (IIRC) has been working on a nice icon editor in Python, I believe, which I look forward to.

From what I've seen, you need python just to run it. And hes been working on that thing for years now.

Then make a feature request to expand them, etc.

It has been discussed already in this topic: http://www.byond.com/members/DreamMakers/forum?id=697017

That still won't allow you to actually access the parts of the icon that you want (e.g. frame 3 of NORTH dir of state "attack")

Sure it would, You'd just do something like Icon.state_info("Walk"). Which would return something like "dirs=4&frames=3&delay=2&delay1=2&delay2=2&delay3=2". dirs and frames (basic stuff) then delay would be the default frame-delay for the icon_state, followed by each frame's current frame-delay, and anything else that can be included (what else?).
EDIT: Could also include: movement-state, loops, rewind...
In response to Falacy
Falacy wrote:
New run-time turfs could always just act like they do from the map editor. Any you add on top of existing ones merge with it. Though making that change now would probably break some games.

There's not much need for built-in functionality for this as, as mentioned, it's pretty trivial for the developer to do so himself, if he so wishes.

I see we like exaggerating, huh? =P

No, not really. If I'm going to go through the trouble of fully learning another language, to the point that I can replicate BYOND, I would just make my own.

Yes, yes really. Nobody was talking about anything remotely like replicating the BYOND suite until you brought that up - you just decided to exaggerate and act as if that's exactly what I was talking about, but I was talking about simply making a custom icon editor, which you originally brought up. Also, nobody was specifically talking about you personally, either, so it doesn't matter what languages you happen to no or not (or if you think you can replicate BYOND, heh).

I could (and would) create an icon editing tool with DM that can do everything DM's can. With a few additional features (like a modified palette, multi-state/frame modifications, more user-friendly inputs, animated previews, zooms, etc).

It's possible, but that wasn't the point. It would also be very possible to do to in JavaScript if you were so inclined.

From what I've seen, you need python just to run it.

Oho, and a BYOND developer has an issue with such a thing? =P Besides, IIRC Python programs can be packaged in a way to not require pre-installation of Python, but that's off-topic.

That still won't allow you to actually access the parts of the icon that you want (e.g. frame 3 of NORTH dir of state "attack")

Sure it would, You'd just do something like Icon.state_info("Walk"). Which would return something like "dirs=4&frames=3&delay=2&delay1=2&delay2=2&delay3=2". [...]

No, it wouldn't, you didn't understand. You'd have the DMI data, but you wouldn't be able to intuitively actually access the icons themselves, i.e. isolate each graphical parts. That would need to be implemented in the language, like you can already isolate an icon_state and dir for instance with new /icon(file,state,dir), you'd need some method (probably the same) to isolate animation frames and whatnot.
In response to Falacy
I made a program that saves/loads similar maps, and it only took about two hours to write. My format is really similar, except it only supports one turf, area, obj, and mob per tile ('cause I was lazy, and that's all I needed).
Page: 1 2