Vindictus Wiki
Vindictus Wiki
Vindictus Wiki
Official wiki
9,778
pages

Talk: Community portal

Back to page
Sign in to edit
Archives


Item Categories[]

With the Season 2 update, the Admins decided it was time to "wikify" the wiki. And with that a lot of changes have come, including changes on the item templates. They now have 3 fields regarding the type of the item and they are "type", "subtype" and "category". The "type" field is to be filled with what the ingame item window shows and, in case it has a ",", the part after the comma would go into "subtype". But sometimes nothing shows in the item windows, but we still need to categorize those items nevertheless and that's what the "category" field is for. But what should we write there? Well, that's what I want to discuss with you, fellow wiki editors. I made a list of possible categories, divided by sections and wanted for you to check it out and point out anything that you feel that it's missing or if nothing is missing, that you agree with it. We need some guidelines for the future, and we need it them quick. You can find the list here: User:Sekuiya/Categories. I await for your feedback eagerly. Sekuiyatalk 04:11, 25 February 2013 (UTC)

Like I suggested, we could use the market categories for the ones that can be traded ^^' → Nedigo talk ― 04:16, 25 February 2013 (UTC)
Well, that list is very "marketplace-like" aside from a few things. First, "Expertise Material", most of these items appear in "Miscellaneous‎ Material" but I think they should get their own category, or, fit into the "Special Material" category. Another thing, regarding "Miscellaneous‎ Material", if we check the market, like I said, we see or Expertise Materials or lots of Crescent Moon drops, which is kinda weird. Those should go into the "Crescent Moon Island Drops‎" though.
Another thing, in the Accessory part, we have a category called "Necklace". I never saw any items under this category, so I just ignored it. The "Accessories" part, from what I gathered, it contains "Earring"s and "Jewelry" so I just broke down those two. And the "Other" one was also ignored, since from what I gathered, they're just for Earrings that are not usable, so they should go under the drops of their region or Special Material if they are made. I heard around that they are made but wasn't sure.
Aside from that, I broke down the Event category into 3 different categories, "Event Consumables", "Event Equipment" and "Event Story". I think these three are the only type of event items that exist ingame.
And that's about it regarding the marketplace. If you have a better idea, please, feel free to share it. Sekuiyatalk 05:13, 25 February 2013 (UTC)

Оrder of skills on character pages[]

For uniformity, I suggest that on the characters pages in the "Skills" section, make skills ordered by level. I think that it will be more convenient for readers of the wiki. Firstly, skills go like this ingame in the skill window. Secondly, it reflects the order in which the player receives them and gets acquainted with them: first, the initial skills, and more advanced ones after them.

I'm willing to work on making these changes for all characters.
This rule is important to approve and adhere to in the future in order to avoid an edit war between contributors.

At the moment, different characters have a different picture:

I would like to note that from the point of view of uniformity, such an order is very bad, because some characters do not have a linear sequence of smashes, but in general a unique mechanic where skills cannot be grouped into logical chains. For example, Arisha or Staff Evie. In addition, it will remain unclear in what order to put other single utility skills: before or after a group of smash skills. This will generate arbitrariness, and in the worst case, a war of edits on the pages, because each contributor will begin to change the order of skills based on their understanding of "how it will be right". Ordering by levels "as ingame" eliminates this problem.

I recently updated the list of Arisha and Evie skills and made them ordering by level. Because even with the alphabetical order, it was still not convenient to use the list.
On the example of Evie it was:

Such a sequence only confuses, complicating perception. But when ordered by level, they are at least presented in accordance with the game. And grouping them by types of elemental magic is a bad method, as I pointed out above - each contributor can have his own opinion where to place single utility skills, like Active: Hallucinate (gameplay-wise insignificant) and Active: Continual Focus (gameplay-wise very important).
--Kaiver (talk) 22:16, 9 December 2022 (UTC)


I have no objections to sorting the skills list based on level required to learn them as they are in the "Skills" window of the game. This should be valid for every character released up till now. Silverberg44 (talk) 19:32, 12 December 2022 (MSK)

Old skill names on character pages[]

For visual clarity, I suggest that on the characters pages in the "Skills" section, indicate only the actual skill name and remove the indication of the old names. Old names uselessly overloads the skill list and makes it difficult to perceive. And it doesn't add useful information.

I'm willing to work on making these changes for all characters.
This rule is important to approve and adhere to in the future in order to avoid an edit war between contributors.

I don’t see the point in informing the reader what name the skill had before, if he doesn’t come across it in the game. And for cases when old guides (on the wiki or other sites) use outdated names - we have a redirect mechanism that allows to find skills by old names through the search. Ofc, when cleaning out the old names, it is necessary to ensure the presence of redirects to new ones.

Examples of problem:

--Kaiver (talk) 22:17, 9 December 2022 (UTC)

Agreed. The naming issue has been present since the time when there were EU and NA regions separately, each having their own version of localization for... mostly everything. Now that NA and EU became Global, this is no longer the issue. Silverberg44 (talk) 20:45, 12 December 2022 (MSK)

Naming format for Skill Icons[]

For uniformity, I propose to approve a single format for naming skill icons.

  • If the skill name has a prefix like Active:, Alchemy:, Blast:, Trooper:, Grace:, Revelation: , then it should be in the icon file name.
  • Symbol : in the name of the skill (for example Active: Comet Dash) should be replaced with the symbol -
  • After the name of the skill, indicate (Skill) in parentheses through a space
  • If the skill has changed its name, then the icon must also be renamed, and not just the skill page.

Example of a valid name: Active- Comet Dash (Skill).png

Separately, need to talk about the presence of the symbol "-" instead of ":" All old characters from Lann to Delia (with the exception of Arisha) have "-" in the names of the icons of all Active: skills. However, since Miri - this format is no longer respected. This makes it difficult to work with content. I believe that you understand how important uniformity is.

I'm willing to work on making these changes for all characters.
This rule is important to approve and adhere to in the future in order to avoid an edit war between contributors.

Examples of NOT correct names:

  • Active Comet Dash (Skill).png
  • Active- Comet Dash.png
  • Active Comet Dash.png
  • Comet Dash (Skill).png
  • Comet Dash.png

For the Blink skill, the icon name will NOT be correct:

  • Battle Scythe- Blink (Skill).png

For the Life Drain skill, the icon name will NOT be correct:

  • Battle Scythe Life Drain (Skill).png

For the Active: Void Star skill, the icon name will NOT be correct:

  • SP Confusion Hole (Skill).png

--Kaiver (talk) 22:17, 9 December 2022 (UTC)

I see where you're coming from and approve the suggestion. The issue with colons is that the file manager doesn't seem to like it being in the file name, most likely because of its inner use. This led to instances where colons are either removed or replaced with "-"s. Bringing them to the same format should help when the time comes to perform edits when necessary. Silverberg44 (talk) 19:32, 12 December 2022 (MSK)

In the infobox in the description of the skill, make <Controls> bold[]

For better readability, I suggest bolding <Controls> in the infobox in the description of the skill.
This allows you to visually separate the block from the previous text and serves as a subtitle for subsequent activation methods.

An example where it is and looks good: Active: Mana Tracer.

I'm willing to work on making these changes for all skills of all characters.
This rule is important to approve and adhere to in the future in order to maintain uniformity of visual design.
--Kaiver (talk) 22:31, 9 December 2022 (UTC)

Deleting unused categories[]

The page Special:UnusedCategories currently lists 1000 unused categories. There are actually more, but the page caps the list at 1000, likely on the theory that a well-organised wiki should not reach the cap.

If I look at the list of categories at Special:Categories, and page forward from there, I find almost 1200 unused categories ranging from Category:Items_Crafted_Through_Expertise_With_5th_Vertebrae to Category:Items_Crafted_With_Zyarga's_Sword_Fragment. All these categories have zero members.

The page for an ingredient should (and indeed does) contain a list all the items that can be made with that ingredient. One way to do that is, for every ingredient, create a category containing all the items that can be made with that ingredient. But that's not how this wiki does it. It does it in a more efficient way, by running cargo queries on the tables at Special:CargoTables/Expertise_recipes and Special:CargoTables/NPC_recipes.

I wondered whether these currently unused categories used to be used, but their members had subsequently been deleted when the cargo query method was implemented. So I viewed the history of several of these unused category pages. In all the cases I checked, the history shows these categories have NEVER had any members. That is, it looks like these categories have never been used to achieve anything.

One odd thing is that these unused category pages do not seem to have been created by a bot. Based on the history pages I checked, they were created by several different users over an extended period, as if this was part of concerted plan of action, though the action never reached the point where members were added to the categories. I find that so hard to believe that I've been trying to think of some other explanation. This wiki was started on Curses, so I wondered whether some of the history got lost when it was transferred from Curses to Wikia around 2019. (Wikia was subsequently renamed to the current Fandom.) But this seems unlikely since the history is showing edits for these unused category pages from well before 2019.

Anyway, whatever the cause, the wiki has almost 1200 unused category pages that should probably be deleted. That would be horribly tedious to do individually. Is there anyone still active on the wiki who knows how to implement this by using a script? Scribe100 (talk) 12:21, 8 November 2024 (UTC)

Hello there! Using a script, I have removed roughly 1000 category pages that contained "Items Crafted Through" and "Items Crafted With" that you've pointed out. The page cache should update and clear out those pages.' → Silverberg44 talk ― 17:10, 11 November 2024 (MSK)
Great. Thanks for the fast response, Silverberg. Good to see the unused categories listing greatly reduced in length. Scribe100 (talk) 13:21, 15 November 2024 (UTC)

Deleting background images[]

I used to play Vindictus over a decade ago and have recently returned to see how the game has developed.

I have an interest in accessibility of computer games for the visually impaired. Visual impairment is not a binary on/off thing. There are degrees of impairment. Obviously those who are completely blind are not going to be playing video games. Those with very limited vision may cope with video games with simpler visual elements. They may stick to 2D games rather than 3D. They prefer games with a fixed frame of reference. Side-scrollers, where the frame of reference moves, add a level of difficulty. Those with better vision may venture into 3D games, but avoid games with features that make image interpretation difficult. For example, games that implement screen-shake are pretty much universally hated by vision-impaired players. Screen-shake can turn the on-screen image into random noise to a vision-impaired player, and each time it happens it can take a couple of seconds after the shake stops for the brain to lock back on to the image. Amongst 3D games, Vindictus is one of the easier games for vision-impaired players. It does have a few skills that cause viusal flashes when charged, but apart from that it's fairly benign.

Alas, the same can't be said for this wiki. Some of the original designers of this wiki decided to take an artistic approach which reduced accessibility.

Originally, this wiki was hosted on the Curses web site, which provided an easy way around the accessibility problems. If you created a Curses account, then once you logged in you could set your preferences to display the wiki in any theme you liked, overriding all formatting implemented by Vindictus wiki designers. So I could easily choose to always view the Vindictus wiki in the Monobook theme, the highly accessible theme used by Wikipedia. Unfortunately, somewhere in the ensuing series of takeovers and mergers that saw this wiki pass from Curses to Gamepedia to Wikia to Fandom, this feature disappeared. There does still seem to be a way to implement personal styles on Fandom but I'm finding it difficult to follow.

So I'm trying to gauge the attitude of current editors to see whether we can reach agreement to improve the accessibility of this wiki. As a test case I'm proposing one change: Let's eliminate the background images.

Background images reduce the readability of the text printed on top of them, reducing the accessibility of the wiki. If someone really likes an image from the wiki, they can make it their screensaver. They don't need us making decisions that force them to see some random wiki image poking through behind the text. So I think all the background images should go.

What do the rest of you think?

(I have been doing some research on how the background images are implemented. I'll wait to see what sort of response this proposal gets before spending time documenting the steps required to remove background images. For now I'll just flag that it will involve editing some protected css and javascript pages, so it's going to require help from someone with administrator rights.) Scribe100 (talk) 11:13, 6 December 2024 (UTC)


Hmm. No responses to my suggestion above. I'll go ahead and add the extra information about how to implement the proposed changes.

This wiki was created on the Curses wiki site, and due to various takeovers, was subsequently moved to Gamepedia, then Wikia and finally Fandom. The Curses site allowed (and encouraged?) editors to upload image files into a complex directory structure. So did Gamepedia, though some of the directory names changed, so some Gamepedia staff created redirections to keep things working correctly when the wiki moved from Curses to Gamepedia. By contrast, Wikia defaulted to placing all images in a single diretory under the File namespace. So when the wiki was moved from Gamepedia to Wikia, all the image files from the complex directory structure were transferred into a single directory under Files. This would cause many image links to die, so Wikia staff created more redirections to keep things working. The redirections mentioned in this paragraph aren't visible to us editors. We can verify that they are happening, but we can't see the code that causes them to happen. (At least, we normal editors can't see the code. I'm not sure if editors with Administrator rights can.)

I searched the current File: namespace and found 5 files that seem to relate to background images. They are Bg.png, Bg1.png, Bg2.png, Background.png and Background_test2.png. There is also a redirect at Bg3.png that goes to Bg2.png. I couldn't find any links pointing at Bg3.png so I suspect that redirect can be deleted.

There's a page at Background that purports to explain how the background images are implemented, but it's not up-to-date. It claims there are three files supplying background images.

If you copy the first of these three URLs into your browser, it redirects to 

https://static.wikia.nocookie.net/vindictus_gamepedia/images/3/3a/Bg.png/revision/latest?cb=20150126204104

We can see the redirect happens, because the URL showing in our browsers changes, but we can't see what makes it happen. This redirect would have been implemented when the wiki moved from Curses to Gamepedia. The latter two links show images existng at those URLs.

However, in all three cases, there is another hiddedn redirect that ensures that the three images actually used are File:Bg.png, File:Bg1.png and File:Bg2.png. We know this because if we follow those last 3 links to view the images, and scroll down to the "File Usage" section, it claims these images are used by the page Background. For example, the only way File:Bg1.png can be used in the page Background is if the URL https://gamepedia.cursecdn.com/vindictus_gamepedia/c/c2/Bg1.png that occurs in Background actually redirects to File:Bg1.png.

As an aside, every redirection increases a page's loading time. Hence, as a general rule, if you find a link that points to an image or page under vindictus.gamepedia.com or gamepedia.cursedcdn.com, consider replacing it by a link to the corresponding image or page under vindictus.fandom.com.

The Background page claims the default background image is first set by MediaWiki:Common.css to the file Bg.png, but is then altered by the javascript at MediaWiki:Common.js which makes a random selection from Bg.png, Bg1.png and Bg2.png. Both claims are out of date.

First claim: Default background image set by MediaWiki:Common.css. Presumably this was true when the Background page was created. However, when the wiki subsequently moved to Fandom, the default theme was set to MediaWiki:Fandomdesktop.css and this is where the default background image is now set. It seems that CSS in MediaWiki:Fandomdesktop.css is only applied to the regular wiki site, CSS in MediaWiki:Fandommobile.css only applies to the Mobile version of the web site, and CSS in MediaWiki:Common.css is applied to both versions. The mobile version of the web site does not use a background image, so the default background image is set in MediaWiki:Fandomdesktop.css rather than MediaWiki:Common.css.

If you search MediaWiki:Fandomdesktop.css for the css "background-image" property you'll find 4 occurrences. The first is commented out, so has no effect. The second sets the background-image to Background_test2.png for the style class theme-fandomdesktop-dark. The third sets it Bg1.png for the style class theme-fandomdesktop-light. The fourth is unrelated, setting the .battlePointsContainer style, which I'll come back to later.

Now in general I'm in favour of supporting both a dark and light style, but currently I'm not sure we can do this reliably, because we have several cases where templates contain individually hardcoded colours. Switching between light and dark mode doesn't change any of those hardcoded colours. If we want to make a serious attempt at providing dark and light themes without creating an administrative nightmare, the first step is to replace all those hardcoded colours scattered across templates by styles listed in Fandomdesktop.css, where there is code setting colours differently for light and dark mode.

Second claim: MediaWiki:Common.js changes the background image to a random selection from Bg.png, Bg1.png and Bg2.png. Go to MediaWiki:Common.js. and scroll down to the very last few lines of javascript to find the function changeBackg(). It doesn't match the code quoted in the Background page. Rather than randomly selecting from three different images, it "randomly" selects from one single image: https://vindictus.gamepedia.com/media/vindictus.gamepedia.com/3/3a/Bg2.png. Also, note that the javascript function is called by window.onload, a calling method with known difficulties. There are 4 problems here, the first three of which relate to the use of window.onload, and the 4th being more general.

1. The window.onload event is triggered when a page is fist loaded, but usually doesn't trigger if the user REloads a page. So on a reload Bg2.png won't get set as the background image, meaning the image will stay as whatever it was set to in Fandomdesktop.css.

2. Historically, browsers have behaved inconsistely when users load a page to one tab when the page is already open in a different tab. They might treat it as a new load that triggers the window.onload event or they might treat it as a reload that doesn't.

3. Fandom tries to run scripts from a large number of tracking sites and also tries to run scripts that insert advertisements in wiki pages. It is likely that many users use script-blockers to stop the attempts at tracking and to block the advertisements. For these users MediaWiki:Common.js never runs.

4. Currently MediaWiki:Fandomdesktop.css is setting the default background image to two different images depending on whether light mode or dark mode is selected. Then MediaWiki:Common.js overrules that, setting the background imaged to Bg2.png, no matter whether light or dark mode is selected. If we want to properly support light and dark mode, we should not be overriding the setting in MediaWiki:Fandomdesktop.css

Because using window.onload to call the changeBackg() function is unreliable, and because I believe that we should try to support light and dark mode in the long run, I suggest both the changeBackg() function and the window.onload command that calls it should be deleted from Common.js. Editing Common.js requires someone with Administrator privilege level. If that change is made, the background image will be whatever is set in MediaWiki:Fandomdesktop.css.

If editors agree with my suggestion that we should remove background images completely, then we should also edit Fandomdesktop.css, which also needs administrator privileges. We should replace the code setting the background-image property by code that sets background-color. At first glance it might seem we should set background-color to black for theme-fandomdesktop-dark and to white for theme-fandomdesktop-light. But as mentioned above, we also have templates that set hardcoded colours manually and I don't understand those well enough to see all the implications. It's possible that selecting light mode results in some white text on a white background colour. I guess we just try it and see what happens. If light mode does fail spectacularly when the background colour is set to white, then set it to black and leave a comment in the code explaining that we'd like to set it to black, but we can't do that until we fix the hardcoded colours in the templates.

Finally, there's 3 loose threads to pick up.

1. I flagged earlier that there is a .battlePointsContainer style. Both Common.css and Fandomdesktop.css set the background image for the the .battlePointsContainer style to be https://vindictus.gamepedia.com/media/vindictus.gamepedia.com/7/72/Battle_Points_Background.png. The file Battle_Points_Background.png does not seem to exist on this wiki. CSS usually fails gracefully when it can't find a file, so I suspect any attempt to use the style .battlePointsContainer would simply not apply a background image. Having said that, I haven't been able to locate any pages that use the battlePointsContainer style class, or the the other related styles in that section, battlePointsText and battlePointsContainer. I suspect these styles are obsolete, and are safe to delete, but I'm not sure how to go about proving that.

2. I noted above that CSS in MediaWiki:Fandomdesktop.css is only applied to the regular wiki site, CSS in MediaWiki:Fandommobile.css only applies to the Mobile version of the wiki, and CSS in MediaWiki:Common.css is applied to both versions. Currently there is some duplication between MediaWiki:Fandomdesktop.css and MediaWiki:Common.css. For example, the very first definitions in the two CSS files are identical, setting a Cinzel font. Another example is the .battlePointsContainer style mentioned in point 1. Duplications like these shouldn't happen.

3. The MediaWiki: namespace contains three javascript files. These are MediaWiki:Common.js which has been mentioned earlier, MediaWiki:Fandomdesktop.js, which is actually empty, and MediaWiki:Mobile.js, which contains only one line.

Based on how the css files behave, I would have guessed that MediaWiki:Fandomdesktop.js only runs for the normal version of the site, MediaWiki:Mobile.js only runs on the mobile version and MediaWiki:Common.js runs for both. I mentioned earlier that the javascript code that replaces the default background image by Bg2.png is in MediaWiki:Common.js, so if my guess was right the mobile site would have a background image, but it doesn't. I wondered if maybe the mobile version somehow overwrites the background image. So I checked by using the Firefox Web Developer Tool to directly examine the styles being set on each element, and it seems no background image was ever set, so MediaWiki:Common.js is not being run on the mobile site. This seems odd, so I'm wondering whether I missed something.

-Scribe100 (talk) 08:43, 13 December 2024 (UTC)

Hello there. It seems that the script that involves automatic random background change works from the js file that isn't visible in the wiki and in my opinion are located somewhere on the server. The attempt at removing the script ended in failure as it continues to work despite the changes. Changing the Bg2.png to another picture e.g. of the plain color solves the issue, but is a bandaid solution that isn't the thing one would want to achieve.
For the lack of response to your suggestion the answer is quite simple: there are 1-3 people at most managing/posting changes to the wiki, including yourself. There is no incentive to do so and not many buy the "out of good will and enthusiasm" shtick. Not counting that, the wiki is completely abandoned by people and GMs both.
Another reason could be that the Community Page isn't visible on the main page, which is why people don't even acknowledge its existence. Added it to the main page.
I recommend to use the available channels like Discord for more flexible response.
-Silverberg44 (talk) 21:23, 13 December 2024 (MSK)

Hi Silverberg.

I've just been reading some of the help pages about javascript and css at community.fandom.com, and have been learning about the need to submit javascript changes to Fandom for approval. This is new stuff to me. But I see you made the changes to the Vindictus wiki's Common.js that was submitted for approval on 10-Sep-2021, so I guess you know about the approval process already.

I see you made several changes to Common.js on 7-Dec-2024. The changes commented out the changeBackg() javascript function that replaces the default background image by Bg2.png as the background imaged, and also commented out the window.onload call that makes it run. You then reverted to the 10-Sep-2021 version. Those changes weren't submitted to Fandom for approval, so I'm assuming you used the testing tool to temporarily apply the changes to see what effect they had, and that you found they had no effect. I'm also assuming you know about caching issues and used the appropriate special way to reload pages that avoids using cached copies. That would explain your suggestion that there is some other function that we can't see that controls the background image.

https://community.fandom.com/wiki/Help:Advanced_CSS_and_JS

From the above link, I learned that appending ?usesitejs=0 to the URL of any wiki page will disable the wiki's locally defined javascript, and based on other similar pages I believe this means only javascript in the wiki's Common.js and Fandomdesktop.js is disabled. When I tested appending that code, the wiki pages I viewed did use the default background image set by the css, and did not replace it by Bg2.png. To me this is a strong hint that it is the changeBackg() javascript function in Common.js that is causing Bg2.png to be displayed as the background image.

So I'm wondering whether there might be something buggy in Fandom's testing tool mentioned above. Would you consider redoing the edits to Common.js that commented out the changeBackg() function and window.onload call that makes it run, and then submit that changed version for approval?

On another issue, I see that on 7 Dec you also made a change to Fandomdesktop.css to change background-color. This CSS property was previously set to rgba(20,20,20,0.85). The last argument sets opacity to 0.85, so the default background image doesn't show through very strongly. You changed it to rgba(20,20,20). I believe this will cause an error, since the rgba function requires 4 arguments, and doesn't have a default that it uses if the alpha channel number is missing. Thus I think a browser fully compliant with the CSS 3.1 standard will ignore the entire command so background-color will not be set, and the background image will show at full strength. Or at least that's what happens if we use the URL suffix to disable javascript. If we don't then the function in Common.js resets both the background-image and background-color.

If your intention was to try to override the background image with a background-color that had no transparency, then I think you should replace the rgba function by the simpler rgb function that only expects 3 arguments. That is, use rgb(20,20,20), though rgba(20,20,20,1) would also work.

My reading at community.fandom.com also alerted me to a couple of errors in my previous post.

1. CSS: The mobile site does NOT use Common.css. It only uses Mobile.css. The normal (desktop) site uses both Common.css and Fandomdesktop.css, in that order.

2. Javascript: The mobile site does NOT use any javascript. The normal site uses Javascript from both Common.js and Fandomdesktop.js, in that order. So the file at Mobile.js doesn't do anything and can presumably be deleted.

-Scribe100 (talk) 08:25, 22 December 2024 (UTC)

I have submitted the modified version of the Common.js (that has the script commented) for review. Hopefully it passes and should resolve the issue.
As for the change to background color, this was my attempt at responding to your suggestion regarding background distractions. I did some reading that the rgba function should work normally even without the 4th parameter for alpha.
For Mobile.js, I'll see if removing it does anything (probably won't cause any issues).
-Silverberg44 (talk) 21:16, 22 December 2024 (MSK)

Hi Silverberg.

I retract my comments about the rgb and rbga functions. After seeing your comments I eventually found time to do some tests which showed that using rgba with only 3 arguments did set the "missing" opacity argument to 100%. So I've just been reading the W3C standards and I'm out of date. The functions both now support exactly the same set of arguments so they have become fully interchangeable. Relevant section of standard:

https://www.w3.org/TR/css-color-4/#funcdef-rgba

Which raises the obvious question of which form is preferred, rgb or rgba. W3C doesn't seem to make any recommendation on this. Their site contains compatibility tests for the 4 major browser families, and they don't show any support differences between the rgb and rgba forms, so I'm guessing browsers now just treat them as synonyms. My first thought was that for better readability, we should prefer rgba when specifying the opacity and rgb when not specifying it. W3Schools has a page with examples that follow that approach.

https://www.w3schools.com/cssref/pr_background-color.php

But then on another page they state "Note: The rgba() function is an alias for the rgb() function. It is recommended to use the rgb() function."

https://www.w3schools.com/cssref/func_rgb.php

-Scribe100 (talk) 01:16, 30 December 2024 (UTC)

Hi Silverberg.

I see your edits to common.js have been approved and gone live, and after clearing my cache, I can see that this has fixed the problem. That is, Bg2.png is no longer being used as the background image. So it looks like there is something buggy in the tool you were using to test changes to the common.js.

So now the background image is under the control of Fandomdesktop.css, and it is using either Bg1.png or Background_test2.png, depending on whether the light or dark theme is selected.

I'm not sure whether you agreed with my proposal to remove all background images. If you do, you can now move onto removing the css that sets those two background images. At first I thought this could be done by removing the whole css paragraphs that set those images, but I've just realised I don't actually understand what the "--theme-page-background-color--secondary" sections do. I'll have to do some reading to figure that out.

Edited to add: It just struck me that the css referenced in the previous paragraph was possibly not hand-written, but rather was generated via the Theme Designer described at: https://community.fandom.com/wiki/Help:Theme_Designer. Hence, rather than manually editing the css file, the first thing to try is to see whether Theme Designer is showing the file names Bg1.png and Background_test2.png as the selections for background images for the light and dark themes. If so, changing those should update the css appropriately without us having to figure out what --theme-page-background-color--secondary does. So we just have to hope that Theme Designer does have an option to select "none" for the background images.

-Scribe100 (talk) 03:13, 7 January 2025 (UTC)

Hello there, Scribe.
Regarding background, I don't think that's something that must be decided on a whim, but should should be taken to discussion with other people for the third opinion on the matter, whether they prefer the background or plain color.
I suggest taking it to the discussion via other medias, such as Discord, as there are people that we can communicate with and get a manner of response.
Regrettably, beside you and myself, there are hardly any people interested in joining the discussion here.
-Silverberg44 (talk) 14:06, 7 January 2025 (MSK)

Copyright and Story order[]

I've recently been creating wiki pages for the some of the early tutorial-style stories created during the last decade, that haven't previously been documented on the wiki. Doing this raised two issues, one relating to copyright, the other to the order for listing stories.

1. Copyright

Most of the story pages on the wiki contain a section called "Story Dialog", where some wiki editor with way too much free time has painstakingly typed in the complete NPC dialog for the story. I've got two problems with this.

Firstly it seems to be a blatant copyright violation.

Secondly, it just doesn't seem that useful to me. Let's be honest here. Vindictus has many great features, but the quality of writing in the English-language version is not one of them. The story dialogue doesn't really warrant preserving in a wiki. Often it seems to have been produced by a translator who isn't entirely comfortable with English. The dialogue rambles, repeats itself and sometimes contradicts itself. The meaning is sometimes unclear. The grammar and punctuation can be appalling. There are frequent inconsistencies in the names used for game objects, probably due to translation discrepancies. Sometimes tutorial stories totally fail to mention a key issue. Some tutorial-style quests incorporate images of game interfaces that don't quite match the interface the game actually uses. (Perhaps the images were originally correct but the interface was subsequently redesigned and the images in the story were not updated. Perhaps the tutorial stories were being written at the same time the interfaces were being designed, so the images were based on beta versions of the interface and were never updated for the final release.)

So in the new wiki pages I recently created for the early tutorials, I deliberately did not include a "Story Dialogue" section. Instead I included a much shorter "Story Dialogue Summary" section which hopefully briefly states the important information from the story, and sometimes adds a key point or two that the story did not mention but should.

While I believe the Story Dialog sections in most existing story pages infringe copyright, I not going to start deleting those sections. But when I encounter a story where the dialogue is particularly lengthy or pointless, I may be tempted to add a short "Story Dialogue Summary" section before the existing lengthy "Story Dialogue" section.

Mainly, I'm writing this in the hope that other page creators will think twice before going to the effort of producing verbatim copies of story dialogue. Please consider whether readers would find it more useful if you instead produce a much shorter summary of the imporant points. And that willl probably take you less time that typing in the lengthy story dialogue.

2. When I created new story pages, I haven't yet added them to the Stories page because I was having trouble deciding where to put them in that list.

I'm currently thinking the list of stories at Stories will be most useful to readers if it lists stories in the same order as used by the in-game Stories Window, accessed with the M shortcut key. The order of headings it uses is:

  • Key Story
  • Main Stream: Season 1
  • Sub Story: Season 1
  • Similar headings for Seasons 2 to 4
  • Equipment Story
  • Content Story

At least, that's what I've seen so far. There may be other headings I haven't seen yet because I haven't yet received any quests that fall under those headings.

Making Stories order match the in-game Story Window order doesn't seem to require major changes. The Storage wiki page does subdivide the season stories into episodes. The in game Story Window does NOT have headings for episodes, but it does seem to use a sort order based on episodes, so no change is required there. For the moment, I think all I'd need to change on the Stories wiki page is adding a "Key Story" section at the start and a "Content Story" section at the end, and maybe move a small number of existing stories to the "Content Story" section. (More on that last bit later.)

The wiki didn't have a key story category, but I've now created the page for the Guide Story - Grow story, so there is now a category page for Key Stories.

There was already a category page for Category:Content Stories containing 13 stories, and I've added 2 more. About half of the 13 stories don't appear in the list of stories at Stories and about half do, but the later are scattered across many different headings, including Niflheim Stories and Season 2 - Episode 1 - Substories. None of my characters currently have these quests appearing in their Story Window, so I haven't managed to verify that they appear under the "Content Story" heading there. If they do, then I suggest it makes more sense to put them under "Content Story" heading on the Stories page, because I think that any players consulting that wiki page to find that story will be wanting to know where to find it in their Story Window in game, and they won't care the slightest about which episode the story was released in.

That's my current plan. As always, happy to hear counterarguments from other editors.

--Scribe100 (talk) 08:04, 23 June 2025 (UTC)

Templates Infobox Battle and BattleInfoBox[]

Editing templates needs higher level access, so can I only make suggestions.

Template:Infobox_battle This currently has fields "prerequisites" and "leads", which is fine. But another relevant constraint is that most battles belong to a story, in the sense that the story requires the player to complete that battle to progress the mainstream storyline. That story will also have ordering constraints, which are recorded in the "prev" and "next" of the template Template:Infobox_story. But what's currently missing is an easy way to find your way to the story constraints from the battle page. To fix this, I suggest we add a new field to the "Infobox battle" template that points to the story that it belongs to. I prefer longer more meaningful field names, so I'd probably call the field "BelongsToStory". I guess we could also add a corresponding reverse field called "ContainsBattle" in the "Infoxbox story" template, but I suspect that's unnecessary since that information is already easily found in the "Steps to completing" section.

The file at Template:BattleInfoBox seems to be an early obsolete version of what eventually became the "Infobox battle" template mentioned above. I believe it can be safely deleted. Since I can't edit templates, I can't put the tag on it to flag it for deletion, so I'm making the suggestion here. It doesn't appear on the Special:UnusedTemplates page because there a single link to it from the user page of a user who has been inactive for 15 years. (And yes, when I gave the address of this template page at the start of this paragraph, I deliberately didn't make it a link, since that would created a second reference to an obsolete page.)

Hmm. Seems somewhat excessive that our wiki's UnusedTemplates has over 100 unused templates. I'll add that to the bottom of my list of things to investigate further, a list so long that I'll probably never reach that item.

--Scribe100 (talk) 02:42, 28 June 2025 (UTC)

Missing prices in equipment stories[]

I found a bunch of pages that contain a failing #show command. The pages relate to equipment stories available from Aislinn's shop. Each case has two relevant pages.

1. A page for the SCROLL item which can be purchased. This page correctly displays the scroll cost. Example: Story:_Premium_Rookie_Set

2. A page for the STORY which you can complete once you purchase the scroll. This page includes an attempt to display the scroll cost, but the attempt fails due to an error. Example: Premium_Rookie_Set_(Story)

I'm not a fan of the naming scheme adopted here. If I saw the name Story:_Premium_Rookie_Set in isolation, I'd assume it's the story, but it's actually the scroll. To me, the sensible name for this item is Scroll_Premium_Rookie_Set.

Anyway, let's put that aside for the moment, and talk about the error.

But first, some background. The basic install of MediaWiki does not include any database features. There are two separate extensions that can provide database style commands.

(a) Semantic MediaWiki. https://www.semantic-mediawiki.org/wiki/Help:User_manual

In this extension, the most commonly used commands to perform database queries are #ask, which is used to return data from several rows of a data table, and #show, which is used when you seek data from a single row of a data table and you know a key that specifies that row. Since #show is performing a simpler task than #ask, it has a much simpler set of parameters.

(b) Cargo. https://www.mediawiki.org/wiki/Extension:Cargo

In Cargo, the most commonly used commands to perform database queries are #cargo_query and #cargo_compound_query, which are comparable to #ask. Cargo doesn't have a simpler command comparable to #show. Cargo data tables can also be accessed with Lua or SQL commands, but they cannot be accessed with the Symantic #show and #ask commands.

Semantic and Cargo are both available on Fandom.

Cargo is a more recent development. Originally databases in the Vindictus wiki all used Semantic, but more recently many have been converted to Cargo.

For the Equipment Stories mentioned above, the relevant history pages show the move from Semantic to Cargo started on 17 May 2018, when template Template:Cost was created, which allows the purchase price of items to be stored in the cargo table Special:CargoTables/Cost. Then, over a day or so, the scroll pages (Type 1 above) were edited to remove the Semantic code that stored the purchase price in a way that would allow it to be accessed by a Semantic #show command, replacing it by code that calls the cost template to store the purchase price of the scroll in the new cargo table Cost. However, the corresponding story pages (Type 2 above) were never correctly adjusted to grab the purchase scroll from that cargo table. Instead, those pages are still trying to use the Semantic #show function, which of course fails, because the data is no longer in a form accessible by a #show command. Hence in the story page we see {{#show: Story: Premium Rookie Set|?cost}}, indicating that the wiki could not process the #show command, so instead just displayed the command.

The weird thing about this is that I can't find any evidence that any attempt has been made to use data in the cargo Cost table. I've been through all the story pages, and looking through their history pages, no edits were ever made to try to access the Cargo Cost table. The Cost table also contains a huge number of items other than scrolls. There's so many of these I couldn't be bothered checking them all, so I checked a few for more common items that would be used in constructing many items. That is, I checked items that would gain most by having their price in a table that could be accessed by MANY other pages, and again could not find any attempt to even refer to the cost price of the item in other pages that refer back to that item. It's as if someone decided to put a whole heap of purchase prices into a table without ever having an intention to access those prices from other pages.

We could fix this by replacing the #show command by the appropriate #cargo_query command to extract the cost from the cargo Cost table. I haven't had much experience with databases and have no prior experience with cargo, so it took me a couple of hours to figure out how to do this. I can't guarantee I've got the best solution, but the following seems to work. 

{{#cargo_query:
tables=Cost
|fields=Cost.Price
|where=Cost._pageName="Story:_Premium_Rookie_Set"
}}

Line breaks in the above are just for readability and can be removed when inserting the code into a page.

To prove that this works, I made the change in the following page. Kobold_Winter_Suit_Set_(Story).

While that solution works, I'm not convinced making this adjustment to all to the other equipment story pages is the right way to go.

This wiki used to have many regular editors, but has gone quite in recent years. No doubt, part of the decline will be due to declining player base in the game. The wiki has also had a messy history, starting on Curses, but subsequently moving to Gamepedia, then to Wikia, which was renamed Fandom. Each move caused something in the wiki to break, so likely some editors gave up in frustration.

But I suspect some potential editors are turned off by the complexity of the wiki. I think we need look for opportunities to simplify the wiki when we can, and this is one of them. The cargo extension is complex and not well documented, which helps explain why the error in the story pages has apparently existed for 7 years with nobody figuring out how to fix it. So I suggest we abandon the cargo table. We could revert back to the previous Semantic code, but even that's hard for non-tehcnical editors to understand. So I suspect we should go to an even simpler approach that will more easily understood by potential new editors. Hard code the purchase price of the scroll into both the story page and its scroll page. Then put a comment in the code where the prices are set, reminding editors that if they update the price they should also update it in the other page.

I know that this suggestion would make skilled database coders cringe, but given these errors have existed in the equipment quest story pages for 7 years without anyone fixing them, I'm fairly confident that it's a long time since any skilled database coders have done any editing of the wiki!

--Scribe100 (talk) 12:42, 28 June 2025 (UTC)

Oath of Honor Removed?[]

I see the Battle Points (BP) page still refers to Oath of Honor, a concept I remember from before I took a decade long break from the game. Also, several battle pages also still list the relevant Oaths of Honor, but as far as I can see, for all the missions my characters can access, they no longer exist.

Can anyone confirm that they are completely removed?

If so, I'll start removing them from wiki pages whenever I see them. If not, I'll just remove them from the battle pages where I have a character high enough to confirm they no longer exist for that particular battle. Scribe100 (talk) 07:59, 6 November 2025 (UTC)

Community content is available under CC BY-NC-SA unless otherwise noted.