ID:104318
 
Applies to:Dream Maker
Status: Open

Issue hasn't been assigned a status value.
Allow a library to specify a help file that gets included in DM's help if the library is included in the current project. This would just be an HTML file that follows the format of help\ref\info.html.

Even better: make this a new type of file (code, map, icon, interface, script) with an editor (in the Dream Maker program) that has templates for different types of help pages (var, proc, etc.). All of these help files (.dmh?) within a library get added to DM's help when you include the library.
+
If these library help files were listed in a separate tab, then I could see it being a useful idea. Just mixing them in with everything else might get confusing though.
Unfortunately there isn't much room to add tabs to the current reference interface (libraries can also have long names). It would be nice for each library to be on its own tab not just to avoid confusion, but to let people browse the help content for a single library at a time.

Having built-in support for this would also make it possible to mark every library-related page as such (instead of relying on developers to mark the pages themselves). For example, in this screenshot you can see how the page is marked multiple times as belonging to a library.
Maybe it could be listed as something like library.function, though that might break the topic search
:|

wouldn't be THAT hard...well maybe a little but come one : http://www.byond.com/developer/Masschaos100/RefWriter
Masschaos100 wrote:
wouldn't be THAT hard...well maybe a little but come one : http://www.byond.com/developer/Masschaos100/RefWriter

Clearly it's possible but there are problems with modifying info.html directly. Changes are hard to undo. Built-in support could add a library's documentation to the reference when the library is included and remove the content when the library is unincluded (or when you open a project that doesn't use that library).

It's also hard to manage changes to the reference this way. If you update BYOND it'll overwrite info.html and you'll lose the new content. If you append content to the file you need to be careful that content isn't appended twice. If you replace info.html with a new file you can only have one set of changes applied at a time.

I'd also rather not rely on users clicking "Yes" to allow access to files. People should instinctively click "No". (edit: especially because changes to the reference can be damaging and hard to undo)

I'm not requesting this to make it possible, I'm requesting the feature because built-in support would make it more usable and functional.
Why not just have a separate help reference for the library? Like Ctrl+F1.
Hiro the Dragon King wrote:
Why not just have a separate help reference for the library? Like Ctrl+F1.

Because the goal is to allow for better integration of libraries. Nobody is in the habit of pressing ctrl+F1 for help in Dream Maker.

Naming collisions are not a problem. They already exist and the current system handles them fine. There are two pages for the pixel_x var but they're called "pixel_x (atom)" and "pixel_x (client)". If a library defined an object type called "overlay" and gave it a pixel_x variable then its reference page would be called "pixel_x (overlay)".
How about the opposite. In a library, Ctrl+F1 brings up the DM's help files and F1 brings up the libraries.

And naming collisions would be completely destructive to one of the purposes that help files serve. There should be some separation between DM's help files and the libraries help files. That way, I can just open the library, bring up the help files, and browse through what the library has to offer. Just like I currently do with DM's help files.
When you're using a library you won't have it open, you'll have your project that's using the library open.

With this as a built-in feature your reference would only contain entries for built-in stuff and the libraries you have included in the current project. That last part is the key. To better show how this would look here are some more screenshots:

http://files.byondhome.com/Forumaccount/page-1.png
http://files.byondhome.com/Forumaccount/page-2.png
http://files.byondhome.com/Forumaccount/page-3.png

The first two images are parts of the index page which every entry related to my library links back to (as seen in the third screenshot). With built-in support for this it could be required to have this index page and DM could automatically place links to it in related pages. It could also stick the "[library]" tag on each page automatically. This would let users easily see what content is contained by the library and easily identify if a page is a built-in feature or part of a library.

Edit: It's a somewhat unrelated point but naming collisions are often a good thing. If you create a new kind of object that isn't a child of atom (or client) and it has vars to determine its pixel offset you should call them pixel_x and pixel_y *because* those names are already used. Even though it will cause a naming collision in the reference those are the variable names that DM programmers are familiar with and would expect to see.
Well, I guess that you're right about that, but I still disagree with how your demonstration is set up. If anything, the libraries list of topics should be at the top of the list.

Also, I may not have delved that deeply, but can you even map a datum that isn't child to an atom?
I definitely think this should be added. I also agree that it should be a new type of file similar to interface. That way you could build it up into as many pages as needed for your library.
With instant access to the documentation of library procedures, ease of use with libraries would improve, making it easier and faster to develop with them.
Hiro the Dragon King wrote:
Well, I guess that you're right about that, but I still disagree with how your demonstration is set up. If anything, the libraries list of topics should be at the top of the list.

Are you talking about the list of topics on the left side of the reference? If so this is handled by Dream Maker - regardless of the order that pages are defined in info.html they appear in alphabetical order in this list. Splitting library and non-library pages would break the alphabetical ordering and cause problems.

Also, I may not have delved that deeply, but can you even map a datum that isn't child to an atom?

I'm not sure what this relates to.
I was speaking about the second screenshot. If you're going to list the libraries, they should at least be at the top. Otherwise, it would just be a complete mess.

Forum_account wrote:
Edit: It's a somewhat unrelated point but naming collisions are often a good thing. If you create a new kind of object that isn't a child of atom (or client) and it has vars to determine its pixel offset you should call them pixel_x and pixel_y *because* those names are already used.

I though that only atoms could be mapped. If it can't be seen visually, than pixel offsets wouldn't exactly matter. I was just wondering if I was wrong.
Hiro the Dragon King wrote:
I was speaking about the second screenshot. If you're going to list the libraries, they should at least be at the top. Otherwise, it would just be a complete mess.

That makes more sense. It would still be a problem for searching if an author's name shares a prefix with the name of a page you're searching for. Also I'm not sure why you think it would be a "complete mess", it would only list the libraries you have included in the project.

I though that only atoms could be mapped. If it can't be seen visually, than pixel offsets wouldn't exactly matter. I was just wondering if I was wrong.

Suppose you create a class that is a wrapper for an object that can be shown on the map. You might do this for overlays or images because they're sort of treated like objects but not completely. Your new object would expose display properties (icon, icon state, pixel offset, etc.) that get passed on to the object that gets displayed.
Okay, so I was right, just confused by your post. I understand you now. As for the complete mess, I am a stickler for organization. Everything is a complete mess to me.
Bump.
I guess I'm the only one voting for this feature now?
I had a free vote so I'm voting for it too.
Page: 1 2