Keymaster quality of life improvements

[IMS-Network]

Dark Mode

Please add dark mode to the Keymaster website
It should be a standard when making websites.

Update Notifications

It would be nice if we would have a notification system when a script gets updated.
also displaying the current script version. and as @menkzy suggested adding the date:

[Keymaster/Tebex QoL] Script Last Updated

Hello, It would be nice if the Purchased Assets page had a column for when the script/pack was recently updated. Would help server owners a lot with when their scripts have had an update or hotfix. A good example would be subscription based packs, such as Gabz maps. Small mockup; [firefox_KrhNKWgHe7]

The version is set by the script developer, this will help us (users) truck server scripts and keep them up to date.
also maybe adding an option to get emails when a script got updated.

Script Sorting & Search

Adding a search bar if a user has more than 10 purchased scripts, a simple indexing by script names.
this feature will help users that have a lot of “granted assets”, also this can be added to the “created assets” for developers/users who sell/have more than 10 scripts.

Sorting

A-Z, Z-A, by updated date, by License received at date or even size.
This goes with the searching future, it will allow users to organize the Keymaster’s “granted assets” library if they want to find something.

Script Orgnztion

Adding tags for scripts, for example MLO, MAP, UI. developers or asset creators can add tags to categorize their scripts, the end user/buyer should be able see tags next to the script.
This will give everyone gets a better understating of their scripts and how to manage them
in addition to this, adding the tags to the sorting system can help users better locate a specific script.
Developers or asset creators can add tags to categorize their scripts while adding them to “created assets”

KeyMaster API

As @Beke_Rugos posted, an API(update) would be helpful with the new additions that are proposed here
API can be useful to integrate Keymsater into discord bots, websites, automation, and much more.

API for uploading resources to keymaster

I think some resource creators would welcome a feature where people can use a REST based API to upload a zipped asset to be processed to be encrypted using the FiveM escrow system, removing the hassle of going to the keymaster page every time they want to update their resource. A use case I could imagine for this is CI/CD, or any automation.

Usage Examples

• Send notifications in a discord channel when a script gets updated
• Activate an automation when a script gets updated to downlode it and updated the server
• Request script data (name, tags, date)

Old Versions & MultiDownload

While this would require storing a lot more TB of data, it can be useful for the server owners… in case of bugs and problems with new scrip updates
this suggestion adds to @dkden7e.dev

[Keymaster] asset versioning + multiple simulteneous downloads

Hi. I want to suggest the following features to be added to Keymaster: Asset versioning with the ability to add version numbers + changelogs, the ability to remove or keep old versions by asset creators, and the ability to download enabled old versions by asset owners. Ability to “download all” and/or, even better, download many of the owned resources at the same time (“download selected”). Thanks in advance.

While I think that having the ability to download all the scripts at the same time is stupid, downloading 3-5 assets at the same time can be a nice feature.

[nta]

Interesting ideas, but a little bit short-sighted: sure, adding all of these would work, but it’d be a lot of effort, and with a little more effort we’d have a much more ideal solution anyway than something that’d just cement the current hodgepodge solution.

Anyway,

@IMS-Network

Please add dark mode to the Keymaster website

Not likely until the site gets redone entirely. However, you can just use a user style to have a ‘dark mode’.

@IMS-Network

It should be a standard when making websites.

If it ‘should be a standard’, it should be such in browsers, not somehow expecting everyone to somehow figure out a correct color scheme for such.

@IMS-Network

It would be nice if we would have a notification system when a script gets updated.

Not going to happen - there’s going to be a new system for managing both paid and free assets in the future, including handling updates in a cleaner, more integrated way. Adding to the current system would be redundant wasted effort, and ‘notifications’ on update would be handled in a unified way in the new workflow, plus would auto-update if enabled.

@IMS-Network

Adding a search bar if a user has more than 10 purchased scripts, a simple indexing by script names.

Perhaps.

However, this would add complexity to the current frontend which already needs redoing, and the new asset subscription system (which would be tied to the new asset publishing system) would need this anyway.

@IMS-Network

Adding tags for scripts, for example MLO, MAP, UI. developers or asset creators can add tags to categorize their scripts, the end user/buyer should be able see tags next to the script.

This will be solved by the new asset publishing system, doing it in some half-assed way doesn’t make sense.

@IMS-Network

an API(update)

Not going to happen, this has to be done at the same time as the new publishing/consumption system (where you’d also not need to download updates manually anymore, so publishing updates automatically would be less of an annoyance to users as well).

@IMS-Network

• Activate an automation when a script gets updated to downlode it and updated the server

… this should be a built-in feature, not some ‘API’ where everyone is expected to make a half-assed solution.

@IMS-Network

• Request script data (name, tags, date)

Not going to happen until the new publishing system, again.

@IMS-Network

Old Versions

Again, will be solved by the new publishing system, whenever that happens.

Ability to “download all” and/or, even better, download many of the owned resources at the same time

Same for this, also going to be solved by the new publishing system, as you’ll just be able to subscribe to a (set of) releases directly without having to manually download and reupload downloaded resources.

Also tagging @frenzy-renegade as he might know a bit more about these plans, and might want to know this is a recurring request.

[ChieF-TroN]

Please no auto download of resources, that is intrusive, and can and will cause issues. Countless times I have to make an edit to scripts to fix for my needs and if that overwrite my shit, I would be pissed.

[xseba360]

@ChieF-TroN

Please no auto download of resources

I agree, this may cause more harm than good. Unless there’s a specific configuration of the theoretical auto-updater, people are going to end up having their edited script and/or config files overwritten. Perhaps something like a .gitignore file and an overwrite prompt? I don’t know.

@nta

Adding to the current system would be redundant wasted effort, and ‘notifications’ on update would be handled in a unified way in the new workflow, plus would auto-update if enabled.

So… This sounds like the basic concept Steam Workshop. There’s a wee bit difference though.

Stuff like vehicles/objects/peds/map mods don’t really require any changes to the files provided. Well. What if someone wants to edit them? If they’re not encrypted by the keymaster, one could just edit them and copy them over to a different resource (but that defeats the purpose of having an auto-updater in my opinion). No biggie.

The difference is with scripts/code. As far as I know the main idea behind the keymaster is to allow people to sell stuff on Tebex and not have it available to download for free on some third party website in a matter of minutes. So the solution was an encryption system. Steam Workshop on the other hand? No way to sell/purchase assets - No need to encrypt them.

So, asset creators can selectively choose which files are not encrypted (to allow for config files to be stored as .lua files for example or even just opt to not encrypt any files at all). Since people can edit these files, they most likely will. And what’s going to happen when there’s an auto-updater with no overwrite prompts and such? Their stuff is going to get overwritten. Custom NUI assets (js/css/html), any configs stored in the resource directory or just simply code edits - gone. Imagine the chaos from confused server owners in “FiveM Client Support” category .

There’s also some other things that would have to be taken into account. For example: Currently - asset creators can put multiple resource folders into a single .zip file. Let’s say a server owner only wants one of the resources from the .zip file. What happens then? I would personally really dislike the idea of having to put EVERY SINGLE RESOURCE FOLDER into a separate asset on keymaster as this would force me to maintain 100+ assets instead of about 20. Not to mention the (currently) utterly tedious process of updating multiple assets to the keymaster at once and (currently) literally no reliable method to automate it/integrate with CI/CD (like GitHub Actions for example). As mentioned here earlier this year:

@xseba360

if only that pesky cloudflare anti-bot page did not get in the way, it could have been automated even without a REST API… but sure, a proper API would be nice too

Perhaps a solution to the auto-updater overwriting files would be to integrate it with txAdmin? What do you think about that? You open the panel, go to the resources tab, see all of the resources available, currently installed version, latest version and release dates. A button to manually update only a selected resource from list. Prompt with a changelog. Perhaps a on panel login prompt could be displayed? “Hey, since last time you logged in to the panel, these resources have been updated: foo, bar, baz. Would you like to update all of them - View changelogs/Yes/No”.

Not sure if there’s a better thread existing for this but I’m just trying to do some brainstorming here.

[nta]

@ChieF-TroN

Please no auto download of resources, that is intrusive, and can and will cause issues.

Before getting scared about some weird use case not being covered, note that this is covered: auto-update would be optional.

Also, ‘editing scripts’ is a bit of an odd use case born out of ‘badly-written scripts’, and we’d prefer scripts to not need editing in the first place as people’d make them in a configurable way, and, of course, auto-updating would be disabled (or use a diff tool - probably asset subscriptions would even just add a set of embedded git repos, similar to how Steam’s configuration data is actually a backing Perforce repository) if anything is edited compared to the initial download, ever since the concept of auto-updating was first thought of, diffing user edits was a core priority, and it somewhat expresses a very weird distrust if you assume we don’t think of the most obvious concern there.

‘Noooooo, no auto-update, please!!!’ is a weird response to potential issues that are extremely easy to cover for, and are also a leftover of the ‘old way’ of doing things which we are so valiantly trying to replace with something less error-prone, because it’s somewhat evident that the way resources are delivered now is very easy to confuse a newbie with.

It’d be preferred if instead of everyone trying to worry about things that aren’t even remotely close to set in stone yet, and then ‘brainstorming’ on top of small mentions, adding complexity in the process, there’d be some trust here in that we do care about these use cases, and, when the time is there, and we have actually covered these specifics, will have specifics laid out further for you to comment on.

This is exactly why none of these little suggestions from this and prior topics are implemented: each single suggestion can and will lead to some edge cases, and then thinking of a solution to balance out the edge case (e.g. an API to publish assets would need a way for users to be aware of updated assets, but then you make such a notification system, but then users will get confused about what to do with notifications, etc.) which only adds more potential edge cases and will again reinforce the current style of constantly balancing between half-implemented solutions, running from fire to fire to put out the latest edge case scenario.

Again, future implementation ideas are mainly based on the question of ‘how can we make things hard to impossible to get wrong by making it easier to do the right thing’, while not alienating existing users and their hodgepodge workflow they’ve built on top of the current systems, and not entirely breaking the existing ecosystem of released content. Building more crutches on top of the current methodology of server maintenance has its limits, and I believe this has already reached them years ago given the amount of user error that’s going around, the amount of weird ‘server packs’ containing ancient content, the anything and everything.

tl;dr: just wait, don’t get worried in advance, and yes we are aware of what you’re saying and reiterating it doesn’t really help at all

[nta]

As I’m bored enough anyway, I’ll respond to the other message as well, mainly pointing out a bit of short-sighted thinking - ignore this if you so need, it’s mostly useless rambling:

@xseba360

I agree, this may cause more harm than good.

‘Just don’t make things easier, it may be bad’ - ‘yeah I agree!’. Useless and non-constructive.

@xseba360

Unless there’s a specific configuration of the theoretical auto-updater, people are going to end up having their edited script and/or config files overwritten

Why would this be based on, or solved by some sort of ‘configuration’?

Also, ‘config files’ are an archaic concept which shouldn’t exist inside resources, convars exist for this - and yes, we are aware existing resources do use such a concept, but again, this can be solved in various ways.

@xseba360

Perhaps something like a .gitignore file and an overwrite prompt? I don’t know.

‘Overwrite prompt’ shows a shortsighted idea of how this would work at all. Yet, you seem aware of Git - have you ever noticed how Git has a concept of an interactive merge, and it also ‘auto-merges’ text files that changed?

These same constructs can be easily automated and reused for such an ‘update’ feature.

Another sign of this same view is below:

@xseba360

Currently - asset creators can put multiple resource folders into a single .zip file.

In this implementation, .zip files either wouldn’t exist, or be only a high-level construct used for submission and ‘manual downloads’. There’d be no scenario where this update logic would exist based on ‘automatically downloading and extracting a .zip file’, as that’s just outright stupid for the reasons you describe.

@xseba360

and copy them over to a different resource

Yeah, overrides should be in a different resource, since they’re not the original resource anymore.

In fact, ideally (and not just for the ‘auto-updater’, same goes for the concept of client-side cache reuse as it has been implemented since 2014), resources would be immutable, and resource authors would make their stuff as to allow for that… yet now we’ve got some ecosystem where users are ‘expected’ to edit a ‘config script’ which will invalidate the entire cached resource leading to a lot of download waste.

@xseba360

but that defeats the purpose of having an auto-updater in my opinion

Why would putting edited files in a proper place, which would simplify the work of ‘an auto-updater’, defeat the purpose of an auto-updater’?

In fact, why are opinions involved here at all?!

@xseba360

the main idea behind the keymaster is to allow people to sell stuff on Tebex and not have it available to download for free on some third party website in a matter of minutes

This shows an odd understanding of ‘the keymaster’. ‘The keymaster’ is solely a thing to assign a server a persistent identity, anything else is just added to this because it happens to be the service that handles server identity.

Asset delivery functionality there was merely added to solve a need that started to exist when we (slightly lacking foresight ourselves) started allowing paid assets in the releases section, and people started making weird broken custom ‘licensing/obfuscation systems’ and hiding malicious content. It, in itself, is a half-assed solution to a sudden edge case created by an earlier half-assed solution.

@xseba360

Since people can edit these files, they most likely will.

See above - people shouldn’t ever have to edit stuff. Make the right thing easy, and people will do it over the ‘wrong’ thing.

The rest of that argument is based on the simple view of ‘zip files’, again, though, and also assumes only paid/licensed content will be used in the new system.

@xseba360

Steam Workshop on the other hand? No way to sell/purchase assets - No need to encrypt them.

In fact, ‘encrypted assets’ simplify the issue you’re raising here since such files are immutable by definition.

@xseba360

Custom NUI assets (js/css/html), any configs stored in the resource directory or just simply code edits - gone. Imagine the chaos from confused server owners in “FiveM Client Support” category .

… this almost sounds like a threat - ‘don’t even dare doing this because you’ll get more support hell, which you hate, right?’

Again, new systems are first and foremost designed to reduce user confusion by making it easier for users to do things without getting themselves into a weird bind.

And, again, resource authors should step up their quality and make stuff that can be customized without editing files in the resource, like in any other extensible application.

@xseba360

Not to mention the (currently) utterly tedious process of updating multiple assets to the keymaster at once and (currently) literally no reliable method to automate it/integrate with CI/CD (like GitHub Actions for example).

See, again, the point where this will be an entirely new publishing system where this specific user expectation is already handled by design without it being a post-hoc hack.

The ‘pesky cloudflare anti-bot page’ exists exactly to prevent users from making weird hacky solutions that we then have to deal with the consequences of.

@xseba360

Perhaps a solution to the auto-updater overwriting files would be to integrate it with txAdmin?

Why would you think this isn’t already planned?

Any such system would have a graphical frontend to interactively resolve stuff, both in FxDK, txAdmin, the in-game ‘start a small server for your friends’ page, etc. - this bit is again a sign of thinking too much in the existing framework of ideas.

@xseba360

Perhaps a on panel login prompt could be displayed? “Hey, since last time you logged in to the panel, these resources have been updated: foo, bar, baz. Would you like to update all of them - View changelogs/Yes/No”.

Somewhat, see, again:

@nta

and ‘notifications’ on update would be handled in a unified way

There’s a lot of thoughts going on internally regarding unified notifications for various server stuff - not just ‘on panel login’, but way more seamless ideas.

Also, again, I’d like to note that any new workflow will be entirely optional for y’all who want to build your own workflow for whatever reason, as we’ve already seen how attached y’all are to existing ways of thinking, and anything software-related that breaks or removes old workflows is a good way to receive hate (look at every Windows update, lol).

There’s a reason for my initial dismissive reply to this request, and that’s that while the ideas are well-intended, they’re again just entirely short-sighted and will just lead to more future fires to put out, which is already the main issue with this project, everyone is running from fire to fire to put out, which is extremely exhausting, as is having to justify every decision or idea as people seem to respond out of some odd fear, while people at the same time expect things to move ahead, often in conflicting ways.

[ChieF-TroN]

@nta

Also, ‘editing scripts’ is a bit of an odd use case born out of ‘badly-written scripts’,

Its not an odd use case. You clearly have no idea what is being sold on these tebex stores. Its actually quite routine to have to do a bunch of edits.

Hell out of all the resources i have purchased at this point I’d say there is only about 5-10% of them where I dont have to do anything. And I’m using the latest qbcore, and purchasing qbcore specific resources. So its not even like I’m using some unpopular or unsupported.

The level of code quality WILDLY varies on these tebex stores, and you dont really know what your getting until after purchase, and then if the resource is scuffed and the dev that is selling it is not helpful you just wasted your money.

If you’re going to make an auto-updater quality control on resources needs to be done. But thats not going to happen as that isnt really feasible.

But I’m sure anyone that has purchased several resources can tell you, is that majority of the time theyre not just plug and play, nor are they bug free.

[nta]

@ChieF-TroN

You clearly have no idea what is being sold on these tebex stores.

… yet, I do, and you quoted it even: ‘badly-written scripts’. Similarly, to reuse your own words, you seem to ‘clearly have no idea’ what I wrote above, as these plans are not at all related to ‘tebex stores’ only, but a broader plan that’d exist alongside a project to increase the average quality of resources and reduce the amount of edits users ‘have’ to do to get things working.

Similarly, I’m not sure what is with your preemptive hostility, and I’ll therefore refrain from replying to you any further, and I’d implore you to do the same, as there’s clearly an impedance mismatch here.

[ChieF-TroN]

There is no hostility, just when you make a blanket statement that its an odd edge case that edits have to be made, at least from my experience that is the norm, and not just an edge case. That was the only point I was trying to make.

So, to agree with you there is a high amount of ‘badly-written’ scripts in this ecosphere. And if your goal is to raise the overall quality of resources while that would be amazing, I’m not sure how’d you’d be able to achieve that.

As always I do appreciate the work that you do, and was never meant to come off hostile. Just concerned.

[xseba360]

Thanks for the reply.

@nta

Why would putting edited files in a proper place, which would simplify the work of ‘an auto-updater’, defeat the purpose of an auto-updater’?

Well yeah, if you take them out of resource A, and put them in resource B and edit them, then disable resource A, wouldn’t you miss out on all the updates to resource A? One would have to check for updates to A manually? And would it even work if let’s say a single essential file was encrypted with the asset protection?

@nta

Why would you think this isn’t already planned?
[…]
There’s a lot of thoughts going on internally

Well. Maybe there’s a reason behind this which I am unaware of. As long as these thoughts are internal and not discussed openly on forums here or maybe even GitHub/Trello/anywhere else, nobody can really tell what’s being/will be planned/worked on. Can’t really tell if our ideas are bad/redundant compared to the “internal” ideas if we don’t know what they are. Either way - this is for another thread.

@nta

… this almost sounds like a threat - ‘don’t even dare doing this because you’ll get more support hell, which you hate, right?’

Well, no. Was not intended to be one. Sorry, if you took it that way. More like just a reminder of the dumb copypasted RP server owners. Also a reference to the issue that you raised yourself in the sentence below:

@nta

anything software-related that breaks or removes old workflows is a good way to receive hate (look at every Windows update, lol)

@nta

I’d like to note that any new workflow will be entirely optional for y’all who want to build your own workflow for whatever reason

Good! Hopefully this will prevent the aforementioned people from flooding the forums with pointless threads.

---

Just one last question from me probably…

Do you think it’s somewhere in the drafts of the new system to allow for automation of the publishing process? I.e. having a Git repository for an asset and using GitHub Actions/GitLab CI/AppVeyor/et cetera to publish new versions once a release/tag has been created on the repository (or any other manual trigger)?

[nta]

@xseba360

As long as these thoughts are internal and not discussed openly on forums here or maybe even GitHub/Trello/anywhere else

They’re mostly in my head, sometimes landing in one-to-one IMs with people who ask or are responsible for the implementation, they’re not ‘being discussed in private’ most the time either as you might somehow be assuming again.

‘Publicly discussing’ things like this would have a few disadvantages:

• It would be a lot of effort to detail ideas that may not even happen for over a year (a variant of this idea first came up 3 years ago, perhaps 4?), especially when the ideas are nowhere close to finalized
• This would lead to exhausting discussions with people over trivialities (like has happened here, starting with a ‘oh god please no’ and a subsequent ‘I agree’, without even understanding the complete context or goal)
• Anything too detailed would be seen as ‘promises’ and lead to constant harassment of ‘is this done yet?’, ‘any progress?’, etc., and otherwise have a lot of demotivating effects, especially as there’s not really much more concrete than ‘new resource publishing system’ and a lot of scattered thoughts about potential scenarios this would have to solve
• Would generally have no real benefit either given that the initial ideas are always years out from any implementation, and all the community would do is add scope creep and doubt, and make the ideas less likely to ever be executed.

If every single idea would have to be communicated publicly in a structured fashion, it’d probably take a few months to even write everything down, which would also take away from anyone’s ability to do anything, and again, for no real benefit other than leading to users being worried about misinterpreting often unstructured ideas or work items, and then also some more months responding to all that, by which point all the ideas will have changed as well, leading to an even larger backlog growth than usual.

And, yes, these ‘suggestions’ would also take months to be implemented, maybe a year, and then would delay the proper implementation by that time or more, since the same people who’d work on this would be those working on that, and that’s yet another reason there’s a “no”.

I’m closing this topic now as it has derailed and the original suggestion has already been responded to.

---

As a sidebar, here’s a snapshot of my personal list of ‘got to look at in the future’ notes, note that most things are very quickly added as I read things needing to be done, which takes maybe 15 seconds, compared to writing a ‘public discussion’ or work item or whatever which would take 15 minutes at least per item:

(and that’s just recent items, more broad long-term goals are on the other side of the list as they were added initially, including titles like server as npm package for npx, friendlier basic gamemode flow, client->server error reporting for issues tab, community library system, radio with ytdl bundle? lol, team support in devcenter (implied groups?), server side asset shrinking/compression/collision fixing, and so on - but there’s so many fires to put out and small bugs to fix that these little improvements barely even get any chance of happening)

As can be seen, most of this really doesn’t have enough context for people who are unaware to understand, and given people even misunderstand very clear public commit messages (see this useless comment wondering why a bug didn’t get fixed by a commit that had nothing to do with that bug), and there’s around 670 entries in that list right now, with a lot more that are probably not written down and only exist as vague reminders or others’ work items, and work is already being extremely slow for me, in part because of this constant worry of being vilified by the community over the tiniest things and there not really being any team effort (I keep having to push like 50 times to get anything looked into), and you can see how priorities are a little peculiar.

(and no, adding more team members won’t fix this at this time, it’d only worsen it, management structure is unsustainable currently and everyone’s still kind of up to their knees in personal issues making work difficult)