Should I make a bug report or page you about this to keep this thread clean? I can post tests on empty project. Projects with only a map, and other things. My stress test project would hit 30% at ~30 players where 3 were web client users.
| |
Actually there's already a bug report for this, so I'd suggest just posting your test cases there. May as well consolidate.
| |
Lummox JR wrote:
Actually there's already a bug report for this, so I'd suggest just posting your test cases there. May as well consolidate. Would this be the one I submitted already pertaining to something like this? The one I submitted dealt with rendering CPU. Edit: I found it here. | |
When are the check boxes going to be supported. They still aren't rendering in my game. Going to have to refactor my hosting options again because I forgot to check on that.
| |
Checkbox buttons already work; however they act just like pushbuttons. Radio buttons also display the same way, but do work as radio buttons.
If it's important that the button actually display as a checkbox/radio, I could add support for that. (I can see how on certain interfaces it might not be clear enough that the button is checkable.) I feel like it'd be better using something other than the regular browser input though, so it'd be easier to style. | |
Lummox JR wrote:
Checkbox buttons already work; however they act just like pushbuttons. Radio buttons also display the same way, but do work as radio buttons. Just finding a moment to start looking into some of my webClient issues. I took a closer look and found that my checkboxes had a black foreground and background. I originally did this so the checkbox background matched my black window. In order to get the webClient and the winClient to match, I ended up checking the "Default" Appearance option and then resized all my checkboxes so no background shows. | |
PopLava wrote:
Lummox JR wrote: ack! There's no check in the checkbox and clicking it doesn't toggle the image state to anything. Is the expectation for us to provide our own check image for toggling? | |
I don't know what the deal is but I'm having some trouble making a custom checkbox with images and a pushbutton. When I click the button, it calls the ToggleCheck proc and this is what I get. This happens in the WinClient.
false If I fast click the button, I'll occasionally get a true so my results look like this. false Those results suggest the button is changing the 'is-checked' state back to "false" on button-up. Fine, I can understand that since I'm trying to use pushbutton as a custom check-box. I'm wondering if it's even possible to use winset/winget calls to make a custom checkbox. I can't use pushbutton and I can't use checkbox since it ignores the custom images. I think I'll have to create a variable for each checkbox that stores the is-checked state. Perhaps my mind is fried and I'm just missing something which is likely. mob/proc | |
I ended up re-writing it and storing the state in code instead of on the UI. Made for a big ugly multi-conditional block of code but it's working and now the WebClient Checkboxes (custom images) look exactly like the WinClient ones. Still seems like there is an opportunity to improve this though.
| |
Is there a way to tell if the player is using the WebClient or the WinClient? I need to hide a control (Zoom) in my UI when a player is using the WebClient.
| |
Ah, perfect. Thanks!
From the help file: 'connection' is a read-only var describing the type of client that is connected. | |
PopLava wrote:
Ah, perfect. Thanks! > 'connection' is a read-only var describing the type of client that is connected. Noticing the help page for 'connection' doesn't call out what object it's a variable of via (client). | |
PopLava wrote:
PopLava wrote: > > 'connection' is a read-only var describing the type of client that is connected.
Technically it tells you it's a read-only variable of the client at the beginning. I noticed this last year but it explains what it is within itself in multiple places. Not sure if it's required to emphasize it anymore or not. Edit: http://www.byond.com/docs/ref/info.html#/client/var | |
I've got a few questions for you Lummox JR if you have time:
If we want to send custom data each frame and keep it lock-step with the normal map updates, is output()ing the data to a custom control sufficient? Are multiple output()s automatically batched together and sent with the rest of the data, or are they sent individually? When the server reboots, what's the preferred way for custom controls to clean up after themselves? Callbacks registered with setInterval() and requestAnimationFrame() seem to continue running after a reboot if not manually cleared/cancelled. The control's remove() function isn't called on reboot, so I've temporarily resorted to stashing the control object in a window property and cleaning up any existing version in create(). | |
DarkCampainger wrote:
If we want to send custom data each frame and keep it lock-step with the normal map updates, is output()ing the data to a custom control sufficient? Are multiple output()s automatically batched together and sent with the rest of the data, or are they sent individually? Outputs are just sent when they're sent. They happen independent of the map. However the difference in timing should be really minimal. When the server reboots, what's the preferred way for custom controls to clean up after themselves? Callbacks registered with setInterval() and requestAnimationFrame() seem to continue running after a reboot if not manually cleared/cancelled. The control's remove() function isn't called on reboot, so I've temporarily resorted to stashing the control object in a window property and cleaning up any existing version in create(). Your workaround sounds like a good solution. I agree that remove() ought to be called on reboot, though. Or maybe even there should be an onremove function. | |
Thanks for the info. If you could make remove (or some similar function) trigger on a reboot, that would be a bit more friendly. Then, so long as a developer implements the full interface for their custom control, they'll get reboot handling for free.
| |
Would it be possible to write to a file the output from a converted dmf -> dms skin? I'm imagining the uncleaned output is ugly, but it would be useful for finding errors in it and as a launching point for making a skin without having to start from scratch.
| |
To be clear, the server is constructing the map view, breaking it down into which icons to display at which locations, etc. So the webclient will use more processor on the server end than a DS client would, because the server offloads a ton of this stuff to DS and the webclient is a "thin" client. The biggest bottleneck I've tended to see there is when the view is very high, because it not only has to do the LOS calculations, but it also has to look at that many turfs. However if there are specific projects showing some inefficiencies, that's something I could look into.