This seems kind of iffy to me, since the hub isn't arranged in such a way that it has parent/child server relationships. Servers advertising that relationship would have to authenticate it somehow, which makes things a little tougher.

Sorry, but where's the headache part? I genuinely don't see that.

A server is started using startup() with a parameter that says it should consider itself a child of the parent.

At the part where it advertises itself to the hub it sends along an ID that identifies the parent.

The hub stores the ID in a variable.

When presenting a server list you can now group by servers that have the same "parent ID".

When showing the main server you include all of the players in the child servers beforehand. If you wanted to be thorough you could query that list separately and present the players on the server and the players on the server+children separately.

There is one issue I can see and that is the potential issue of security: how to prevent people from abusing this feature to combine the player count of other servers?

I think that is easily resolved by having the hub check if the parent ID it received is hosted on the same machine (same IP).

It would even be backwards compatible: older games don't send the parent ID, so they'd have no parent (which is how it works now)

Is there something I'm missing other than planning/schedule issues? I really want to know if I'm being stupid or naïve with this suggestion.

Lummox JR wrote:

There's one issue to start with: you'd need to ensure a lack of ID collisions. That would imply using a hub-assigned ID for the parent.

What if the ID was the already-generated world ID that the hub uses for the BYOND.world.* format?

A same-IP check would, IMO, severely limit the potential for such a feature, since it might be desirable to host servers on different machines.

Just to get the feature off the ground, a same-IP check would probably be suitable for most needs in the beginning. Eventually, you'll have to have a model where both the parent is aware of its children and the children are aware of its parent, probably through some linking mechanism.

Given the nature of a feature like this, I don't know that you'd have to worry about building that linking mechanism into BYOND. It's not necessarily a bad idea to simply expose, say, world.parent_world and world.children variables that get reported to the hub and used for verification purposes, and let the developer decide how worlds can be discovered and linked together as parent/children.

One thing I'd like to add to this which goes off-topic is that this type of behavior ("it's non-trivial, deferred") is exactly the kind of thing that scares away potential developers (and thus potential new games, thus potential new revenue streams/income).

I'm still really really hoping that you'll work with us some more on crushing some of these specific issues. It's the only way BYOND is/was going to grow.

Audeuro wrote:

Lummox JR wrote:

There's one issue to start with: you'd need to ensure a lack of ID collisions. That would imply using a hub-assigned ID for the parent.

What if the ID was the already-generated world ID that the hub uses for the BYOND.world.* format?

That was actually my first thought, but it's too easy to get and therefore easy to spoof. It wouldn't work.

NullQuery wrote:

I know that there's already an ID assigned for every BYOND world hosted. For instance, at the time of this writing ID 1848259218 points to the Colonial Marines SS13 server.

I'm not sure if this ID is sent to the BYOND world in the daemon<->hub communication, but passing that along should be easy and has no security issues (as the ID is public knowledge).

The fact that the ID is public knowledge also means any world can simply claim it as their parent. A same-IP check would help in that regard, but it would also lock this into using that ID and therefore it'd be hard to break away to non-same-IP cases in the future. This is the kind of design decision that's bitten us in the butt before, so these days I plan out hub features in particular very, very carefully.

With the way I've laid it and looking at the request on a whole I don't see any way in which this could be feasibly abused, at least not in a way that couldn't be addressed if and when it occurs.

I'm not sure how it would be addressable. There'd have to be some kind of mechanism for a hub to proactively say: "No, this isn't mine." It seems like that's the kind of thing that should be built into the initial design, or else it becomes an admin hassle for the hosts, authors, and me.

In the worst case scenario there's a bug that allows worlds to masquerade as each other, which is an issue that can be addressed in the backend without requiring a new release of BYOND. Absolute worst case the hub stops accepting the new information.

I don't see how this would be a hub-only fix, if the design turned out to be exploitable. In the past such things have always impacted the software as well. This is why I insist on using a well thought-out design from the outset, because designs that were quick and easy have burned us in the past--especially for hub features.

It's a lot of man-hours to put into something that I think would be used by only one game.

Passing the ID to Dream Daemon and receiving the parent ID: 1 hour.
Modifying the hub to report players from child servers as well: 2 hours.
Modifying the website frontend to show players from child servers: 2 hours.

5 hours of work vs. the gratitude of one of your BYOND Members, who happens to have saved you at least 8 hours of work already.

That breakdown is completely unrealistic.

Modifying the software to alter the hub communication protocols on its end takes a certain amount of time, and that's after a design is finalized. For instance, I'd have to either find a message the hub is using to send info or I'd have to add a new one, add routines to access the data that was sent back, etc. More than 1 hour of work, and that's not counting the time investigating the messages and the flow (on both ends), nor the testing time after the hub has been updated, nor the time involved in getting a release out. Also, a change like this may need to be a major-version change.

Hub alteration is a stickier affair. Leaving out the aforementioned time investment in studying whether to add a new message or modify an existing one (since it applies to both ends), everything has to be compiled and tested carefully with both the software update and the old software. This is not a fun process. The hub gets angry when mishandled and therefore requires more fuss.

For this issue, the hub would also need to handle all the parent-child stuff, which means the addition of new queries and the modification of other queries. Those changes are not simple because they require either grouping or not grouping depending on the presence of an ID and a matching parent, whereas the existing queries can be run straight. The hub is a lot more rigid with its data handling than the site. (On the site, this process would be easier because the site gathers the records first and they're fairly easy to manipulate. The hub likes to pipeline things. For this reason it might actually be easier to run this as two queries, finding a way to string them together.) Part of this is assuming of course that the pager won't be touched, and that some of these modifications are to the data the hub presents to the pager.

The site part ironically is probably the easiest of all, since the way worlds are read from the hub is much more centralized and manipulating the query results there is fairly straightforward. In fact showing the child servers probably wouldn't be all that bad either, although as a first step that wouldn't even be necessary.

Ultimately we're talking about four different interoperating pieces of software that would need to be thoroughly tested with these changes. (Even if the pager isn't modified on its end, the results of the grouping on the hub end would have to be tested there.) Switching between these projects is also a pain, and requires significant mental "spin-up" time; a case like this would require switching back and forth several times over to make sure all the bases were covered, even after the initial study and design portion.

So the time investment is far greater than you make it out to be. I wouldn't say it would take a full week, but it's not the kind of thing I'd burn through in one day. Also it's often the case with hub and site changes that because they can be prickly, I'll work on them and then re-study the changes before I commit anything. I wouldn't dare do any less.

I don't see the problem here. Either the BYOND source-code is an even worse mess than I can fathom, or you don't want to do the work but you don't want to straight-out say it.

The former is certainly true, but I did actually say the latter; in my view the time investment is too significant for something that will impact very few people.

IMO it would make more sense for anyone who wants to group their servers to keep track themselves of which servers they're running, and display that appropriately on an outside page. Pager users would always end up joining the main server with this setup, and site users would probably tend to overwhelmingly favor the main server, whereas with a custom setup of your own you could rotate the servers or do whatever you like.

It's not that this isn't doable. I'm just having a really hard time seeing the utility of it, and making changes to the hub isn't something I do lightly; the utility has to be correspondingly high. In this case I see this maybe impacting one or two SS13 branches, not even most of them, and as many SS13 branches have their own sites, it seems like the grouping would be way easier for them to setup on their end.

big icon issue is still not fully fixed theres still some flickering happening from time to time on large monitors with large views

Never, I'm done reporting anything. Will just put it in the backburner like the Alerts/popups where movement gets fucked up. Since thats the new way of dealing with bugs :V

Sure, let me know when you get a 1080p monitor and a 2k monitor.

So, this issue... is pretty easy to implement. I've already laid down the exact steps to implement it. I don't know about the underlying frameworks, but I do know that you designed the BYOND Pager software yourself and unless you're far less competent than I think you are you'll be able to send an extra 8 bytes to the hub.

Security is moot. The worst case scenario is that someone claims their server is a child of someone else's. So what? They'd only be artificially increasing someone else's player count. Most people in this community aren't even capable of finishing their own projects, let alone working together with others.

If something does happen you've still got the same-IP option. Or you can turn off the functionality altogether until you find the time to look at it later. You'll get no objection from me, I'm happy enough that someone is still working on the software.

---

But that actually doesn't matter. I could argue this all night and you'd still be right. Implementing this feature could introduce a bug. You could make a poor design choice that would cause you more work later. That's true.

So instead I'll tell you what you're doing wrong, and the real reason you're not making thousands of dollars a week off of BYOND.

For the past 5 years I've been working for a small company that was founded at around the same time BYOND was originally founded. The key difference is that we're making money.

So you should know that if I'm telling you that this is the way you need to do this, then it's the way you need to do this. This isn't me talking, this is the years of experience I've accumulated at my job and its history.

And what I'm trying to tell you is this: the problem with BYOND, the reason you're scraping by on donations and ad space, is your rules and procedures. They work very well for a larger organisation, but it does not work at all if you're a small company, and it's an absolute disaster when you're the sole developer.

You're supposed to work faster, not smarter. You don't have the luxury of having the time to be smart. You need to implement features and get BYOND to the point where it can be presented as a product of 2016.

The biggest item on your to-do list according to your own announcements is the implementation of regular expressions in Dream Maker. This is a feature that should've been implemented 10-15 years ago AT LEAST and you've only now found time for it.

But that's the thing: you don't have the time for it. You need to implement this feature as soon as possible, because a BYOND Member asked for it. Not just a BYOND Member, but someone who knows what he's doing, and who might attract other developers to BYOND, who may in turn attract more players who become BYOND Members. I'm a rare kind of person: someone who has stuck around BYOND for years and years and is still drawn toward it like a moth to a light.

You have absolutely no idea who you're dealing with. At the beginning of this week I thought "hey, let's extend my postgresql database operations library with mysql and sqlite support, split it up, and open-source it". So I did. If our positions were reversed I'm sure that it'd still be in the planning stages, deciding how to go about implementing it. But I analyzed and came up with a design in a couple of minutes, and implemented it. I tested my work, and released it.

And just like you believe no-one (or very few) may end up using this feature, I'm not sure if anyone is going to use my work. But I did it anyway, because it's progress. It's a step forward toward my goals, one of hich is giving you less work and another which is contributing something good to the community.

---

Again, I'm really hoping you'll see this and that things change. The way everything has been going BYOND will die a slow death. I think SS13 is the primary reason BYOND is still relevant, and there are multiple projects already to port it to another language.

In the time it took me to write this message I could've been at least 1/4th done with implementing this feature already. And that's without inside knowledge of the BYOND source-code.