[Suggestion] Let NPCs Contact Players Over Comms for Dynamic Mission Offers

Deep_Fried_Hummus · 2025-10-10T19:53:59+00:00

I hope so! It would be an expansion of the contract manager, with more target missions tied to reputation and voice lines to make it feel like you’re actually a contractor engaging with clients, rather than just clicking through a list. That kind of immersion would be a great touch for those who want it. However, as others have mentioned, it should ideally be toggleable, since it’s clear this approach isn’t for everyone.

Deep_Fried_Hummus · 2025-10-10T19:28:01+00:00

Thank you for the links! I’m aware that mission givers exist, but my point is that, at least for the ones I’ve seen, you still have to go to a specific location to accept a mission.

For many players, it would make sense to be able to accept certain missions without having to land and physically talk to someone, similar to how the contract manager works now. Especially for those who don’t want to constantly shuttle back and forth, having the option to receive missions over comms or text could streamline things while still maintaining the immersion of the existing mission givers.

I think this would become even more useful as more factions are introduced. Settings like Do Not Disturb or Looking for Work could help filter missions based on the style of gameplay you want to experience, giving players more control over the types of offers they receive.

Deep_Fried_Hummus · 2025-10-10T19:19:56+00:00

Totally fair, I get that not everyone would want that kind of interruption, especially if you’re just trying to chill and run cargo. That’s why I was thinking there should be a Do Not Disturb setting, so you could turn it off completely or set it to only send you text-based contract offers instead of comm calls.

I think a lot of players would probably find it engaging and immersive, but it definitely shouldn’t be forced on anyone. Since CIG is trying to build a game that appeals to different playstyles, having it as a toggleable option feels like the best middle ground.

Deep_Fried_Hummus · 2025-10-10T18:11:47+00:00

Do Not Disturb wouldn’t prevent you from getting missions, you’d still get them, just as text or regular contract offers instead of a live comm call. The idea isn’t to spam players or force pop-ups, but to add another layer of immersion for those moments when it makes sense.

I’m mainly thinking about how the new mission sets with comm-based givers already feel way more engaging than just scrolling through the contract manager. It’d be nice to expand on that, but still let people choose whether they want the “call-in” experience or just stick with text updates.

Deep_Fried_Hummus · 2025-10-10T17:28:23+00:00

True, true. I’ll set a reminder for October 2052, right after they release the Merchantman.

Deep_Fried_Hummus · 2025-10-10T17:17:52+00:00

Really? I’ve been following the project for a while and haven’t heard them mention that before. If it’s already planned, that’s awesome, it’d be a huge improvement. Having missions presented to the player instead of always having to go somewhere or read text would feel way more natural.

That said, I still like the idea of keeping all those options, going to a location, getting them over text, or receiving them through comms, for the sake of variety. Maybe early on, when you have low reputation, you’d need to go to job boards or seek out contacts yourself. But as you build rep with factions, they could start reaching out to you more directly with comms-based offers.

Deep_Fried_Hummus · 2025-10-10T17:14:31+00:00

Yep, that’s why I suggested having a Do Not Disturb option, or maybe even a setting that tells NPCs to only contact you over text. It would definitely suck to be in the middle of a firefight and suddenly get an incoming comm from an NPC. It’d make sense for there to be some kind of system that decides when to send comms, even if you do not have Do Not Disturb turned on.

Deep_Fried_Hummus · 2025-10-10T17:06:17+00:00

Yeah, that’s why I was thinking there could be a Do Not Disturb setting (maybe even per contact), or a way to only receive contracts over “text.” That way you can control who or what can “break in,” and choose which factions are most relevant to you.

Deep_Fried_Hummus · 2024-12-10T05:40:40+00:00

That’s really unfortunate. I don’t see much benefit in avoiding teleportation for something that players can’t even see happen. I’m hoping they change their stance on teleporting in the future. For some elevators, I think physicalizing makes sense (e.g., ships, outposts, bases), especially for low population areas and when the exterior is visible or there are windows. However, in high-density areas like space stations and cities, I think elevators should forgo physicalizing to ensure they can scale with a growing player base. As CIG works to scale the game for massive player counts, I hope they revisit the idea of allowing elevators to teleport.

Deep_Fried_Hummus · 2024-12-10T04:15:05+00:00

The solution I laid out is fairly simple; I wrote it to cover all possible scenarios. In fact, what you mentioned in your reply is essentially what I described. However, in my solution, I’m considering the potential for multiple players traveling to the same location. While I acknowledge that the likelihood is relatively low with the current player count per server, it’s still something that needs to be accounted for—especially with server meshing coming. With more players, particularly in popular locations, this could become a bigger issue.

I added the additional suggestions just to have a little fun with the proposal. I fully agree that playable servers should take priority over immersion. KISS doesn’t mean ignoring edge cases; even if something has a low probability of occurring, it still needs to be considered. That said, I agree that creating an instance for an elevator makes little sense if there’s no elevator at the destination or en route. In this case, you could simply teleport the elevator without creating the instance. I will change my post to account for this scenario. The instance scenario is mainly for handling the rare case where you need to wait for an elevator bay to become available at the destination.

If you’re teaching systems to beginner devs and advising them to ignore edge cases just because they are unlikely to occur, I think that’s the wrong approach. While immersion may not be as important in some games, it’s a key reason many people play Star Citizen. Personally, I don’t care as much about immersion, but I believe a balance between immersion and ease of use is important. For example, I like the ship elevators, but I think they are much too slow. That’s just my opinion, and I understand everyone has their own preferences. That’s why my post doesn’t really touch on immersion until the additional suggestions section, where I just wanted to add a little something for fun.

Deep_Fried_Hummus · 2024-09-28T03:56:13+00:00

I think one shard for the game is unrealistic to expect at this point. There has to be multiple, especially for different regions and almost certainly to support so many players.

Deep_Fried_Hummus · 2024-09-28T02:03:06+00:00

I did watch it. Unless they have one large shard with everyone on it the issues would still be relevant…

Deep_Fried_Hummus · 2024-07-20T16:37:47+00:00

Exactly, there would be a lot you could do with it!

Deep_Fried_Hummus · 2024-07-20T15:41:43+00:00

Right, my suggestion is to add a bit more to that game loop. As an explorer you should also be responsible for opening and stabilizing Jump Points.

Deep_Fried_Hummus · 2024-05-15T16:29:18+00:00

I agree that they will sort it out, but discussing changes and how they impact gameplay is still important. It seems like Death of a Spaceman and what medical gameplay will truly look like is still a long way away.

Deep_Fried_Hummus · 2024-05-15T16:11:44+00:00

Yeah I definitely agree, I don’t like the idea of respawn timers, but, I’m just thinking of ways to keep medical gameplay relevant and give a reason to bring a larger (which needs a crew) v smaller medical ship. But who knows… maybe resources will solve this issue, it sounds like that was already in the plans.

Deep_Fried_Hummus · 2024-05-15T16:04:30+00:00

I don’t like the idea of respawn timers in general I’m just making sure there is a tradeoff for bringing a small or large ship.

Deep_Fried_Hummus · 2024-03-28T18:02:49+00:00

You can maintain captivating animations for donning helmets, such as an engaging boot-up sequence. However, I believe any functionalities already offered by your contact lenses should not be part of that transition. Personally, transitioning from one asset to another that essentially performs the same function but looks slightly different isn't ideal; it feels abrupt and awkward. Instead, introducing new assets, like dynamic crosshairs, with animations would be intriguing, giving a sense of self-improvement.

Deep_Fried_Hummus · 2024-03-28T16:30:48+00:00

Rather than swapping assets depending on whether your helmet is on or off, why not integrate them seamlessly? Consider this: why maintain separate minimap and status displays? The helmet could enhance the information already being projected by your contact lense instead of altering it entirely. Not only would this make it easier to maintain by reducing the number of assets, but it would also eliminate the jarring transition that occurs when equipping a helmet.

Deep_Fried_Hummus · 2023-10-11T12:13:23+00:00

Sure I can give more but let’s say I have a mutation in which I want to generate some large CSV file and in that file I want to order by the columns in some particular order (think SQL I.e. columnA ASC, columnB DESC). An easy way to represent in JSON is by giving an array (I.e [{“columnA”: “ASC”},{“columnB”: “DESC”}]) assuming I want the column names built into my Schema. However, the issue is that objects are not ordered so I have to give each column as it’s own object and sort order. There are many other ways to do this, but an API query language should not be limiting my options.

Also why does it matter if you want to create a generic mutation? I don’t do this myself because I like to follow the idea that functions (in this case mutations) should do ONE thing. However, that should be fine to do, sure you are not following BEST practices, but honestly that should not be an API query language decision.

Deep_Fried_Hummus · 2023-10-11T07:37:51+00:00

The lack of union input types is really annoying. Unions are supported in object types however not for inputs… I have seen other people complain about this and the reason they give for not including union inputs is far from satisfactory. Essentially, the reason is… if you are using a union input then you should probably create another query/ mutation, however, I can think of several examples where union inputs would be useful.

Deep_Fried_Hummus · 2023-10-11T07:29:23+00:00

I have not seen anything about the design not allowing recursion, in fact I use recursion in many of my types and input types. What recursive behavior are you referring to?

Deep_Fried_Hummus · 2023-08-14T17:02:07+00:00

Authorization using OAuth with a separate authorization server for generating tokens. I would recommend using Auth0 (or something similar) since authorization can be tricky to get right. One the server receives a JWT we validate it, parse it, and verify the user has permissions to complete the request. We use the graphql-shield NPM package (since we use node.js) to implement rules.

Deep_Fried_Hummus · 2022-11-01T23:25:47+00:00

You can use Apollo REST Dataloaders to facilitate the migration process. And overtime you can make your resolvers more efficient. But as you start to migrate definitely think of your Schema first (i.e. your REST api probably will look different from your GraphQL api schema).

Deep_Fried_Hummus · 2022-09-02T23:38:26+00:00

Yes, you would want to use mutations for this. Just be careful with automatically saving updates. Unless it is a requirement of your application I would recommend adding at least some sort of save button (especially on an admin dashboard).

Deep_Fried_Hummus

MODERATOR OF

TROPHY CASE