allow third party software to not spam the in-game console
-
I created a PR for backend-local that would expose the
hiddenattribute used here to the/api/user/consoleendpoint. This would allow third-party apps to use the API without spamming additional lines into the console they use to debug in the client. I know of multiple TamperMonkey scripts and other apps that would benefit from this. Thank you for your consideration.
-
As it stands now I know people who explicitly use the external clients because they allow for filtering out the garbage that comes from the console api requests. Being able to mark the requests as not requiring an output to be displayed would be amazing.
-
I'd like to step in here, not just regarding the PR itself, but regarding something of a pattern I'm beginning to see emerging-
I like it. The functionality is already there, and anything to reduce the signal-noise ratio of console spam is always welcome, especially with third-party stuff that's going to be running a lot- If I need to see that data, I can just unsilence it.
I'm also not entirely certain why the PR was closed- Allow me to quote directly:
This property is not supposed to be exposed to an end user, it's for internal usage. All console commands sent on behalf of the user have to be displayed explicitly, even those sent by third party tools.
@artch I'm afraid I don't entirely understand this reasoning. Why do console commands sent of behalf of the user have to be explicitly shown, and why is it unacceptable to allow us to silence them? The basis of this argument seems to be that it isn't being used the way that you want it to be, and is therefore wrong. Can you explain your reasoning behind this decision?
The PR appears to have a fair amount of community support behind it. Broadly speaking, this failure to respond clearly is extremely concerning. I also have concerns that this type of response may deter the efforts of some of the developers who have been submitting PRs and doing a great deal of work on Screeps over recent months. If nothing else, I feel like they need to understand why these decisions are being made so they can better direct their efforts and avoid wasting the time of everyone involved, especially given the use of community developed tools like LOAN in World Reviews and suggesting ScreepsWorld to those looking for Screeps related content.
Personally, I've recently cancelled my sub due to concerns like this- I like Screeps, but I don't understand the reasoning behind many decisions like this, I don't understand where the game is meant to be going, and I can't justify blind faith. The last major update was regarding the Contract system (which sounds like a cool, if potentially very dangerous and flawed system, depending on the exact implementation), but there's no roadmap, and the only answers I get from CMs when I push for something is that Power Creeps might be getting worked on and put into a less terrible implementation, but nothing solid (and frankly, it smells like damage control).
While I dislike the fact that the PR was rejected, I'm much more concerned about the communications issues between the players and the developers that it highlights. The lack of updates on the world (possibly made more difficult due to shards, admittedly), the lack of any sort of real roadmap, the lack of clear answers, these all degrade the communications networks between the community and the developers. Given how much sharding has isolated the community, with some alliances going so far as to essentially abandon the public slack, this is an issue that I don't think anyone can really afford.
Thank you for your time.
-
Agreed, @Knightshade. When I said, "Thank you for your consideration," at the end of the original post here, I was legitimately expecting consideration with an explanation of why the devs designed it to be private, why they would prefer not to open it up to the external API and allow time for conversation between the devs and the community, as opposed to a simple no with an explanation of how it works now and immediately closing it.
Although it was effectively a 1 liner, I still did my due diligence, testing on a private server and had it vetted by a frequent 3rd party dev prior to posting. The PR being closed without an opportunity to discuss it felt like a slap in the face when I woke up this morning. It's unfortunate that my efforts to make the server better for the community third-party developers were immediately shut down and I would like an opportunity for more of the community to speak, and see if the devs would reconsider after listening to the community.
-
I think part of the problem is that this project is still undergoing a cultural shift from being a purely internal project to an open source one.
With an internal project decisions are made by a conversation with a few people directly, and it's fair to assume most people will have a good idea of how the codebase works.
With an open source project more discussions need to happen in the open, and lots of times users are not going to be familiar with the codebase. That lack of familiarity requires a community to support things- for example, I never would have been able to submit the PRs I wrote without assistance from @ags131 and reviews from other community members.
I do think the admins are making an effort. Reaching out to the community for development on the Tombstone and Source Keeper functionality features was a huge step in my opinion.
That being said, it would be great if pull requests didn't take as long to process, and if in cases like this PRs weren't closed immediately without a bit of discussion. As long as the admins are still open for discussion I don't think people should be too fixated on what the current status of the PR itself is, and this forum might just be a better place for it.
As for the relatively long process between making a PR and getting it merged I think there's a huge technical burden in the way that we haven't talked much about- the lack of a test suite. I know for my own open source projects I don't even look at PRs which fail the tests, and the projects which don't have tests are orders of magnitude more difficult to manage. This might be an area where the community can step in and help, if the admins can put some infrastructure in place (even a Circle-CI test setup that only looks for syntax errors and code formatting would be great to start with).
-
@tedivm, I wasn't trying to imply that they weren't doing better than they had previously. The Tombstones and SK functionality you brought up are perfect examples of where it is improving. And yes, @ags131 was who I was referring to when I mentioned getting the PR vetted before submitting. I also fully agree with the need for automated tests for PRs too. That could really help the devs with checking PRs from outside of the dev team.
I like to think that the culture is improving, with the adjustments to
.spawnCreep()getting merged in, and other community PRs, but I still feel frustrated that they just closed my PR without a discussion especially when other third-party devs were receptive to the change too. Perhaps I'm being overly sensitive about it, but I think others would probably feel the same way.
-
I'm also curious why the PR was rejected, citing it being an internal property gives us no context or reason on why it couldn't be exposed other than it that it wasn't the intended purpose. I'm not objecting to the PR being closed, in the end, you the devs decide whether stuff gets merged in. We would just like to hear reasons and possibly be able to discuss why they shouldn't be accepted so we can better understand the direction to go with future PRs.
I'm occasionally consulted before some PRs, and usually try to considered a few things before answering, such as what pros and cons are there to them? For this one its fairly simple:
Pros:
- It doesn't break compatibility with anything else either as far as I can tell. It doesn't seem to have any effects other than not submitting a result when processed
- It wouldn't effect the current client at all,
hiddenwould be optional and default tofalse, thus requiring nothing be updated. - It gives API users the option of suppressing the empty results in the console, which means people making their own control panels and such can have macros or buttons to trigger console commands without spamming the console with usually empty results.
Cons:
- None, other than requiring what is likely a one line update to your internal backend
-
We're not against this feature in general, we're just against this PR as a way to handle it. The console UI is going to be revisited soon, we'll add some filtering functionality there. You'll be able to filter out console output from the specific auth tokens (or any tokens at all).
The choice should be given. But to the user, not to the tool. The user should be able to hide unneccessary console output. But they should also be able to see it if they opt-in for it, for debug/security purposes. If this PR was accepted, then the tool could make its activity totally invisible to the user. We can do better, and it's on our backlog. Sorry that I didn't mention that in the comment, I didn't realize other people are watching it, and we really don't have maintaining resources within the open source project to explain every decision made in the past (
hiddenproperty was omitted on purpose there) to every single person asking a question.
-
the lack of any sort of real roadmap
We've just finished our current roadmap. It took 9 months, but we're pretty happy with the results. The new roadmap (regarding Power Creeps, and then Screeps Arena) will be presented very soon. Believe me, this is not damage control, we'll have something ready to show in the next few days (hoped for last week, but alas). And the last Monday we had a meeting in the team to figure what will be our development focus in 2018, and laid out some new big projects, this is why CMs are so excited about this. Stay tuned!
-
@artch I'm glad that the console's getting revisited soon. The PR was based on the assumption that the user would have the choice when configuring the tool. I don't know anyone using 3rd party tools requiring tokens that they do not host for themselves. But yeah, I see your logic now. Thank you for letting us know
-
@artch 10/10 community engagement there, thanks for the updates.
