NationStates

Is this still actively maintained? Anyone using it know if its facing the bug issues that NS++ does?

Considering the last post prior to yours was pre-Rift release, I imagine that at the least it suffers potential compatibility issues of you use that theme. By my understanding as well, it never picked up all the original Ns++ features, so I'm not sure how much further functionality you'd get and how much switching would just remove broken items entirely.

Waiting for this to get the ability to create puppets, the other program says a nation exists so I can't use the name, and then when I ask NS it says that's nonsense.

Android support! Finally!

How do I change the settings?

I Got Both At Same Time(LibreNS++ and NS++)

So, just installed this, any reason why the check boxes in the LibreNS++ thingy at the top are unchangeable?

EDIT: Also, trying to access said tab from the forums returns an error page, probably because its trying to find it with forum.nation... in front of it.

Do you think you'd be able to transfer most of the features seen in NS++? Like highlighting OP.

Hi everyone. As it turns out, I'm still here, and still maintaining LibreNS++! So I suppose the answer to...

Kazmr wrote:Is this still actively maintained?

is 'yes'. Even better news than that however, is the release of 0.0a16!

• Implement NS++ compatibility for regional titles. #28 #29
• Remove support for legacy versions which hotlinked libraries.
• Prevent jQuery 2.1.1 messing with NS jQuery 1.x. Fix #44.

I must confess, I've been sitting on this release for a while now (since December last year, oops!) but it's here now, and it's better than ever!

Now, to address a few questions:

Ever-Wandering Souls wrote:Considering the last post prior to yours was pre-Rift release, I imagine that at the least it suffers potential compatibility issues of you use that theme.

I don't use Rift regularly, but I did for a while, and I never saw any compatibility issues. The 'LibreNS++' and 'Puppet' buttons are still in the old style, but they all work properly.

British Accia wrote:So, just installed this, any reason why the check boxes in the LibreNS++ thingy at the top are unchangeable?

EDIT: Also, trying to access said tab from the forums returns an error page, probably because its trying to find it with forum.nation... in front of it.

LibreNS++ hasn't got too many configurable options right now, so most of the options wouldn't actually do anything, even if you could change them. However, LibreNS++ has just gotten support for NationStates++ regional titles (see above), so now one of the checkboxes actually works!

I've known about the forum issue for a while now, and I've opened an issue on the issue tracker. A little inconvenient, perhaps, but the workaround right now is just to not use those buttons while on the forum.

I'd like to contribute a bit here to practice my JS, but I can't actually tell how to start. It looks like you're using some sort of JS preprocessor or compiler?
EDIT: Alright, figured it out: it's GNU M4. Forking. I think one of my first contributions will be a CONTRIBUTING.md file...

Is this Compatible with the RIFT Theme?

Confederation of imperial states wrote:Is this Compatible with the RIFT Theme?

Yes. Look two posts above you.

I admit I am not the most research-oriented of the NSers around. I have been informed of the potential issues with NS++, thus, when I get home from work, I will be more than willing to uninstall NS++ for your extension. Thank you for releasing it to us!

Thanks to Leveat's work, I present LibreNS++ 0.0a17, followed quickly by 0.0a18!

A number of bugs have been fixed, and many of the options in the LibreNS++ settings menu are finally functional.

A note on updating
If you are currently using LibreNS++ to store puppet details, updating to 0.0a18 may cause your puppet details to become inaccessible. It is strongly recommended that you delete your puppet details from LibreNS++ before updating.

Question to you: it is certainly possible that there are some things that are downright impossible without a centralized server and some other things that are difficult without one, so I think we should consider allowing some centralized data storage, under rules. My suggestions:

1. If it's reasonably possible to decentralize, decentralize first. Example: I'm working on a contribution that uses a sound file; this can be stored in base64 and played off of a data: URI without needing it to be loaded from a server. However, the dispatch is indeed pushing it.
2. Data should be stored in an openly accessible and auditable area. My recommendation is a GitHub repository, which we could name, for example, RunasSudo/LibreNSpp-data.
3. All centralized features should be toggleable and disabled by default.
4. All centralized features should support using an alternate database if the user wishes.

I just wanted to thank you for developing this extension. I installed it and it works great. Thanks!

Leveat wrote:Question to you: it is certainly possible that there are some things that are downright impossible without a centralized server and some other things that are difficult without one, so I think we should consider allowing some centralized data storage, under rules. My suggestions:

1. If it's reasonably possible to decentralize, decentralize first. Example: I'm working on a contribution that uses a sound file; this can be stored in base64 and played off of a data: URI without needing it to be loaded from a server. However, the dispatch is indeed pushing it.
2. Data should be stored in an openly accessible and auditable area. My recommendation is a GitHub repository, which we could name, for example, RunasSudo/LibreNSpp-data.
3. All centralized features should be toggleable and disabled by default.
4. All centralized features should support using an alternate database if the user wishes.

Those seem like very reasonable suggestions, but I'm not sure about audio files. Storing an audio file in a dispatch is probably overkill, but I don't think storing it in a GitHub repo is a great idea either. I can foresee difficulties managing all the files, and GitHub storage space isn't free. Inappropriate content in audio is probably also worse than in text, so I can imagine there might be trouble with content.

EDIT: I interpreted your suggestion as relating to user-uploaded content. My reservations don't apply to LibreNS++'s own assets (which could just be stored in the LibreNS++ repo).

South Jarvis wrote:

Leveat wrote:Question to you: it is certainly possible that there are some things that are downright impossible without a centralized server and some other things that are difficult without one, so I think we should consider allowing some centralized data storage, under rules. My suggestions:

1. If it's reasonably possible to decentralize, decentralize first. Example: I'm working on a contribution that uses a sound file; this can be stored in base64 and played off of a data: URI without needing it to be loaded from a server. However, the dispatch is indeed pushing it.
2. Data should be stored in an openly accessible and auditable area. My recommendation is a GitHub repository, which we could name, for example, RunasSudo/LibreNSpp-data.
3. All centralized features should be toggleable and disabled by default.
4. All centralized features should support using an alternate database if the user wishes.

Those seem like very reasonable suggestions, but I'm not sure about audio files. Storing an audio file in a dispatch is probably overkill, but I don't think storing it in a GitHub repo is a great idea either. I can foresee difficulties managing all the files, and GitHub storage space isn't free. Inappropriate content in audio is probably also worse than in text, so I can imagine there might be trouble with content.

EDIT: I interpreted your suggestion as relating to user-uploaded content. My reservations don't apply to LibreNS++'s own assets (which could just be stored in the LibreNS++ repo).

Nein, nein, nein, you misunderstand; the contribution that uses a sound file is to play a notification noise when new RMB messages are loaded. We don't need to make that customizable per-region, this simple beep I found will suffice and can be hard-coded into the .user.js file. You can see how I did that here.

And yes, LibreNS++'s own assets can easily be stored in the repo. I prefer to bake them into the .user.js (as data: URIs) when possible to avoid any potential compatibility issues, however. Perhaps I could add this to build.sh, so the assets could be stored in their usual form in the repo and be encoded and baked automatically.
EDIT: In fact, I think I will. EDIT TWENTY MINUTES LATER: I just did.

And yes, my suggestions concern only user-generated content.

Will LibreNS++ ever be able to access NS++ regional newspapers?

Baconbacon123 wrote:Will LibreNS++ ever be able to access NS++ regional newspapers?

It would not be difficult for it to read them, particularly with my cooperation (which I'd be happy to provide,) but it would be difficult for it to be used to edit them.

Baconbacon123 wrote:Will LibreNS++ ever be able to access NS++ regional newspapers?

LibreNS++ already interfaces with the NS++ data service to provide compatibility for regional titles, so regional newspapers shouldn't be that hard. I might slip it into the next version, but as Zemnaya Svoboda correctly notes, it would be very difficult (and not on my radar) to allow submitting new articles.

LibreNS++ 0.1.0 has been released! This release brings with it NS++ compatibility for more features, a notification system and a long-awaited update checker!

* Various changes by @ViKomprenas
* Added a notification system for RMB messages.
* Implemented an update checker. #33
* Added NS++ compatibility for regional IRC and newspapers. #28

By the way, here's a list of all the icons NS provides (as of now, anyway), in case you or I need them. They seem to be available on all themes.
The CSS file containing all these class definitions is https://www.nationstates.net/fontello/css/nationstates_v1401173011.css.

Code: Select all

.icon-radar
.icon-town-hall
.icon-search
.icon-mail
.icon-mail-alt
.icon-heart
.icon-heart-empty
.icon-star
.icon-star-empty
.icon-male
.icon-female
.icon-ok-circled
.icon-cancel-circled2
.icon-plus
.icon-plus-circled
.icon-help
.icon-link
.icon-link-ext
.icon-lock
.icon-lock-open
.icon-flag-1
.icon-flag-empty
.icon-flag-checkered
.icon-comment
.icon-chat
.icon-comment-empty
.icon-chat-empty
.icon-bell
.icon-bell-alt
.icon-rss-1
.icon-menu
.icon-wa
.icon-login
.icon-logout
.icon-mic
.icon-lightbulb
.icon-right-hand
.icon-arrows-cw
.icon-target
.icon-award
.icon-globe
.icon-flash
.icon-align-left
.icon-book
.icon-gift
.icon-chart-bar
.icon-megaphone
.icon-coffee
.icon-building
.icon-shield
.icon-stackexchange
.icon-newspaper
.icon-globe-1
.icon-chart-line
.icon-chart-bar-1
.icon-chart-area
.icon-news
.icon-award-1
.icon-chart
.icon-industrial-building
.icon-monument
.icon-cog-alt


Sorry to jump in with a feature request, but something I miss about NS++ is the option on the settings page that can be unchecked entitled 'Show Nation Page on Switch', when you do so and switch, the current page (including active scripts) is simply reloaded from the selected puppets perspective. I am not skilled at coding, so I don't know how much trouble such a feature is to add, or indeed if you plan to do so, I of course understand if you do not.

Also, whilst I am here, thank you South Jarvis for this extremely useful extension, and likewise, thank you for your contribution to it as well, Leveat.