Jan 11 2015, 1:59 pm
In response to Sir Lazarus
|
|
Lummox JR
  |
I like that concept. However, the ckey is not known at the time the splash screen would be requested. Only the IP address would be known for sure. An easier option might be to make this a var, or--better still--to build it into the .dms format. A .dms-format splash screen setting might have the advantage of allowing for other settings as well.
|
Cloud Magic wrote:
Are stylized alerts still on their way? (if not already implemented) Stylized alerts are already doable. In a .dms file--even if you don't use a .dms skin and let the server translate a .dmf for you--you can override the styles used in the alert prompt, which you'll find at the top of alert.dms. | |
Doohl wrote:
Just curious, where do you even go to view "alert.dms" or any of the default dms files? In your BYOND install, relative to the bin directory they will be in the ../web directory. This is a great resource for anyone wanting to create their own controls, as the default controls and prompts can be studied to see how they work. | |
I went and created my own controls, designed an entire game's UI around the webclient...
All without even realizing there was all this existing code I could've studied, instead of spending hours just fiddling with stuff until it worked. I am an idiot. | |
I'd love to see some of the controls you've been working on (as I'm sure would a lot of other developers). The little I saw of your code in progress looked pretty exciting. It'd definitely be worth making a few posts in T&S.
| |
Just to be clear, how many developers are working on the web client?
| |
Working on? Lummox and Tom. Working with? Impossible to tell until things start being released for it.
| |
Lummox JR wrote:
Several ways. If I use browse_rsc() once, is it safe to say that browse_rsc() does not need to be called anymore regardless of which client is attempting to access the files over http? | |
Doohl wrote:
Lummox JR wrote: For the moment that is true. However, I may change that in the future. I don't actually like that the browse_rsc() names are global, because that's not consistent with DS's behavior; it was just far easier from an implementation standpoint. I would suggest always calling browse_rsc(), just like you would with DS clients. It won't hurt anything to do so and it's the safer long-term strategy. | |
I would appreciate it if there were an alternative to have the names be global since I am currently processing a lot of different images every time a client enters a server.
For instance, I want to associate a type (ie, /obj/item/sword) with an image and be able to allow the client to view the image on a popup menu via something like "
<img src = "/obj/item/sword">
In order to do this, I have to loop through every item that I want to assign an image, which can end up being quite a lot. I'd like to do that preferably when the server starts up, not every time a client enters. | |
I don't think it's such a good idea for me to stick with the global setup over the long term. DS doesn't work that way anyway, so a one-time setup would work with the webclient only. Plus I doubt that loop would ever pose a serious performance problem. However, I should note that you can access a file by name.
Also I should add that it's really, really bad practice in HTML to put spaces around the = sign between an attribute and its value. | |
I know, it was subconscious though and I don't actually use a single img tag anywhere in my code. I've got the unpopular opinion that you should never use an img or table tag.
| |
You use a table tag ONLY to display tabular data. Anything else is wrong, so if you stick to that you're fine.
| |
(This might have been answered already)
Q:Will the web client (eventually) be able to support single player? As a hobbyist, all you really need to do to get me to start publishing games on places like Newgrounds is to give me a single player web client. Dream maker can already create some good single-player games.. Q:Exactly how, will hosting work on the web client outside of the BYOND website? I also think multi-player would be great but I can't figure out how I would support the server load those type of games usually get. I don't have a clue how to handle a server load more than 50+ people. On BYOND, Users can choose a server that isn't loaded or host their own, and this is my primary concern with multi-player web client outside of BYOND, how would I get those players where they need to go? | |
IchiroKeisuke wrote:
Q:Will the web client (eventually) be able to support single player? Simply put that's just ostensibly impossible. | |
IchiroKeisuke wrote:
Q:Will the web client (eventually) be able to support single player? The webclient requires a server running Dream Daemon. That part is set in stone. The webclient is a thin client only; it does not take a .dmb and .rsc for example and try to run them in JavaScript. Q:Exactly how, will hosting work on the web client outside of the BYOND website? As of right now, the webclient uses our login system (though it allows for guests). If you want to put a webclient game on another site, all you need is an iframe; the embed code for it is provided by Dream Daemon when you host your game. The way this works is that your site will be on the "outside", inside its iframe will be a page on our site that acts like an invisible layer, and inside that is the game itself. Our layer handles the login stuff as well as pinging the game to make sure it's available to play. If load-balancing is a concern, there's no automated solution for that at this time; the way I would recommend would be for your outer page to have some way of knowing which servers were available (e.g., PHP querying a database or some such), and alter the iframe embed code accordingly. | |
I've noticed some high CPU readings that increases exponentially as more people join the game.
Q: What are your plans for getting through this wall? If the only thing it works with is multi-player, I can see some issues here since the CPU readings apparently increase as a result of the rendering system. Perhaps there's a bug in some external source, or it's running something individually for each player rather than for all players? I don't know much here, but I really do see this being an issue as I have tested it on multiple view sizes. Especially during my Stress Test a while back that got false readings as a result of the web client issue. | |
Xirre wrote:
I've noticed some high CPU readings that increases exponentially as more people join the game. I have not observed exponential increases with higher player counts. Linear increases are to be expected, however. Very little of the code in BYOND could potentially cause an O(N^2) loop based on the number of players. Typically, the only place you'll see that kind of increase with players is that with more players on, each one performing an action like speech that then has to be sent to all the other players, this has the capacity to act in a mildly O(N^2) way. But that isn't any different for DS vs. the webclient. The server, when hosting webclients, basically does the following: 1) It listens to requests from the clients, so it can deliver resources, controls, and of course the compiled Dart code of the webclient itself. 2) It manages the statpanels and maps for each client, and sends full updates or diffs as needed. There are various other housekeeping tasks that aren't worth mentioning here, but effectively all of them scale linearly. If the only thing it works with is multi-player, I can see some issues here since the CPU readings apparently increase as a result of the rendering system. I'm not sure what you mean by "rendering system". If you mean the use of Canvas2D vs. WebGL, that's client-side only and has no impact on the server code at all. Then again when you mentioned CPU usage you didn't clarify, and I'm only assuming you were talking about the server. | |