Progressbar changes

Page: 1 2
ID:260712
 
Apr 18 2009, 9:55 pm
Could it be made so that you can assign special values to the progress bar?

Setting the value to "-1" could display the current progress of downloading the resource files (or w/e resources are being downloaded at that time, even those sent by client.Export()).
But the one I'd like to see is the ability to show the current progress of a file upload.
Apr 18 2009, 9:56 pm
This is already shown on the options and messages window?
Apr 19 2009, 4:37 am
In response to Falacy
Falacy wrote:
This is already shown on the options and messages window?

Isn't that window hidden once the login has finished? Maybe I want to put it on my interface? Perhaps in a nice, separate window? Could it be that I'm using client.control_freak and Options & Messages isn't available at all? Am I more trying to get a progressbar for uploading moreso than a download one?

Sorry, but dodging this request with a "it's already on the O&M window" is lame and annoying. The whole point of having interfaces is so we can control it! Sure, O&M has it, but then we might as well go right back to the standardized layout again.
Apr 19 2009, 4:39 am
In response to Android Data
Android Data wrote:
Isn't that window hidden once the login has finished? Maybe I want to put it on my interface? Perhaps in a nice, separate window? Could it be that I'm using client.control_freak and Options & Messages isn't available at all? Am I more trying to get a progressbar for uploading moreso than a download one?

The progress bar there will show uploads on the clients side. And as for this in general, I had multiple almost arguments with the BYOND staff about it. In short, they said no.
Apr 19 2009, 4:43 am
In response to Falacy
Falacy wrote:
The progress bar there will show uploads on the clients side.

Unless I have client.control_freak enabled, or if I want to actually be professional and make the skin display it with a nice logo and a label informing them on what is being uploaded, to which directory on the server they're uploading it to, etc.

And as for this in general, I had multiple almost arguments with the BYOND staff about it. In short, they said no.

Great, then. "No." Guess I'll have to find a workaround.
Apr 19 2009, 4:50 am
In response to Android Data
Android Data wrote:
And as for this in general, I had multiple almost arguments with the BYOND staff about it. In short, they said no.

Great, then. "No." Guess I'll have to find a workaround.

Well, technically, my complaints were about them removing it from the status bar. You may be able to beat a new interface control out of them =P
Apr 19 2009, 5:30 am
In response to Android Data
Android Data wrote:
Great, then. "No." Guess I'll have to find a workaround.

Flash might be an option. There are a lot of great, flash-based uploading utilities out there. I'm sure one must be open-sourced, or there may be a tutorial out there, that you could alter to include whatever you wanted.
Apr 19 2009, 5:52 am
In response to Android Data
During 430's design phase Tom and I talked about the possibility of having download/upload progress events trigger commands.

The main issue with this would basically just be that the events that would trigger any control updates are generated client-side, whereas most commands run server-side. It's possible for us to call .winset or such in that situation, but since that currently has no notation for including an arbitrary "argument" value into the command, that wouldn't suffice to set a bar control's properties. To properly parse the info into a format you want and show progress on a bar or in a display, you'd need a verb.

Short of that, we could probably opt for a hybrid solution where you could tie a couple of controls to the download/upload system and let the frontend deal with the rest. The downside of that is you'd lose control over how the data is formatted, and things like hiding or showing the controls would probably be limited to modifying is-visible. The upside is you'd still gain the ability to show it directly in your interface.

Lummox JR
Apr 19 2009, 9:13 am
In response to Lummox JR
Given the issues involved with even this, what would it take for BYOND to support client-side processing?

Couldn't you make some other format which can be distributed in the resource file? You would just have extra code files (.dmc or something). These are compiled into a .dmb file of their own, except this one is put in the resource file.

When a client logs into the game, it simply looks for the .dmc file in the resources, and executes it in the background.

It wouldn't have to contain all that much at first. Sure, it would need the syntax of DM, but couldn't you find a workaround given that .dmb files can already be interpreted by the client?

It wouldn't need any custom objects, at least not at first. Just predefined ones, like /client. The client object would have procedures attached to it that would handle things like these file downloads.

Most procs would not be included with this, but procs like winset() could. The client can then manage the whole system without having to create some kind of new control.

Even if this takes a lot of time, I think it would be worth it, just as interfaces have been. It might be a first step, but with this form of client-side processing a lot of requests can suddenly become very easy.
Apr 19 2009, 11:15 am
In response to Android Data
I've brought up the idea of client-side processed instructions before, and I think others have too. I think the general consensus is that it tends to be a great idea - But the implementation might be fishy. Personally I'd like a client-side script language that handles basic interface manipulation, for faster-than-1 tick handling and looped handlling of often-used tasks, such as a timer ticking down.

The amount of network traffic saved between having to update a clock once every second for 20 players and having to send a single instruction and let the client work off a pre-compiled list of instructions would be pretty noticable, I figure.
Apr 19 2009, 11:40 am
In response to Android Data
Android Data wrote:
Given the issues involved with even this, what would it take for BYOND to support client-side processing?

Considerable design work at the very least. With client-side processing there would be a real limit on what kinds of data could be worked on. For example, trying to access a mob var wouldn't be possible at all without some huge changes (above and beyond what it'd take just to do client-side processing in the first place).

Mind you I do like the idea of implementing some kind of client-side processing at some point, but there's a lot it won't be capable of. It would by necessity have to be a limited subset of the DM command structure.

Lummox JR
Apr 19 2009, 1:36 pm
In response to Lummox JR
Lummox JR wrote:
Considerable design work at the very least. With client-side processing there would be a real limit on what kinds of data could be worked on. For example, trying to access a mob var wouldn't be possible at all without some huge changes (above and beyond what it'd take just to do client-side processing in the first place).

A client-side processing language shouldn't really need to access any mob variables. Some variable access would be required, but that can just all be client-side.

The language would be capable of processing itself faster than the server-side, but it doesn't even need to have that at first. Just a very basic language which has some function hooks that you can build small stuff into.

Using a world or server object, it could be possible to poll the server for things. The server end would have a similar object. One calls the other, and the others' return value goes back to the one. And then you've got client<->server communication.

Mind you I do like the idea of implementing some kind of client-side processing at some point, but there's a lot it won't be capable of. It would by necessity have to be a limited subset of the DM command structure.

But do you really need a lot of design for it before you can even get started? Is it really needed to think about every possible scenario and design the full system, or can most of the design be avoided by making it as simplistic as possible?

Client-side processing would need the following:
1. local variables ("numbers", strings)
2. performing calculations (+, -, /, *, but also things like %, binary operations)
3. static objects (that cannot be deleted or altered)
4. procs (possibly custom?), hooks (client/proc/OnUploadStart(), client/proc/OnUploadFinish())
5. built-in procs (primarily winset(), possibly winget())

That's all it should need to

And over time you could expand it. Perhaps over then next couple of versions (after you get it stable) you could continue along the line:
5. Basic server communication (client-side world.Export() that either only sends to the server or sends to the server if the "address" argument is null
6. local object creation and manipulation (/savefiles)

Don't you guys have a community full of wannabe developers here? Exploit that! If we all pitch in we might be able to get a full design document finished.
Apr 19 2009, 6:08 pm
In response to Android Data
Don't you guys have a community full of wannabe developers here? Exploit that! If we all pitch in we might be able to get a full design document finished.

Without understanding the nature of the problem, their input would be entirely useless. To offer any meaningful design input you'd have to really know the way the backend handles things on a lot of levels.

In order for client-side processing to even be possible, a client would have to basically be tricked into thinking it was a server. This becomes more complex for cases where DS is hosting of course, since DS is both a potential server and a client; it'd then be necessary to spawn off a second process, or prevent DS from hosting at all. Then in this mode, the code would have to be provided some kind of separate var/proc structure as if it's running a completely different .dmb (or be given a copy of the .dmb's full structure) and it would have to know there are certain things it cannot do. Among other limitations, it could not modify world or global vars, create new atoms (datums might be all right), and so on.

I'm certain client-side processing can be done, but it cannot be done without great difficulty. This puts it in the realm of features we'd like to have someday, that take a backseat to more realistic improvements like graphical changes that impact a wider audience.

Lummox JR
Apr 19 2009, 7:06 pm
In response to Lummox JR
Lummox JR wrote:
I'm certain client-side processing can be done, but it cannot be done without great difficulty. This puts it in the realm of features we'd like to have someday, that take a backseat to more realistic improvements like graphical changes that impact a wider audience.

But aren't these graphical changes basically fueled by the notion of client-side processing? It seems that with this one, you do get the other.
Apr 19 2009, 7:11 pm
In response to Lummox JR
Consider a client-side language that does not access or care about DM variables at all. All it cares about are performing visual changes on the client-end, to the interface.

This means there is no need for anything except a protocol to recieve commands to execute pre-compiled function calls, that only ever execute winset commands and allow for simple conditional structures; it doesn't even necessarily have to return anything back to the server.

This would allow any sort of dynamic interface changes you want provided you can plan them out in advance, which, well - You can. As long as the function calls can take basic numeric or textual arguments and can have basic string/number comparison you've got enough to shave off a whole lot of communication in most games.

Consider this:
client.ClientSide("set_clock", "60")


And in whatever holds client-side stuff:
proc/start_clock(n)
    do
        winset(self, "clock_window.clock_element", "text=[n]")
        sleep(10)
    while(n--)


Vs. this:
client/proc/UpdateClock(n)
    do
        winset(src, "clock_window.clock_element", "text=[n]")
        sleep(10)
    while(n--)


As far as communication goes, you've just shaved off n-1 back and forth messages that are restricted to 1 per tick. Per player. I realize this lacks some power in that it doesn't fire off client-side interface events, but I don't see why that couldn't happen either - Doing that, you could react to interface events in realtime consistently. You'd also solve the whole row of feature requests that ask for clicking other areas of a window.

Of course, dream mode on I'd love to be able to bundle a DLL over to the client so I could react to interface changes with a UDP library that will communicate back and forth for me with protocol and variables that I declare - But thats probably an entirely different beast? You wouldn't have to worry about that being too hard to use, I'm fairly certain several of us would immediately jump on to create libraries for people to wrap common-use interface changes and a standardized protocol in.
Apr 20 2009, 4:45 am
In response to Alathon
You're talking syntax; I'm talking implementation. Coming up with a syntax for client-side development is simple, as is deciding to only support a limited subset of commands. Coming up with a way to run such code is highly complex.

Everything I said to PM still applies: You'd need to basically make the client into a server that can run DM code without acting serverish. The alternative is having to create and maintain a separate interpreter, which is more or less what the outdated .dms stuff does. Tom would never sign off on creating a secondary interpreter like that, which is just as well because I wouldn't want to write it. So the only choice is to have certain procs able to run in "client mode" and then find a way to actually pass the required information to the clients; or to compile a secondary .dmb outside the scope of the first, send that to each client, and still set up some sort of client processing mode where the existing server code could be put to work instead of reinventing the wheel.

Lummox JR
Apr 20 2009, 4:47 am
In response to Android Data
Android Data wrote:
But aren't these graphical changes basically fueled by the notion of client-side processing? It seems that with this one, you do get the other.

Graphical changes would require modification at the server and client levels, and any processing done by the client would be done via hard code. Improved graphics don't really fall out of generic client-side processing, and generic client-side processing isn't needed for improved graphical capabilities. The two concepts are quite unrelated.

Lummox JR
Apr 20 2009, 7:06 am
In response to Lummox JR
Lummox JR wrote:
The two concepts are quite unrelated.

While I agree that they do not directly correlate, I dare to disagree that they are unrelated.

Most icon procedures could be done client-sided to gain massive resources server sided, by sending the operation, rather than the resulting icon (both CPU and bandwidth, given only some simple changes per icon/send).


Something like a Minimap could be done without sending any additional information at all (if it only contains data visible to the user, or data that has been visible, assuming that the map isn't transferred as a whole in the resource file to begin with), but would grant for nice eye candy.
Apr 20 2009, 7:37 am
In response to Schnitzelnagler
Schnitzelnagler wrote:
Lummox JR wrote:
The two concepts are quite unrelated.

While I agree that they do not directly correlate, I dare to disagree that they are unrelated.

Most icon procedures could be done client-sided to gain massive resources server sided, by sending the operation, rather than the resulting icon (both CPU and bandwidth, given only some simple changes per icon/send).

I'm not talking about specific client-side processing, but general--as in, running procs. It's relatively easy to unload very specific operations onto the client (although mind you, issues we ran into with icons kept client-side icon processing from going into 4.0's first release), but what's being discussed here is really something more generic than that.

Lummox JR
Apr 20 2009, 9:28 am
In response to Lummox JR
Lummox JR wrote:
The two concepts are quite unrelated.

They're unrelated when you're talking about generic client-side processing, but this is BYOND. With client-side processing as it would be implemented, the /icon object can be manipulated on the client-side.

If you need a minimap, or you can't draw that control on your map because it forces it to run in software mode, you can draw it on the map instead. The priority of "make the Windows API work properly" could be moved near the bottom of the list, causing the idea "Port BYOND to other operating systems" to have more merit.

Even if you don't have multiple map elements, you can still stick everything into a single map element and draw everything you need on that. It would just take a little longer, but I'm sure people would develop libraries for that.

It's true that features like having built-in support for vector images would still need changes to both the server and the client to implement, but with client-side processing there's a feasible workaround available that doesn't slow everything down.
Page: 1 2