There are a fair bit of articles that have been influenced by the CK2/EU4 wikis. An objective, third person written style is always better so I'd suggest to follow the guidelines and fix what should be fixed. As for the technical terms, what do you have in mind here? Stuff like "FTL" or technology names will be very common through the whole wiki, and I'd suggest not to italicize them to easy maintenance of the wiki.
-
We have updated our Community Code of Conduct. Please read through the new rules for the forum that are an integral part of Paradox Interactive’s User Agreement.
There are a fair bit of articles that have been influenced by the CK2/EU4 wikis. An objective, third person written style is always better so I'd suggest to follow the guidelines and fix what should be fixed. As for the technical terms, what do you have in mind here? Stuff like "FTL" or technology names will be very common through the whole wiki, and I'd suggest not to italicize them to easy maintenance of the wiki.
The third person is highly preferred, especially outside guide articles.
Technical terms should simply be written as normal text.
- 1
My thinking was that initial capitalization of technical defined terms where they are used is often used in other contexts as an aid to readability and understanding, particularly when it makes a substantive difference whether the word is used in its common meaning or the defined meaning.
In other performance news, I've been trying out HHVM on another server of mine due to the performance issues users have experienced lately. What it does is compiles PHP to a faster language, which according to WikiMedia (the company behind Wikipedia and MediaWiki, the software my wikis run on) can speed up wikis by a factor of two or so.
The results so far seem pretty clear:
While the other server handles 1500 clients in a minute reasonably well while using HHVM, it can't even handle 600 using PHP (it handled 500 fine in an earlier test, so the barrier seems to be right around that level).
Instead, a queue of requests quickly built up, and the server ran out of memory, promptly crashing the database. The memory issue isn't especially relevant to the Paradox Wikis, as they have far more memory, but the CPU load certainly is.
I also ran a test to see how long it took to render a preview of a large page. That yielded the following results across five tests of each config:
PHP: 2.806s, 2.591s, 2.411s, 3.243s, 2.300s
Average: 2.670s
HHVM: 0.691s, 0.813s, 0.419s, 0.722s, 0.791s
Average: 0.687s
That's a near 4-fold reduction in time on HHVM.
As these results are highly promising, I'll be trying out HHVM in practice on the Paradox Wikis tomorrow morning. If all goes well, this should do a lot to stop the performance issues people have experienced.
The results so far seem pretty clear:
While the other server handles 1500 clients in a minute reasonably well while using HHVM, it can't even handle 600 using PHP (it handled 500 fine in an earlier test, so the barrier seems to be right around that level).
Instead, a queue of requests quickly built up, and the server ran out of memory, promptly crashing the database. The memory issue isn't especially relevant to the Paradox Wikis, as they have far more memory, but the CPU load certainly is.
I also ran a test to see how long it took to render a preview of a large page. That yielded the following results across five tests of each config:
PHP: 2.806s, 2.591s, 2.411s, 3.243s, 2.300s
Average: 2.670s
HHVM: 0.691s, 0.813s, 0.419s, 0.722s, 0.791s
Average: 0.687s
That's a near 4-fold reduction in time on HHVM.
As these results are highly promising, I'll be trying out HHVM in practice on the Paradox Wikis tomorrow morning. If all goes well, this should do a lot to stop the performance issues people have experienced.
Last edited:
- 2
Results are not clear when the images are borked.In other performance news, I've been trying out HHVM on another server of mine due to the performance issues users have experienced lately. What it does is compiles PHP to a faster language, which according to WikiMedia (the company behind Wikipedia and MediaWiki, the software my wikis run on) can speed up wikis by a factor of two or so.
The results so far seem pretty clear:
While the other server handles 1500 clients in a minute reasonably well while using HHVM, it can't even handle 600 using PHP (it handled 500 fine in an earlier test, so the barrier seems to be right around that level).
Instead, a queue of requests quickly built up, and the server ran out of memory, promptly crashing the database. The memory issue isn't especially relevant to the Paradox Wikis, as they have far more memory, but the CPU load certainly is.
I also ran a test to see how long it took to render a preview of a large page. That yielded the following results across five tests of each config:
PHP: 2.806s, 2.591s, 2.411s, 3.243s, 2.300s
Average: 2.670s
HHVM: 0.691s, 0.813s, 0.419s, 0.722s, 0.791s
Average: 0.687s
That's a near 4-fold reduction in time on HHVM.
As these results are highly promising, I'll be trying out HHVM in practice on the Paradox Wikis tomorrow morning. If all goes well, this should do a lot to stop the performance issues people have experienced.
- 1
Huh, somehow when I copied the images, they got copied as links rather than files.Results are not clear when the images are borked.
Fixed now.
These results are pretty amazing. Maybe I can convince my company to move towards this. The wiki software we are currently using hits nowhere near this performance. I imagine this will help with the massive hit the wiki will most likely receive upon the actual release of the game.
It turns out that due to running a slightly old version of Ubuntu, HHVM isn't currently an option for the wiki server.
We'll look into whether upgrading to a newer version of Ubuntu is a possibility though. The server itself is also likely to be upgraded in anticipation of the Stellaris and HoI4 releases.
Its a wiki, the easiest way to get more information on it is to write it.
- 2
Place should also include Steam trading card potential rewards, namely the wallpapers and icons.
Hey, Meneth, is this where suggestions for the Stellaris wiki are welcome? I have a few ideas I'd like to put forward.
Might be better if you put them on the wiki itself. If it relates to a page that already exists, put it on its talk page rather than here (or at least in addition to here).
If it doesn't relate to an existing page, here or on the talk page of the main wiki page both work fine.
.png){kind=avatar}
I read this 10x times and i am still not able to do Static Portraits
http://www.stellariswiki.com/Portrait_modding
http://www.stellariswiki.com/Portrait_modding
Is having a list of all components and their effects on the wiki even a realistic goal? I’ll thinking it would really nice to have each technology link to the specs of the components they unlock, but I’m not sure how massive of an undertaking that would be.
I think it would be much more doable with scripts to automate the work.
While we are at it, perhaps implement the tech tree somehow too...