User talk:VariousMetals
Contents
Math problems
Hi VariousMetals, yep you are right that the math-tag doesn't work properly too. For example {{Thrust}} also doesn't work. Did you get the same error when you tried it in your edit? — xZise [talk] 14:24, 14 May 2015 (UTC)
- I have next to no experience with wiki markup in general, so I spent a fair amount of time wondering why the only thing I wrote that would actually render was . The error message was just "PNG conversion failed", so I assume it's related to all the other file problems and it'll work again once they get fixed. VariousMetals (talk) 18:43, 14 May 2015 (UTC)
- Here's a thought: since the migration issue might not be getting fixed anytime soon, we should create "Category:File problems", and list all the pages that need to be updated once the file problems get solved.VariousMetals (talk) 18:57, 14 May 2015 (UTC)
Moved stats table
I have moved the stats tables as you suggested and by that also your note removed regarding the structural fuselage, but not because I don't agree but just because I didn't know where to leave that note and just want to finish something first before I handle that issue. So if you want you can go ahead and move it to another stats table or suggest something in the talk page. Just want to inform you here so that this part doesn't get lost. — xZise [talk] 14:06, 28 May 2015 (UTC)
Move help
Hi, if possible it would be nice when you suggest a move to help prepare it. For example if you want to move A to B and B doesn't exist yet, create a redirect to A and update the pages which use A to now use B. So that when I move it I only have to move it and not move any references.
Of course this should only happen on obvious suggestions and when there should be no redirect from A to B (e.g. because it's an internal template). — xZise [talk] 14:18, 8 June 2015 (UTC)
- Thanks for moving the page. I had left the links as is because I wasn't really sure whether replacing the original links would make it easier to move the page, and I was worried that it might make it more difficult if I somehow did something incorrectly and it had to be reverted. I'll add the links and redirect in the future. VariousMetals (talk) 14:57, 8 June 2015 (UTC)
Stupid question
Sorry, if you find the next a bit annoying, and not coherent, but I am drunk at this moment (love is suck: promising heaven, but opens the gates of hell), and I am not a pleasant person anyway. But before think I am JERK, worth to know, you are one of the few editor, whom I admit, worth to cooperate (Yes there are some, like kspjaptrans, mowaw...), and thinks about many cases about the wiki like I do.
According to the latest editons: don't you feel urge to put the cabins into the "monopropellant tanks" template as they holds some monopropellant?
The parts table system worked by classification of the main function. The tails are not practical in role of nose cones, and the services bay almost useless in cargo bay role (separate table). No one put a great wing for using a fuel tank! (In this case the landing cabins are monopropellant tank, and the small landing gear is an illuminator. The "non-modular" wings can be built together with the set of the modular wings, but not useful as winglets - as they are used to stabilize the rockets. The resource detectors separation from the detectors is acceptable, as they mainly used for another purposes.
Long story short: some kind of reconsideration is needed about this theme...
Yours sincerely - NWM (talk) 22:08, 8 June 2015 (UTC)
- The hierarchy of the Parts lists has been bugging me for a while too. I've been mainly focused up until now on just completely filling out the Parts page to include at least one instance of every currently implemented part. The reason I'd been dividing up hybrid parts into multiple tables and moving around parts between tables was to include as much relevant information in them as possible without messing up the table format or wasting space. So in the case of the "modular" wings, I wanted to preserve the already compiled information about the dimensions of those wings, and put the wings with no exact dimensions into a different table. In the case of all the "hybrid" parts, I started including them in multiple locations because I wasn't sure where to put them, and because it was impossible to include them in a single table without either: giving each one its own new table, including an awkward figure in parenthesis or a new column somewhere in the table for the information, or just putting the information in a footnote or leaving it out entirely.
- I'm still not sure about the best format for the Parts page, but as for the specific examples you mentioned, feel free to change them if you want, and anything else you notice. For the tail connectors and service bays though, I still think they're fine where they are, because they seem similar enough to the other parts in their tables. I'd recommend just renaming "nose cones" to "aerodynamic cones" and "cargo bays" to "cargo bays/service bays" instead of putting them in separate tables. VariousMetals (talk) 23:18, 8 June 2015 (UTC)
- the "Parts" page has grown fat, loads slowly, and maybe some category-template should be blanked temporarily for updating. Dividing to subpages have some difficulty as some parts have no even link to its table from its real category (example: LES). We should economize the repetitions.
- I reckon that, if a group of parts worthy for a separate page (and the service bays and the tails have such a different purpose), worthy for a separate table. And as all the wings - independently from their modularity - have same purpose, and the winglets have a different one (although, they can be used for building complex wings too). I don't believe if the fuel holding wings should be appeared among the fuel tanks, as no one use it for primarily, and even they are empty as default. - NWM (talk) 21:18, 9 June 2015 (UTC)
- The parts page has the same problems as the game itself. The "sort by function" format of the in-game parts menu hasn't changed since back when there were only a few available parts (namely, parts are only divided up into Pods, Fuel Tanks, Engines, etc., and each part only appears as an image until mousing over it) Recently, other filter options were added that sorted based on module, tech level, etc., rather than just a subjective singular arbitrary "function".
- A while ago, I pitched the idea to make all of the tables on the parts page expandable and collapsed by default. That's still an option, and I'm currently working on something over here to standardize all of the tables and make them collapsible and list the relevant modules in addition to primary function.
- Alternatively, what if we formatted the parts page to be the same as the in-game menu: a page occupied exclusively with a grid of the images of the parts and minimal information, that would load additional information upon mouseover? The benefit of doing that would be that we wouldn't be restricted by having to fit every part into a tabled format any more, so each part could have its own box. In fact, since we already have a /Box for every part, all that we'd need to do is make that appear. We could make it so the stats tables are used within their own pages rather than all in the one parts page.
- Actually, wait, that could work really well. I'm gonna go get started experimenting with that right now. VariousMetals (talk) 13:18, 10 June 2015 (UTC)
- If I might just throw a suggestion in here (browsing Recent Changes and spotted this), which may well be quite close to what you're thinking, or possibly even exactly it. ASCII art with a mixture of wiki stuff thrown in seems like an easy quick way to express it:
=== [[Parts/Pods|Pods]] === <!-- 1st in-game category --> [ICON] [ICON] [ICON] … [NAME] [NAME] [NAME} … [ICON] [NAME] === [[Parts/Tanks|Tanks]] === <!-- 2nd in-game category --> [ICON] [ICON] [ICON] … [NAME] [NAME] [NAME} … [ICON] [NAME] === [[Parts/Engines|Engines]] === <!-- 3rd in-game category --> ... etc
- Icon/name pairs would be in a div block each, so they would be as many across the width as would fit on the viewer's window, wrapping as needed to as many rows as required.
- The sub-pages would have an intro paragraph, stats table(s), and a navbox to jump around between the sub-pages. It's slightly unusual to use wiki sub-pages in main article space like that, but I think would actually work quite nicely. The main page becomes nice and brief, hopefully. It's certainly going to shorten the page size a good bit by losing the bulk of the info in the tables.
- Anyway, sorry for butting in, I hope you don't mind. :-)
Don't mind you butting in; actually, I was probably going to try contacting you anyway since you seem to be the CSS/Template expert around here.
That design looks like it would work for managing the bloat in the parts page. We probably need to wait until the file problems get fixed before implementing any of this, though, because until then we won't have images for a lot of the parts (also, I think even the images that are uploaded already won't render as thumbnails unless they've already appeared somewhere on the wiki in whatever specific resolution we use, so we'd be left with a page with only a grid of [File:Image_needed.svg] and tiny thumbnails.)
Also, for the idea I had about implementing a rollover stats table for each part: is that at all practical to do with wiki markup? What I basically had in mind was to make it so hovering over each thumbnail would make a box appear that's identical to the /Box page that each part currently has, and maybe to dynamically load it if possible so that the page doesn't have to load 200 unnecessary box templates at startup. VariousMetals (talk) 15:00, 10 June 2015 (UTC)
- Yeah, it's highly frustrating and/or impossible to work on more complex page layouts involving images right now. You're correct in your analysis that it's not just whether the image is already shown anywhere, but also the size(s) that it's currently shown at. In a nutshell, it looks like the server currently can only serve images from its cache, and is incapable of anything else involving them, including new sizes.
- Tooltips are an interesting topic, but also a complex one for anything beyond fairly simple hover text. It's pretty much always a solution involving JavaScript if you want something fancier than an optionally styled simple block of text. Dynamically loaded tooltips would be an "AJAX" solution, and there are a few different issues with that. First, it's quite a bit of code development time to get a robust solution which works well for all browsers. Second, server load does need to be considered, as it's potentially generating a fairly high volume of data requests. Third, stock MediaWiki isn't really designed to serve the short JSON or XML blobs of data needed for optimal dynamic tooltips.
- So, while I quite like the fancy dynamic tooltips idea itself, I'm uncertain if the cost:benefit for it makes good sense. It seems to me that it's something that isn't highly necessary until the number of parts/items pushes past a fairly high threshold. Yes, we're into a fairly large number of parts now (hence this discussion), but it's still small compared to some games out there, and not so difficult to remember at least the approximate key characteristics of parts.
- There might be some middle ground on tooltips, but most of the ways of making it "easy" would involve serving the data for them as part of the page itself, rather than dynamic loading. So, if total page data size is a concern, simpler is better in terms of the content of any tooltips. My instinct is telling me that we don't really need fancy tooltips (considering the relative cost of them), just a good way for the user to drill down. I'm seeing that as the top level being just a grid of (icon+name) boxes, with a quite minimal tooltip of only the most important info. That in turn drills down via click and new page load, to either an individual part's page, or a sub-page with the stats table(s) for the category.
- I will keep thinking about efficient ways to show the current infobox (or different simplified approximations of it) as a tooltip. So, this isn't a "no" to it, it needs a bit more thought on how best to go about it for a reasonable overall cost:benefit. Is it "practical to do with wiki markup"? No, not really. It's a fairly long way "outside the box" of what MediaWiki does easily by default. You will have likely seen such things on sites using a MediaWiki core, but the reality is that they will have server extensions and/or a lot of complex JavaScript driving it, plus significant development time to create the solution, and MediaWiki itself basically has close to zero support for it as standard.
.svg problem
As I see, you uploaded an .svg too, but the Wiki did not rendered it. And as we have remained without admins, we have to find out a common solution: We can upload the .svg and the .png rendered from it, but these .png-s should be categorized as "svg temporal subtitutions" for the easier later replacement (when the wiki is recovered from this migration). This maybe can be used for the equations too. NWM (talk) 22:11, 21 November 2015 (UTC)
- Right, I noticed. Temporary PNG substitutes is completely fine for now, although the images won't be scalable. The server renders (or is supposed to be rendering) the SVG images and the formulas as .png images anyway before sending them out, so it won't increase page load times. At least not beyond what they currently are: see my post here. Also, instead of a category, the temporary .png files should be identified with a template that displays an information box with a link to the original image and an explanation, similar to this one: commons:Template:JPEG version of PNG.
- By the way, it's not just uploading that doesn't work. Rendering .svg files into thumbnail sizes that don't already exist doesn't work either, just like PNG files used to behave. For example: Image:Ambox_warning_pn.svg
[[File:Ambox_warning_pn.svg|100px]]
- With regards to the migration problems: in hindsight, I find it odd that file uploading and thumbnail rendering (though not of .svg files, apparently) were fixed, but the other problems weren't. It implies the migration isn't necessarily "complete", like it says on the main page now. I think whoever's in charge needs to do a fresh reinstall all of the software currently on the server or something. --VariousMetals (talk) 02:58, 22 November 2015 (UTC)
The error message suggests the system is missing the rsvg utility (converts svg to png). Installing it should be enough. Peteletroll (talk) 09:21, 26 November 2015 (UTC)
- But there are no admins here nowadays, and the equations don't work too, and there are many of the updates needed now. So we have to act as admins' arrival and solution as a distant but hopefully happening even on the horizon of the time.. NWM (talk) 17:33, 26 November 2015 (UTC)
- An another ask: the characteristic curves of the panther still missing, would you be so nice to create them? Thanx! NWM (talk) 01:43, 4 December 2015 (UTC)
Jet thrust graphs
Hello VariousMetals
Firstly I want to thank you for the jet engine graphs at all.
Secondly I want to ask for potential improvements:
- I think, the thrust to pressure graphs would be more convenient / easier to understand if the X-axis was mirrored. E.G. instead of X being rising pressure, X being rising height. This because ~most~ jet engine missions start at 0 height rather than at 0 pressure.
- If transferred from pressure to height (instead of just mirroring pressure) the shape of the graph would change as height is not linear to pressure. Thus, the graph would get even more convenient, as height is displayed directly ingame.
- Integrating a deadline / ceiling height of the engine into the graph would be helpful.
- The R.A.P.I.E.R. graphs are missing on its page, yet being seen on the general jet engine page.
- The Thrust to speed graph of the Wheesley seems a bit broken, as it does not end at 0 thrust. (The engine is capable of going beyond mach 2)
I would like to read your thoughts on this.
Kind regards, Lone Starr
