this page will be dedicated as communication channel for you about your contributions.
Tutorial work in progress
Hi, I saw you submitted new page under tutorials section, well actually you made two of them. Now only this one can be approved: http://modding.scssoft.com/wiki/Tutorials/SCS_Blender_Tools/Staying_Organized_in_Blender as you used proper page title (with navigation: Tutorials/SCS Blender Tools). However I will still wait for you to finish it and then I will approve it, deal? 50keda (talk) 50keda
Yes, sorry; I'd forgotten about the Tutorials/SCS Blender Tools section when I first started writing. I hope I did the right thing by moving it. Perhaps I can either leave a note on its talk page, or your talk page when I think it's ready for review/approval. ;) Smarty (talk)
It's back. Sorry I wasn't careful by deletion. The problem was that when I was navigating to "Advanced/Staying organized in Blender" and wiki automatically redirected me to it's redirect page (which was SCS Blender Tools/Staying Organized in Blender) where I pressed delete :D So I reverted it and finally deleted correct page ;) 50keda (talk)50keda
I am not sure about legitimacy of your latest additions in the user page. Not sure if links pointing to mods is a good idea, after all this is modding wiki, not mod sharing website. Sorry for any inconvenience. 50keda (talk)50keda
Sounds reasonable. I think this latest revision should meet your recommendations. My eventual goal regarding the list of mods is to highlight some unique features/advanced techniques used in each and link within the wiki to tutorials and documentation to guide the user towards producing similar results. I figure if I set the example, maybe someone with actual talent might do the same. ¯\_(ツ)_/¯ Smarty (talk)
- This page seems to be unfinished: http://modding.scssoft.com/index.php?title=Documentation/Engine/Units/accessory_paint_job_data&oldid=2807 right?
- All the new pages under Units subpage should have unified title with proper capital letter on start and unit class name in brackets eg: "Accessory paintjob data ("accessory_paintjob_data")".
- Ok, I'll work on setting up the moves after breakfast. Smarty (talk)
- I (Documentation/Engine/Units/Accessory_data_(%22accessory_data%22)|tried one) but it looks like there is no way to preserve the underscore (_) in the title. I think it might be better to omit the part in parentheses entirely. The class name with underscores is included, bolded, in the first sentence of each article already (a deliberate convention) so including it in the page title seems redundant. Let me know what you think. Smarty (talk)
I'm thinking of using (Documentation/Engine/Shaders) as a general hub for the technical documentation (see Units and (Documentation/Engine/Units/accessory_data|Units/Accessory_data) for an idea of the general organizing structure I'm thinking of), splitting off into something like (Documentation/Engine/Shaders/Eut2/Dif_spec) for each general effect family, following the folder structure of
//effect/..., and then additionally having (Documentation/Engine/Shaders/Eut2/Flavors) as a sub-hub for flavours. Thoughts? Smarty (talk) 01:42, 21 September 2016 (CEST)
Please do not edit modding changes pages, because this pages are not yet in final stage ;) It's true I should add WIP template to the page, so it would be clear we are not yet done with it ;) Thx. 50keda (talk)50keda
Ok, sorry. I'd just noticed some little spelling mistakes and assumed I wouldn't screw anything up fixing it while you were all presumably asleep (like an underwhelming tooth-fairy). I shall keep my grubby hands off in the future. :P Smarty (talk)
I finally took time to go trough your units wiki. However we have several request for your before they will go online:
- Remove Raw Unit Definition sections, because for normal user/modder is just a confusion rather sth helpful.
- Remove Subclasses sections, again user/modeer will be just confused by it. It's already enough they have parent class link.
- Remove deprecated attributes from tables, because one will already be notified wih warning directly from the game.
But otherwise the quality is ok?
- I don't completely agree. I think it can be helpful with navigation, and with understanding the relationship between the units. I'm going to try and gather some feedback from a few modders I know at different experience levels today and see if maybe there's a way it can be tweaked or improved. I hope that's ok. :) (If it still turns out that it's irredeemably confusing, I'll annihilate it.)
There are a few things where I'm not sure whether my explanation is technically correct/complete:
detail_model vs model vs lods – I think I have this correct for accessory_cargo_data and accessory_chassis_data but I think accessory_cabin_data uses a special case with lods for mirror views (Volvo 2012 iirc). Could someone clarify?I looked again and realized/remembered the mirror LOD's are unused. (That's a damned good idea though!)
- suitable_for/conflict_with – Isn't there another control character besides asterisk (*)?
- accessory_wheel_data→inner_width/inner_radius – Are these deprecated, or just mostly unused?
- accessory_cabin_data→toll_tag – Are we considering this attribute deprecated?
To be fair we didn't read all of it, it's just too much to read and check. However if you have doubts about some attributes then just don't write them up ;) + IMHO this wiki pages are not sth that modders are striving for that much as for tutorials. So maybe instead of describing each unit (which can be changed with any game update) your powers might be more useful on tutorials pages ;)
- You can ask them, but there was a decision, that this sections won't be published so don't bother :)
Actually, you'd be surprised. I get asked for this kind of info fairly often – Usually people asking for an engine, etc equivalent of my animation cheatsheet. Plus, a lot of people I've shown the WIP unit articles to have found them helpful. Tutorials are important too, but they're generally not good for quick reference after you've completed them. Regarding game updates, as long as there are still modding guides released per version, the unit pages aren't that hard to maintain. I think the 1.6/1.27 changes took me like 15 minutes. :P
Regarding the Subclasses sections, that's an unfortunate decision IMO. Is there any chance of an "appeal" considering my last revision to them? My "focus group" found it much less confusing — even helpful. ;)
Hi again! It's been a long time since I last revisited your changes on matter of definitions. Once again I would really like ask you to remove subclasses sections from all of the topic, cause:
- if each "class" has already written it's parent you got it covered. The thing is giving reader two directions will only confuse him. Also in general tree should be read better from bottom up.
- we can't provide you full subclasses list which again makes it confusable
- as you can see there is also a lot of subclasses still left undocumented (still hat down for your patience to write all this docs), so why having them there and look like wiki pages on the matter are unfinished?
After that I would really like to finally approve your massive work on writing those ;)
Alright, subclasses have been wiped. I moved the lists to each page's discussion page so I still have a reference for which articles still need to be written. (I do plan on 'completing the set' one of these days...)
Okay :) Well I quickly went over accessories docs again and I still have small "requests":
- please gather all possible types you are describing under each class (eg. resource_tie, token) and update table of possible unit attributes: http://modding.scssoft.com/wiki/Documentation/Engine/Units#Attribute_types ,
- for arrays I would rather see to have this kinda C++ template format eg. array<float>,
- for unit pointers please use: unit_pointer & for arrays as I said array<unit_pointer> or simple create two types in attribute tables: link_pointer & owner_pointer,
- now for attributes you don't know what they mean, I would simply hide them (leave them in source, but just not make them visible for usual reader),
- also hide fully undocumented pages like "Related units" on this page: http://modding.scssoft.com/index.php?title=Documentation/Engine/Units/accessory_sound_data&oldid=3158 .
Thx & may patience be with you :)
That's the funny thing about being a 3D artist – If I didn't have patience, I would have gone crazy by now. :P
- Done afaik. I added a 'notes' column to the table to clean things up. Lots of room for Max to explain the 'fixed' types and what differentiates them from int, int2, etc. XD
- Done (I would rather it match the -dump_units output, but that's not public anymore so ok.)
- Done ...I think.
- Should be more or less done. I'm leaving the PJ flipflake attributes in because they're well-known. I'll try and write up a description for them later tonight (I know what they are, but they're tough to describe.).
- Undocumented, you say? Whoops! Where did those come from? ;)
Hi, after a long time, I took time to go over your changes.
- I have problem with this one: https://modding.scssoft.com/index.php?title=Documentation/Engine/Units/accessory_horn_addon_data&oldid=4638 Please only write the attribute of accessory_horn_addon_data and not the inherited attributes.
Documentation/Engine/Game data/Player trucks definitions
Intro is not really true. There is no complementary unit systems there is just one :D So first sentence can be completely removed. Further more I would rename first section (Data Definitions) to "Vehicle Parts Definitions" and second section (Vehicle and Dealer Definitions) to "Vehicle Configurations". 50keda (talk)50keda
I've made some revisions. The first sentence is more passive/benign now, and I've reformatted the intro to be clearer overall. I'd like to keep 'Data' in the first section title if possible. Consider the usage: The parts data is attached to vehicle_accessory, etc via the attribute data_path. So having Data in the title helps reinforce this connection, imo. (There's method to my madness!) :) Smarty (talk) 16:30, 10 March 2017 (CET)
I know you won't like me for this however I must tell you that we don't want under construction pages to appear:
- not finished topic doesn't help anyone (yeah it's nice to see someone is working on sth however actual content is under constructions so is it valid? Can I use informations provided there?)
- I don't have that much time to check each your action in the topics. So once you create under construction one I will have to approve every your action and control whole topic each time you edit, simple no go for me.
This was actually to clearly mark topics that are still WIP so that they don't accidentally get approved. ;)
Ah. Well don't worry using note stating WIP in there is enough ;) However even without that it will sooner happen that sth doesn't get approved then vice versa :) However I don't want file repository to get bloated with just temporary images ;) Thx for understanding.
Haha, fair enough. I'll have to find another way to sneak the cone monster in here though; That guy is delightful! :D
Documentation/Engine/Units/accessory sound data
In the description of attributes for this unit, you can simply use links? For example: "Points to a sound_data unit which defines the sound to play when the engine is starting." where sound_data can be directly link to that unit no?
I think that would make the page very messy. Most wikis strongly discourage multiple wikilinks to the same article within one article, and I tend to agree with them. In this case, all three sound data units are already linked in both the introduction and the Related Units section. I think that's sufficient. ;)
as you are one of most active and informed contributor, I would like to ask you sth. As you like looking into units and game file structure, would you be so kind and try to update Documentation/Engine/Game_data page (e.g. we are missing road events etc.)? I'm sure that you are able to do it as you are able to decompose almost all units on each update.
I'll give it a shot. I can't guarantee any timeframe though – work's been busier than ever lately. =/