So are you guys talking months, or weeks here? I'm assuming it'll be in a 'beta' or testing phase no matter what condition it's in when it's publicly released. So bugs are going to be expected.
This web client will allow us to do some neat things with Space Station 13 that haven't been possible before, so we're eager to get our hands on it. The ambiguous timeframe is understandable but frustrating.
Patience, young tadpoles.
You shall have your HTML5 in due time. | |
Biggs Mclargehuge wrote:
So are you guys talking months, or weeks here? I'm assuming it'll be in a 'beta' or testing phase no matter what condition it's in when it's publicly released. So bugs are going to be expected. Maybe you should try to clean SS13 up in the meantime. | |
Vrocaan wrote:
Maybe you should try to clean SS13 up in the meantime. The code isn't that much of a problem, but thank you for your concern. Once we get the web client we hope to be able to fix small problems like BYOND forcing every single thing in the game to run server-side. Which isn't that big a deal if you're making a Naruto game I guess. | |
We should have the beta out this week.
| |
Well there go any hopes of studying well now. I was on such a good start too.
Definitely looking forward to that. | |
Tom wrote:
We should have the beta out this week. "This week" is too vague of a deadline. We need a specific date and time for the beta release event. I also want to know what you'll be wearing that day, and if you will use only half of the seasoning packet when you cook your ramen due to sodium intake concerns, or if you'll just go maximum YOLO and dump the whole thing, welcoming your inevitable hypertension with the bravery of a thousand viking warriors. An event this big should be streamed to Twitch. Its time for the WORLD to see BYOND in all its HTML5 glory. | |
I also want to know what you'll be wearing that day, and if you will use only half of the seasoning packet when you cook your ramen due to sodium intake concerns, or if you'll just go maximum YOLO and dump the whole thing, welcoming your inevitable hypertension with the bravery of a thousand viking warriors. Oh my god. I just spat root beer on my monitor. | |
Fugsnarf wrote:
Well there go any hopes of studying well now. I was on such a good start too. BYOND beats future. *nods* | |
 | |
They don't need a hub entry. DD will print out the address the user can go to to play. If you do have a hub, the webclient link will show up on the hub page.
| |
My body is so ready.
| |
The first post mentioned that you guys would be working on single-player mode support for the web client. Any update on this for the beta, or is that still a feature to come?
| |
I'm so ready for this update. It's gonna be epic >:D
| |
That won't be in the first beta, but we'll get to it once the bugs are mostly ironed out. I don't think it should be too much of a problem. I had a basic example working a while ago.
| |
Alittle iffy with this, but It won't hurt for a change.
| |
In a .dms file, you insert the <byondclass> tag with a name attribute for your class. (It's byondprompt for custom prompt types. To use a custom prompt, you override byond.prompt.which(params) to parse the prompt params like type, choices, help, title, etc. and return the name of the prompt class to use.)
Within that tag, you have styles (those are universal to the whole game; they're not scoped), where you'll see each control gets a class "byond_[name]".
Then you have a script, which returns an object literal. (This can be wrapped in a function call, like (function(){...;return{...};})() for instance.) The object literal contains a few other objects, like config which includes config options that might be set by skin params, and their defaults; fn which can override the basic functions every control gets--most often output(), create(), and possibly content(); and winsetfn which can override the basic winset functions shared by all controls or define new ones. A winset function's name is in camelCase and it takes a value and an optional sub-control ID (e.g., grid coords) that can be passed to content(); values of null or undefined mean this is a winget, which should return a string.
After the script you'll have the elements of the control. The control itself is attached to a div that is set in your main .dms as <div id=controlname byondclass=classname>. control.top will point to that div. The first element you put inside it will be control.elem (set in create() unless you override), and control.content() will point to that by default as well. For anything in this section with an id, the id will be removed so there won't be conflicts in the skin, but control.ui[id] will point to that element; so for instance control.ui.myinput can be used to point to <input id=myinput>.
I've been working up more comprehensive docs on all of this, but that should be enough to get anyone started, and function names and such you don't know can be filled in later.