[FLASH SKIN] Naming conventions for bonus/extra features

[plm]

I'm trying to find the best naming convention for bonus/extra features for Eversion.

In the 5150 HTML skin I used to use:
feature name.[01.Bonus-first bonus feature name].extension
feature name.[02.Bonus-second bonus feature name].extension

This worked well as 5150 would recognise the Bonus- in the brackets and treat the file as a bonus feature, would also sort on the filenames alphabetically so I got them in the numerical order I'd specified, but also only display the name after Bonus-, so my bonus features would be listed as:
first bonus feature
second bonus feature

The same naming in Eversion (with evstreamed) works fine, sorts correctly, but displays:
01.Bonus-first bonus feature name
02.Bonus-second bonus feature name

Is there a way of hiding everything up to and including the hyphen at the end of Bonus-? I've tried not having the numbering in there in case this was tripping it up but it still displays Bonus-bonus feature name in each case.

[accident]

The properties has keywords for what is an extra, I'm pretty sure 01.Bonus is not one of them.

[plm]

It finds them as extras even with the digits. Without the digits to force the sort order it still does but it displays the extras as 'Bonus-bonus feature name' whereas it would look neater (especially with the limited screen real estate) if it displayed them as 'bonus feature name', i.e. with the leading Bonus- trimmed off.

I've not found a way of doing this yet but it could just be down to how I'm naming the files.

[accident]

you can use a condition to look for the title containing Bonus- and then use variable modifiers to cut off the front of it.

this is not exact but it's something like:

PHP Code:

<tile>
  <text>
    <condition>[:title:] contains .Bonus-</condition>
    <display>[:title,slice9:]</display>
  <text>
</tile> 


hmm although I see something lacking here, there's no option to say does not contain bonus to have an alternative just show it option.

[plm]

Cool, I'll have a play with that. I just wanted to know if I was missing something in how I was naming the files since every skin handles the naming slightly differently, but that will do fine for what I want to achieve. That would also still allow me to sort them into a specific order which is useful when you've got a Rolling Stones box with over 20 extra features!

On a vaguely related note, are you accepting feature requests or is it on hold while you work on the dentedboxes project?

Reason is, and this is only a minor cosmetic issue, when you've got multi-part features and press enter the list of parts doesn't have the nice looking blue cursor that the extras and TV series episodes do. I'm sure I can look at the skin code myself but it would be nice to carry this part of the theme across all the scroll lists for the sake of uniformity.

[accident]

(03-05-2012 06:41 AM)plm Wrote:  is it on hold while you work on the dentedboxes project?

It's actually the opposite and dentedboxes went on hold. Gaya wasn't going to work and before I gave up on the popcorn hours I decided to give back to yamj and help out skinners by looking at the flash ui.

Quote:are you accepting feature requests

If there's bugs that need to be fixed like playback bugs, new firmwares breaking something I'll get involved in. I've been doing that for the last 7 months already and since I need to host a new download I tend to throw in fast other fixes if i have a few moments and it's safe to do that.

Also it's open sourced. I haven't heard of anyone playing with it to take it further. I'd post them.. now the best place so they don't get lost?? perhaps the db forum in the request section or maybe the issues on the github? then someone new could see some things to try to add to learn how eversion itself works.

Quote:Reason is, and this is only a minor cosmetic issue, when you've got multi-part features and press enter the list of parts doesn't have the nice looking blue cursor that the extras and TV series episodes do. I'm sure I can look at the skin code myself but it would be nice to carry this part of the theme across all the scroll lists for the sake of uniformity.

it took you longer to post what you want then it would have taken for you to customize the eskin to your liking.

[plm]

(03-06-2012 06:06 AM)accident Wrote:  it took you longer to post what you want then it would have taken for you to customize the eskin to your liking.

Almost, but then it wouldn't benefit anybody else if it were just for me!

Anyway, I've found a minor stumbling point. [:@media:] in /shared/code/mpart.eskin doesn't point to the media within the skin itself but rather to the eversion shared media from what I can test by displaying it. Is there a variable that points to the media within the skin I can use in this file, since I don't want to hard-code paths, or do I need to copy the image files to the global shared path?

[accident]

copy the eskin file to your version of the eskin.
in load.eskin add an mpart to add your filename to the list of valid options
add a systemMPART eskin setting pointed at your version of the file

this is my last post in this no longer on topic thread.

[plm]

(03-05-2012 02:31 AM)accident Wrote:  you can use a condition to look for the title containing Bonus- and then use variable modifiers to cut off the front of it.

this is not exact but it's something like:

PHP Code:

<tile>
  <text>
    <condition>[:title:] contains .Bonus-</condition>
    <display>[:title,slice9:]</display>
  <text>
</tile> 


hmm although I see something lacking here, there's no option to say does not contain bonus to have an alternative just show it option.

I've been playing with a few variants around this and keep coming unstuck whenever I try to add a catch-all for strangely-named extras.

Could you maybe consider adding !contains, !startswith and !endswith operators at some point? I think with the combination of these and the ++ operators you'd be able to do everything that an 'else' statement would achieve without the complexity of adding if... then... else... type structures. From looking at the list of operators available I think these would allow for all eventualities.

You'd then use contains and || for finding matches, and !contains and ++ for finding everything else.

[accident]

Doesn't yamj split the title out when configured correctly and you add your custom extra tags to the properties? I don't see a reason to slow everyone down because your not configuring yamj right for your custom naming.

[plm]

I do have YAMJ configured correctly.

If you name the bonus feature featurename.[Bonus-bonus feature name].extension then evstreamed will display it as:
Bonus-bonus feature name

If you name the bonus feature featurename.[01.Bonus-bonus feature name].extension then evstreamed will display it as:
01.Bonus-bonus feature name

This second case isn't documented but allows you to sort them into a specific order, which I think is useful, but others won't necessarily.

Regardless, the display is 'Bonus-name', whereas I just want to see 'name'. That problem exists whether I use the default naming or take advantage of the undocumented feature I found.

I can ensure that all my files are correctly named and just match by using a combination of slice, cut and contains but you said yourself that this doesn't allow for a catch-all condition and over on dentedboxes people have already been asking for the possibility of an else operator, so there's clearly a desire to be able to do more complicated logic and not just by me.

Would adding these additional operators to the code slow it down for everybody, or only when you're using them? If it's only when you're using them then that's fine by me since this would only be when generating the list of extras for those few features that have them, but I wouldn't want to compromise performance for everybody.

But, looking at the operators available, I believe that you could avoid the need for an else condition altogether by adding the negation operators for those few that don't have them.