ID:133475
 
I'm not sure if others may have suggested these already, nor if they are currently being implemented, but I wanted to get them out there non-the-less :).

o Interface Suggestions

+ Multiple DMF compatibility
- I see where this could contradict itself, but could deem useful at some-point :)

+ Import DMF function
- Currently interfaces cannot be imported/exported within themselves, but the other day I was wanting to re-use some interface files of mine, but I couldn't figure a way to import nor copy+paste the DMF skins.

+ Dropboxes
- Could be very useful :), the players would have to set the options through winset but again very useful.

+ Multiple Maps
- I have yet to try this function myself but, the added maps could display the default maps view, but a way for users to make it display differently could be winset the map aswell ^^ and what ever atoms are displayed within it. Good for Mini-maps,ect.

+ Removing Tabs
- A way for players to remove tabs on info panels

+ Removing Scroll bars
- a box to remove scroll bars on most skins

+ Re-size Child Splitter
- A way to disable the Child splitter, and to define the width to the child :)


o Image Coloring Suggestions
+ Invert
- Invert icons to whats beneath()


o Updating the Help(f1)

Here's a few suggestions :)
LucknFavor wrote:
+ Multiple Maps
- I have yet to try this function myself but, the added maps could display the default maps view, but a way for users to make it display differently could be winset the map aswell ^^ and what ever atoms are displayed within it. Good for Mini-maps,ect.

This has been suggested several times already. For technical reasons it's just not possible. BYOND is too solidly geared around the idea of only having a single map.

+ Removing Tabs
- A way for players to remove tabs on info panels

Info panels only have whatever tabs you give them.

+ Removing Scroll bars
- a box to remove scroll bars on most skins

Scroll bars pretty much only appear in the output, browser, and grid controls, but they're more or less automatic. I'm not sure where there'd be a point in removing them.

+ Re-size Child Splitter
- A way to disable the Child splitter, and to define the width to the child :)

I'm not 100% sure what you mean here, but I'm guessing you mean you want the child control to have two panes but make the splitter invisible and impossible to move. I've thought about something like that before; it might be worth pursuing at some point.

o Image Coloring Suggestions
+ Invert
- Invert icons to whats beneath()

That'd be a radical alteration not only to the icon format but also to the drawing. In OpenGL and DirectX I'm not sure that's even possible.

o Updating the Help(f1)

Updating it in what way?

Lummox JR
In response to Lummox JR
Lummox JR wrote:
o Image Coloring Suggestions
+ Invert
- Invert icons to whats beneath()

That'd be a radical alteration not only to the icon format but also to the drawing. In OpenGL and DirectX I'm not sure that's even possible.

If he means add effects such as sepia and negatives of images then it is possible through HLSL (I think that is what it is called for DirectX).

George Gough
In response to KodeNerd
That also means it should be accomplishable by /icon.MapColors() (I think).
In response to Popisfizzy
o Updating Help(f1)
-there is very little to be updated from what I've seen ;), from what I mean though is to remove some of the unused commands such as prompt, adding some of the commands that aren't included within, giving brief descriptions on how to use some of the older commands that have come to be obsolete (like SendPage) :D.
In response to Lummox JR
Lummox JR wrote:
This has been suggested several times already. For technical reasons it's just not possible. BYOND is too solidly geared around the idea of only having a single map.

So is this a "we're never going to see this", "maybe in BYOND 5.0" or "gah this is going to annoy me a lot"-kind of obstacle we're talking about here? cause' I was under the impression this was being worked on.
In response to KodeNerd
the invert thing... coulnt it do somthing like:

blue 255
red 0
green 0

invert

blue 0
red 255
green 255

for every pixle?(slightly off topic: rofl, just calculated it, there is 1024 pixles per icon o.0 never knew that :P)

not sure if thats what they ment by that

_ _
|_| KingCold999 |_| <-impenitrable box from CTHULHU :P
In response to Android Data
Android Data wrote:
Lummox JR wrote:
This has been suggested several times already. For technical reasons it's just not possible. BYOND is too solidly geared around the idea of only having a single map.

So is this a "we're never going to see this", "maybe in BYOND 5.0" or "gah this is going to annoy me a lot"-kind of obstacle we're talking about here? cause' I was under the impression this was being worked on.

I don't know where you could have gotten that impression. I won't go so far as to say never on this, but multiple views would be such a huge design change that it would require considerable time just coming up with a coherent plan for using vars like client.eye, world.view, etc., and then there'd be the long hours of working on that and only that. This is very much in the "not on the drawing board" phase, though I will say it's much more feasible than, say, 3D.

To answer your question more directly, I'd say this is a "maybe in 5.0". For the 4.0 series other changes, like for instance the limits The Magic Man was talking about, are more feasible and more urgently needed.

Lummox JR
In response to Lummox JR
Lummox JR wrote:
Android Data wrote:
Lummox JR wrote:
This has been suggested several times already. For technical reasons it's just not possible. BYOND is too solidly geared around the idea of only having a single map.

So is this a "we're never going to see this", "maybe in BYOND 5.0" or "gah this is going to annoy me a lot"-kind of obstacle we're talking about here? cause' I was under the impression this was being worked on.

I don't know where you could have gotten that impression.

A lot of suggestions seem to either be impossible to put in properly / not on the list at all (such as 3D support), it's on the list but is delayed due to the amount of work requires (in this case the multiple map controls, but also certain limits) or is just really annoying (certain interface changes, BYOND site vs. IE, ...). I just wanted to know where on the scale it was.

I won't go so far as to say never on this, but multiple views would be such a huge design change that it would require considerable time just coming up with a coherent plan for using vars like client.eye, world.view, etc., and then there'd be the long hours of working on that and only that. This is very much in the "not on the drawing board" phase, though I will say it's much more feasible than, say, 3D.

Don't know if this helps, but here's what I came up with:
client
var
list/views[0]
New() //by this I mean the raw New(), what sorta happens internally
//backwards compatibility
eyeobj = new/client_eye("map", null, MOB_PERSPECTIVE, src.view)
/*
at this point, BYOND should automatically sync variables such as client.eye/virtual_eye/perspective/view/lazy_eye
etc. with the eyeobj.
*/


return ..() //call the 'real' client/New(), well, after doing the rest of what you guys do in here!

client_eye
var
control //windowid.controlid for the map control
atom
eye
virtual_eye
perspective = MOB_PERSPECTIVE
view = world.view
lazy_eye = 0
pixel_step_size = 0
list
screen
images
New(control, eye, perspective, view)
src.control = control
src.eye = eye
src.perspective = perspective
src.view = view


Basically it would introduce the "views" list which contains objects that can be used on other maps. The eyeobj's "control" variable is read-only and is always set to the default map. The rest of the variables are kept synchronized with the main client vars.

This allows for multiple map controls without breaking the existing system...

To answer your question more directly, I'd say this is a "maybe in 5.0". For the 4.0 series other changes, like for instance the limits The Magic Man was talking about, are more feasible and more urgently needed.

...but since you'd probably have to dig deep in the code that makes the map work and behave as it does now, for now I'll just have to wait and not have the ability to use my fancy camera system using multiple map controls. Oh well. Onto 5.0. :P
In response to Android Data
I have doubts that creating a new built-in datum type would be a viable solution. Thinking about this yesterday, I suspect something a lot closer to linking clients together would be the best way to go, since a lot of code would be able to function as-is. Of course that could be dovetailed with your idea to access those chained clients as a list.

Lummox JR
You could code in a way to remove tabs. Just add a verb in the tab called 'Remove Tab' and make it take away all of the verbs and give them a verb in the Commands tab to get them all back.
In response to Quiet Screams
I meant in the way of removing tabs and to consistently keep the verbs though ;). Multiple tabs isn't a problem, more or less removing the tabs all together and keeping the verbs and the pane to show the verbs in category. Speaking of scroll-bars though, I there could be use with this, for the perfectionist such as myself :D, say I make a grid 32x32, just for the purpose of displaying the icon, nothing more, in its current version it would bring up scroll-bar's that hid the grid itself!
LucknFavor wrote:
I'm not sure if others may have suggested these already, nor if they are currently being implemented, but I wanted to get them out there non-the-less :).

o Interface Suggestions

+ Multiple DMF compatibility
- I see where this could contradict itself, but could deem useful at some-point :)

Sorry for necroing this topic, but this seemed to be the most recent topic on this subject; is this a possibility in the future?
In response to DivineTraveller
We've talked about possible means of using more than one .dmf file before, but it's kinda complex because they just aren't meant to be merged into a single skin. Some potential issues like name conflicts can come up; resolution of those issues would be problematic. It might be feasible to do this but it involves some design decisions and some possible restructuring of code, so it isn't as straightforward as it might sound.

Lummox JR
In response to Lummox JR
Alright, thanks for the feedback Lummox. I hope it comes along sometime, anyway.
+ Multiple DMF compatibility
- I see where this could contradict itself, but could deem useful at some-point :)

I'd like to see the aforementioned request supported. This will allow developers (like me) to create libraries which provide a .dmf file without conflicting with the consumers. Assuming we wisely name things.

If it can't be done, a build error/warning should be provided.

Thanks,
ts
In response to Tsfreaks
Seconded, though if memory serves me right it's probably on The List already anyway.
In response to Kaioken
What list?
ts
In response to Tsfreaks
Schindler's list =o
In response to Tsfreaks
I actually don't understand why it's so difficult to provide compatibility for multiple DMF files. Seems to me all you need to do is combine all the .dmf files included in the project as a single .dmf file.

The only issue would be a minor one: what happens to duplicate windows? The answer is to pick from one of the choices below:
1) either you skip over the duplicate windows;
2) rename the duplicate windows to "window1", "window2", and so forth
3) display an error that there are duplicate windows preventing the skin from being merged, opting the user to fix it.

I'm not pretending to know how the interface system is set up, but it seems to me that if it's possible with BYOND to merge a couple of text files together, surely you can do the same with C++. All you'd have to do in addition is to parse the result for any duplicates and cause a remove/rename/error.

Has this feature been forgotten, or is it really that difficult? Or are you just too swamped with work to be able to implement this?
Page: 1 2