One question are the missions shown in the BBS filtered based on the reputation or does one see also missions one can not take? If the latter, I would suggest to make it optically clear which missions are available in the overview table (e.g. show the unavailable in gray instead of white).

It shows all ads, since they are there for the NPCs as well, to give immersion, and also because I don't (yet?) know how to implement colours on the BBS ;-) (ui/BulletinBoard.lua:updateTable I would guess?).

We currently don't filter out missions that require more cabins than the player has, or for a distance that is outside the players jump drive to reach.

According to the road map there are/were? plans to be able to sort and/or filter the posts on the BBS.

The problem of getting many refusals is only for beginners, since you relatively quickly will be eligible for (almost) all missions.

Mind you, that I didn't look at the code. yet or tried it out, but my first impression is positive.

It shows all ads, since they are there for the NPCs as well, to give immersion

I agree. That's why I suggested visually differentiating them.

The problem of getting many refusals is only for beginners,

Which makes it only worse. There is never a second chance to make a first impression ;) We don't want beginners to drop the game, because it gives them only missions they can't accept by bad luck (randomness). Maybe we should just make sure that there are enough low-reputation missions at game start (i.e. randomly select a certain amount of missions only from the "any" group instead of all missions).

I don't say filtering/marking needs to go into this PR (probably not), or that you had to do it. I was just thinking loud.

For sorting adverts I have some code in the backhand, I wanted to wait with until NewUI stabilizes (which might be now?). I didn't think about filtering or color marking/categorizing adverts until now, but that goes into a similar directions and now that I think of it, it sounds nice. Anyway, the sorting might already be enough as a starter, as one could include required reputation as a sorting criterion.

Pinging @robn for the question, if it is worth looking into that sorting stuff now, or if there is more NewUI stuff to come which I should wait for.

Alternatively one could change the colour of the newly implemented BBS icons, since those are set in the mission script, I don't know which way is best.

Sounds like we're on the same page.

The UI that's there is stable; I don't anticipate any significant changes in functionality. There's certainly lots to be added, and I may change some core things (particularly around the input system), but widgets and containers should keep working. If I do have to break something I'll help port any code to whatever replaces it.

Regarding colours, keep in mind that hardcoded colours suck because they're not really easy for a mod to modify. More generally, colours aren't always a good way to convey important information for colour-blind people or even in situations where colour contrast isn't the same (local light levels, glare, etc).

I'm not saying don't do it. I'm acutely aware that we'll need a better mechanism for colour and highlights throughout the UI. I'm just saying you should be aware of it :)

Provided there will be at least one mission on the BBS for a new player, I don't think there should be any problem of scaring away a new players, since it is only natural to be denied some missions, and this will hopefully arouse some curiosity.

Now there will always be at least one local delivery on the BBS if the player has reputation below 8.

Note: when using 139d75c (has debug outputs) for testing I noticed in the Barnard system that it failed to create a local advert once, possibly because makeAdvert chose to make the advert with same destination as the station? I have a loop witch makes five attempts to create a local advert.

adf7165 is without debug outputs.

So what's the best way for someone to set about testing this?
Are there any Lua commands we can use to set parts of our reputation to make sure that mission/bbs thresholds are met correctly?

@fluffyfreak
I flew one mission "manually" to test it, then I've used import("Character").persistent.player.reputation = 16 or similar and same for import("Character").persistent.player.killcount.

(ops, wrong button :P)

@fluffyfreak
I flew one mission "manually" to test it, then I've used import("Character").persistent.player.reputation = 16 or similar and same for import("Character").persistent.player.killcount.

Just started a game with it. And for almost every non-local mission is rejected. This is a very bad first impression for a new player clicking on a full list of missions and getting rejected almost everywhere.

I really want to like it, but currently I don't. This definitely needs some clear visual feedback in the missions list.

One idea: For missions that require >4 reputation mention the required reputation. Such as: "For reliable pilot:..." or "Searching experienced pilot for...". Though, we also need to be careful, that the player is not drowned in a wall-of-text.

Or maybe, the missions you can not do grayed out, but still selectable and giving the refusal message. I think the refusal message should then definitely include the required level in a recognizable way for levels >4 (I'm limiting to >4 here, because something like "I only accept inexperienced pilots" would sound very strange).

Okay, after some playing. I'm starting to like. Aside from the visual feedback issue one suggestion for balancing:

• Increase all reputation needed for ranks by factor two
• Increase all reputation required for missions by factor two
• Keep local deliveries at 1 reputation
• Increase all other gains by missions by factor two

So, in effect cut the win from local deliveries by half compared to remote deliveries. This will probably need some more balancing later, but this can well be done after merging, when more players have experience with it.

@lwho Thanks for the feedback. I appreciate it.

Upon rejection at the BBS

I agree that it is bad if all missions (or close to all) are rejecting the player, so maybe a solution would be to increase probability of getting local missions for new players when creating BBS? However, then we are customizing the BBS for the player, which might be OK if we only do it for players with reputation < 4 or < 8?

However, unless I have a bug (I will check the code again), roughly 70% of all delivery missions should be accessible to a new player.

I think it is important that the player will relatively quickly feel a progress, by gaining access to new missions relatively fast, so in this case, after "just" 4 delivery missions they will have access to 80% of all delivery missions, and 50% of all taxi missions.

I'm wondering if it's not also a deeper issue here: for whom is the BBS made?

1. Just the player - Only show missions suitable for that player.
2. For everyone - Show all missions, player must accept that when he/she has 0 flight hours, and never done a mission there will be many rejects.
3. For everyone, but player has an auto-filter - Works as you suggested.
4. For everyone, but player can filter manually - The player can, when closing the ad, choose to "dim it/gray is out" in the BBS list. E.g. have two buttons "hang up" and "hang up and mark gray" or similar. This way you can "remove" missions that you don't feel like doing when going through the BBS.

However, I don't think I it is quite as bad as you do, that it would be bad for a new player to see many missions that rejects the first 2-3 times they go through the BBS board. That's part of being a rookie, as long as you see some missions available to you.

Balancing

There is definitely some balancing to be done, as can be tweaked later as you point out.

Not sure I understand your 4-bullet list, but this is how I interpret what you are saying:

1. multiply column 2 in table one (first table in first post) by two
2. multiply column 4 in table two with 2
3. local deliveries in same syste, gives: +1
4. intersystem deliveries: +2, taxi: +4, assassination +16?

I'm also thinking that the last assassination mission might require double reputation compared to now, and lower killcount (8). Having 16 is pointless, that's the same as having done just one assassination mission prior, with current settings.

Also, you will effectively get "maximum reputation" fairly fast with both current (and suggested) settings, so that might need some thought.

It would also be interesting to see if others have any feedback.

However, unless I have a bug (I will check the code again), roughly 70% of all delivery missions should be accessible to a new player.

Well, I ignore all local missions in Sol :P, I want to get out there fast. And of the remaining, almost everyone is rejected, and it's not clear from the text or visually, which those are.
Don't get me wrong, I'm not against the fact, that you can't do most missions in the beginning. It's great that you have to work for that. I'm against the fact, that you have to click through every one of them to find out, which you can take.

I'm wondering if it's not also a deeper issue here: for whom is the BBS made? [...]

As you said, only showing the missions, that the player can do, would kill immersion. Also, he should see what's the reward of achieving reputation. But I think, they should just be visual distinguishable. I don't think, that anything more complex than such a binary differentiation is necessary. I'll hack something together to try it out...

Not sure I understand your 4-bullet list, but this is how I interpret what you are saying:

Actually, I just wanted to cut the bonus of local deliveries by half and keep the values integers (but there is no technical reason, Lua numbers are floating point numbers anyway). So, let's just pretend, I said:

• Cut the reputation achieved by local delivery to 0.5, so that it makes a noticeable difference to non-local deliveries.

Now, that I think of it. I've never had so many local missions to the same destination, as in this game, which meant I would achieve the points for the next level, by just one very local trip (same planet). Maybe that's the base problem, that needs digging into.

Also, you will effectively get "maximum reputation" fairly fast with both current (and suggested) settings, so that might need some thought.

Yes, I agree. But that doesn't need to happen before merging. Currently, you get "maximum reputation" so to speak immediately on game start. So, the current balancing tends to "not change too fast from the status quo", which I think is not a bad think.

It would also be interesting to see if others have any feedback.

Yes, I would like to see more opinions as well, as that is more a gameplay than a technical issue.

Short version: I agree with everything.

Longer version: see below

Actually, I just wanted to cut the bonus of local deliveries by half and keep the values integers

yeah, cutting local delivery in half (to +0.5) would be easier/less rewrite. I am all for it.

Then the fact that we are re-balancing ships in other commits is also affecting this commit:

• if player starts with a bare ship (no hyper drive) they are left to just do local missions. So to make 700 credits for a class 1 hyper drive, they need to do 700/40 = 18 missions. That means once they have a hyper drive, they also have full reputation for almost all missions. Cutting the local deliveries from +1 to +0.5 will be good, to let them "work" some more to unlock those juicy taxi missions once they have a hyper drive.

So we need to see what direction this ship balancing will take, and then balance accordingly (after merge?).

I obviously don't want the code merged if there are any objections to it, so it's good we can sort all the major things out now, and then do tweaking and balancing afterwards as you suggested.

But I think, they should just be visual distinguishable. I don't think, that anything more complex than such a binary differentiation is necessary. I'll hack something together to try it out...

Good, because my coding is very weak when it comes to anything graphics.

Please see a version with "disabled" adverts in lwho/reputation. I had to invent some more events. If you are testing by setting reputation/killcount manually, you have to explicitly trigger Event.Queue("onReputationChanged", oldRepu, oldKills, newRepu, newKills)

So 110d4de is my implementation of the things discussed above, except the visual BBS code you've written.

@lwho I tested your "visual" implementation, and it seems to work. Should I merge that into this PR? or will you do that? or is there more work to be done on it? (I haven't had time to look at the code in detail.)

Rebased lwho/reputation onto your last change.
I'll try to solve that "generate an extra local delivery" issue tomorrow.

Hmm, just noticed that an advert was not properly removed from the bulletin board after accepting two delivery missions. When clicking on it, I got a Lua exception that indicates to me, that the advert was removed from the SpaceStation but not from the BulletinBoard, I think:

error: [string "[T] @ui/StationView/BulletinBoard.lua"]:29: attempt to index upvalue 'ad' (a nil value)
stack traceback:
        [string "[T] @ui/StationView/BulletinBoard.lua"]:29: in function 'chatFunc'
        [string "[T] @ui/StationView/ChatForm.lua"]:32: in function 'New'
        [string "[T] @ui/StationView/BulletinBoard.lua"]:35: in function <[string "[T] @ui/StationView/BulletinBoard.lua"]:23>

Looks a lot like #2636, as it only seems to happen when I side-exited a chat before (i.e. not by pressing "Hangup"). Though, I have no idea why this messes up stuff that happens in a later chat.

Okay, happens on clean master as well. So not related to this PR.

Hmm, just noticed that an advert was not properly removed from the bulletin board after accepting two delivery missions.

Yeah, I've experienced that on this branch as well as master before.

I'll try to solve that "generate an extra local delivery" issue tomorrow.

You mean it should not be there at all (i.e. negate/remove 139d75c), or if should be done in a less ugly way? I'm fine either way.

or if should be done in a less ugly way?

Just pushed a less ugly version to lwho/reputation. Only very lightly tested (want to get a bit of sunlight first ;)).

• Extra job is only generated if there isn't an easy one anyway
• Easy job may now also be one of the non-local easy jobs
• onCreateBB now only requests an easy advert if that is possible to fulfill and MakeAdvert will always create one in this case.

Easy job may now also be one of the non-local easy jobs

I noticed that this was not a good idea when the rookie had no hyperdrive, so taking this into account now, as well.

It seems that new adverts are generated much too fast (but again no problem of this PR, just noticing).

I noticed that this was not a good idea when the rookie had no hyperdrive, so taking this into account now, as well.

My thoughts exactly.

It seems that new adverts are generated much too fast (but again no problem of this PR, just noticing).

I've also noted this. I plan to put some time into balancing number of ads on BBS, and shipyard, and respawning of those, but that's for another time.

I'm intending to clean up the commit history a bit and then merge that PR in the course of this week.
Unless someone is seeing any issues that need to be solved before.

Rebased it and folded a few commits in lwho/reputation_rebased. Giving it a last test, then I'll merge.

Merged the rebased version (that's why github didn't detect it automatically).

One think I noticed in the last test: You can avoid the bad reputation for failed deliveries (i.e. cheat) by not flying to the destination. Delivery missions only fail. when you go to their destinations (and otherwise pollute your mission list forever, which always annoyed me). This should probably be fixed at some time (hint hint ;)), but not in this PR as this now

Closed/Merged

@lwho thanks for all the help.

You can avoid the bad reputation for failed deliveries

I've seen that as well. My thinking was that you have to choose, either avoid
bad rep, or pollute your missions list.

Any suggestions for how it should work? Clear the failed missions (and set
reputation) once the mission has been failed for 1 month? 2 months?