Pioneer dev forum

As suggested, I've been in the bbs interface attempting to add some functionality. The ui components are still a little beyond me, but I'm getting better. I managed two new features:

• * Sorted ad items in the bb table (by icon name)
  * A toggle button to show only the items that are available (white ads, not greyed out)
  

toggle off fullscreen
https://docs.google.com/uc?id=0BwErCvBm ... t=download
toggle on fullscreen
https://docs.google.com/uc?id=0BwErCvBm ... t=download

Sort By Icon Name: This groups the ads in bunches and give the listing a reliable order. There is no sub-sort within a type of item. The ads currently show: assassination first, then hyperspace mechanics (breakdown_service), then crew hires, deliveries... and so on.

Available Only Toggle: works as advertised, updates the display so that only the ads you qualify for are shown. Toggle remembers it's setting.

I'm pretty sure I tightend some (very) loose coupling between the ads table and the display and that may help with known "clicking bbs ad responds with wrong item" issues (or not).

TODO's
I have a mind to put in a filter selection pulldown to further limit the display to a type of ad. I was first thinking this would be by icon type as well, but then I started thinking of more general filters like "Job" (ads that offer payment), or "Combat" (ads with high risk), etc. Suggestions most welcome here.

The sort/filter I'm using is terrible. Both as code and as implementation. It's run a lot (esp frame changes and startup) and it's almost always in worst case. It doesn't slow down the game I'm running on, but I don't want introduce a bull into the china shop.

I'm looking into replacing the bbTable with either a SmartTable or something like a SmartTable (to help with the sorting for one thing). I want it to further bind the station's ads to the display, in a less fragile (and prettier) way than it's currently coded.

There was a thought to put in a search widget. The more I think on it the more I would rather have meaningful and thought-out filters than typing. I can't see a search being useful unless we expect 100's of items in the bb.

Other than that, I want to present clean code for pull. I'm embarrassed by the learn/hack stuff in it now.

It is great to see that you're having fun (mixed with pain?) with the BBS, and the Lua system, and learning.

When I added the reputation system lwho was very much against showing ads that the player couldn't accept, where as I thought the player should get turned down when being a beginner with no reputation, just like there are ads with too short date for the ship you currently have. We settled on a compromise which is the "greying out" of ads where the player is lacking reputation.

So removing those "grey ads" by a filter sort of stings my eyes.

Sorting on dead line would probably be useful. Or distance. Or deadline / distance?

That is the reason I needed feedback! Thank you Impaktor!

It is great to see that you're having fun (mixed with pain?) with the BBS, and the Lua system, and learning.

yes, yes, it always great when it's finally happening to the other guy =)

When I added the reputation system lwho was very much against showing ads that the player couldn't accept, where as I thought the player should get turned down when being a beginner with no reputation, just like there are ads with too short date for the ship you currently have. We settled on a compromise which is the "greying out" of ads where the player is lacking reputation.

So removing those "grey ads" by a filter sort of stings my eyes.

No problem! I actually had a thought about how it would be less and less useful as you gain rep anyway. It's really just a first attempt at a control. A happy little button that controls something I was already working with and had an example of how to use. Removal is easier done than said.

The important things are: placement and if the color or type of button is ok. Also, should it remember or forget it's state.

I didn't mean to touch any sore points. I'm sure the agony of the past will reflect brightly into the future.

Sorting on dead line would probably be useful. Or distance. Or deadline / distance?

I'm just testing a rewrite of the sorting function and would love to attempt a different ad value to sort by. Or maybe multiples. I need to get a pulldown working.

Do you think it would be ok to filter by type if the enabled state wasn't messed with: Just show deliveries, just show assassination, that type of thing?

Personally, I like the ability to filter out ads that I can't accept. While some might want to see the whole list, I'd like to only look at what is available. Thus, the toggle is a nice feature.

eloquentmess wrote:Personally, I like the ability to filter out ads that I can't accept. While some might want to see the whole list, I'd like to only look at what is available. Thus, the toggle is a nice feature.

I'm not married to it, it was a feature that presented itself in the code as "doable". I can easily see arguments against it. I'm open to mob rule. Hopefully the next iteration of filters may be even more attractive and less controversial (conversational?).

After some investigation, thinking and help from the irc channel (thank you noz, impaktor, laasman, elequentmess, and esp robn for having to put up with my poor lua skills) I'm at a point of needing serious ui help. What I'm looking to do is to make an icon radio button widget (hopefully) like this:

...or something close.

Where a set of toggle buttons use icons instead of captions and making them adhere to a radio button configuration by only having one on at a time. The list of buttons will vary at construction so that the button list will have to be "addable" (that would be normal under most radio button widgets, i think). The widget logic I'm pretty confident about, but the composition is just bewildering to me.

It would be used as a "type" selector for a general filter. I started with the idea of making a dropdown box with the icon names listed. This widget is in response to a solution noz pointed out to the problem of translating unknown future icon names by simply using the icons themselves. It would prevent having to maintain a "list of known icons" in any sense (leaving module creation design alone). Laarman pointed out that attempting to categorize the modules/missions into types other than using the icons could lead to a formalization of modules in general and curb module creation freedom, something I think none of us wants.

It could even look something like this...


but the space usage is less efficient (that is a concern here) and, well, it's kinda ugly. It would allow me to continue the development of the bbs interface changes though.

I'm not convinced one way or the other if this can be done with just the lua containers (or not), but in any event, there are no examples of putting something like this together that I have been able to fathom. In fact I'm just being to grasp the ui components: thus, help?!

I'm backing off the development of this interface a bit so I can go back to concentration on attempting to revive the scout missions and maybe create some new modules. So do not mistake this help request as a priority on my part. If this is more vital than i consider it, please let me know.

I like the idea of the radio buttons in the first picture. Unfortunately, I don't know the first thing about Lua, and I don't have time to learn right now. :(

eloquentmess wrote:I like the idea of the radio buttons in the first picture. Unfortunately, I don't know the first thing about Lua, and I don't have time to learn right now. :(

I'm a fan of that configuration too. Unfortunately, I think it's more a matter of the ui engine components than lua. Lua would tie it together, but there isn't (that I can find) a way to produce a button of the type pictured. It's a mockup; I gimped it together.

The second style pictured is also a mockup but of a known type (cb_button). I don't have a confirmation that you can or cannot give an image to the button as a label. My strong suspicion is you cannot.

To have either issue remedied would require altering the ui engine code (c++). I could try (i do have an amount of c++ competency), but having other things at hand to work on, I'm just opting to table the changes until I have a stronger sense of urgency. I will probably return to the issue if I think of something clever or just want to implement the sorting stuff which does not have all the issues the filter function does.

A friend recently pointed out that I might be able to do a pushend of an image with a cb_button and get the effect of the secondary selection set. I'm a bit scattered atm but still working toward this.

You're doing excellent work. The title of the post suggested suggestions, so here's one.
It's probably UI related, but it would be nice if when you press F2, F3 or F4, and it brings you to an info screen, continuing to press F2, F3 or F4 would cycle through the tabbed options at the top of the screen. It would feel more fluid and would tie in with F1 cycling through the views.

On second thought, maybe not F4, but I hope you get the idea. If you press a function key to access a screen, continuing to press that key would cycle through the options on that screen, if any. The system information screen could really use this too.