#wiki prototype docs - why do you still use them?
1 messages · Page 1 of 1 (latest)
One thing I liked on the wiki was related concepts being on one page, for certain things. [An] example I ran into earlier tonight, energy sources
Force of habit
I see, that unfortunately is unlikely to change. Does it not help that the inherited properties are on the page of the child? I find that it helps a lot for example with style specifications or triggers, which were already separate pages on the wiki
Hmm.
I can think of things on site layout that may be easier to talk about
One, above the search box, if Prototypes / Runtime were right there
It might not be something normally noticed, but not having it right there, where it feels like it matters the most, is a big oversight
When the docs were moved to the api page, I usually would pull up a specific page like I used to - LuaEntity, LuaSurface, LuaBootstrap, etc, but I honestly didn't find an obvious way to just make prototypes happen
for an indication where you are or to switch stage?
(or both, but primary reason is..?)
To switch, and to make it obvious if I search for something, I won't find other results
The first time someone searches they might look for, let's say, inserter
And it just won't have the inserter prototype unless they knew to be on the main prototype pages
The prototype side, so to speak
I see where you're coming from. It'd be a larger change, but it might be possible from a technical standpoint to let you search the other stage from the side, with a switch. Like say, you type inserter on the runtime sidebar, find nothing and it offers "search prototype docs instead"
From a design standpoint, it would be most obvious if they looked like in-game tabs, one saying Runtime, the other saying Prototype... I know the API isn't designed from the game's elements, but I think you understand what I mean
From the user-side, I think navigating between Prototypes and Runtime would be much much easier to use if the search was "separate-able" from what you're on, in that sense
So if someone looks up LuaEntity, and asks about a prototype, someone can say look for X in prototypes, and the search can just do that - without needing to "switch sides" of the API
I'm still hesitant to connect the two stages too much, but connecting the search partially (like you propose) sounds intuitive to me. Because you'd still need to manually switch so the separation should hopefully stay clear
The actual pages going back and forth is acceptable to me, as that makes complete sense. You leave a Runtime page and are now on a Prototype page
The search being "bound" to which side you're on without an easy way to go back and forth... not very intuitive
I don't find myself going back and forth much, so it hasn't been in my radar. So it's good to hear this from other, after all the page is for all modders, not just my usecases
Moving on from that topic, if we may
One possible thing to "clean" the layout a bit, might be a way to minimize the "short descriptions" that are in the main Members / Properties tables
To keep things simple, say a global or per-side user option... I'm outdated and think of just a cookie setting
Compare the density and brevity of:
Prototype/Inserter — inserter
energy_source :: EnergySource
extension_speed :: double
hand_base_picture :: Sprite
hand_base_shadow :: Sprite
hand_closed_picture :: Sprite
hand_closed_shadow :: Sprite
hand_open_picture :: Sprite
hand_open_shadow :: Sprite
insert_position :: vector
pickup_position :: vector
platform_picture :: Sprite4Way
rotation_speed :: double
allow_burner_leech :: bool (optional)
allow_custom_vectors :: bool (optional)
chases_belt_items :: bool (optional)
...
vs
extension_speed :: double
rotation_speed :: double
insert_position :: Vector
pickup_position :: Vector
platform_picture :: Sprite4Way
hand_base_picture :: Sprite
hand_open_picture :: Sprite
hand_closed_picture :: Sprite
energy_source :: EnergySource
Defines how this inserter gets energy.
energy_per_movement optional :: Energy
energy_per_rotation optional :: Energy
stack optional :: bool
Whether this inserter is considered a stack inserter.
allow_custom_vectors optional :: bool
Whether pickup and insert position can be set run-time.
allow_burner_leech optional :: bool
Whether this burner inserter can fuel itself from the fuel inventory of the entity it is picking up items from.
draw_held_item optional :: bool
Whether the item that the inserter is holding should be drawn.
use_easter_egg optional :: bool
I understand the intent of having short descriptions, but it interrupts the idea that this is a list of things one can examine closely
haha, that matches my thought of "what if we removed the short descriptions from the TOC to force people to read the whole description. nah, that sounds like a bad idea" I had yesterday
Honestly, I think that's a better way to handle it
It reduces where the information is, so it's easier to manage and easier for the user to find what and to know where it would be
As I understand simple HTML, the text can be made hidden but still come up with ctrl-f searches. I don't know how it interacts with expanding nodes or however it is called
A reduced layout is a small step, moving information is the bigger one
now, fun question. If you expand the layout to fill the whole page (button top right) and the descriptions end up on the side, how much does that improve the readability of the list for you?
.......how did you know I did not know about the expand layout 
just a guess 
That or I tried it before and it got reset somewhere
Well. Hm. That's a thing isn't it
It doesn't interrupt the vertical flow
I like it but then I want the sidebar so I open the sidebar and it squishes the TOC again and I just end up going 
yeah. on 1080p the wide layout + sidebar open still ends up with the descriptions in the extra row
.. or not?
A more intense option which might be "nice"... remove the repeated parts of classes etc from the search
Do I really need to see every prototype is a prototype
Still, it could go a bit to improving the use of space
Some way to squash them... I need to mention something before I forget it
I dont know, it doesnt make the sidebar wider to have the word there
One comparison to the wiki, the inheritance tree is a little harder to follow
The wiki goes from ancestor -> descendant. There is, also, that Prototype is at the end of the word instead of the front, which feels like it interrupts the flow of the text
I think "Inherits From" could be completely removed, and if the order were reversed, it'd be... more readable. And usable. It almost feels like I don't want to use anything there because it is difficult to read (?)
you mean the list at the top of the page? Inherits from EntityWithOwnerPrototype « EntityWithHealthPrototype « EntityPrototype « PrototypeBase
Inherits from EntityWithOwnerPrototype « EntityWithHealthPrototype « EntityPrototype « PrototypeBase
PrototypeBase » Prototype/Entity » Prototype/EntityWithHealth » Prototype/EntityWithOwner » Prototype/Inserter
Both convey the same information, but it feels like the second presentation is just much easier to read and follow
Even just reversing the order and removing "Inherits from"
PrototypeBase >> EntityPrototype >> EntityWithHealthPrototype >> EntityWithOwnerPrototype
In a sense, from left-to-right follows where one starts, to where one ends up
to where one proceeds 
the ordering was something we weren't sure on. Now in hindsight I'd say that the direct parent is first because it's likely the most relevant (you don't really care about PrototypeBase). But I also liked the wiki order ... 🤷♂️
I think fundamentally, starting with the most abstract and general is the regular presentation of things
we ended up going with the current order because we wanted the intro sentence and it wants that order. Without the intro I think it's quite free floating to just have it in the page randomly (since it's not at the top like on the wiki). But you don't want the intro 🤔
I'd consider an intro acceptable. :thonk: I'm not sure what would go in it. Things relevant to modders, particular behavior of that entity?
I like the introduction to Prototype/Inserter
An inserter.
💯
Oh oh, sorry.
Yeah. I don't think it needs to be there.
I think having the Ancestor in front just repeats that
If someone was like "what is this" they click it - and can see all these things are from that
The meaning is itself
fun times to look at how other api docs do it. Same class, 3 different websites:
I've often felt game developers were in a special position, compared to a lot of other roles that always have trouble finding good solutions.
...such as conveying information in a way that's efficient and sensible
The first image is the example of the API's inheritance at the moment. It's ironic the individual elements are still left-to-right
The class::thing, and folder layout lol
as in game devs have trouble finding good solutions or other roles have trouble finding good solutions?
Other roles.
It is a tangent, but "how do we keep people engaged" has been a looooooong discussion in other topics, meanwhile, keeping someone engaged is like, goal #1 of making a game
And they never just... asked how game makers do it
One thing, stylistically speaking. The indentation for the API is slightly amiss. It's hard to suggest anything, but the Title of a table and the contents seem reasonable - but for the prototypes, there is a section separator like Inherited from EntityPrototype
It might feel redundant, but having one line under Properties, with the class repeated, might create a visual expectation that is consistent with the other "Inherited from" lines
A small visual indicator: below Properties and above FooPrototype, would uhhh "prime" someone for the layout of what's to follow: a thingPrototype and then the properties from it
It's a change to the visual structure a bit, but starting at the top, and then scrolling down and then the layout changing slightly in an unexpected way with the "Inherited from" space feels ever so slightly wrong
It might be me, but it feels like, "ok we went from Properties, indent 1, to the properties, indent 2, but... where do I put this third thing?"
I think I might need a screenshot indicating what areas you mean, I'm getting lost in your description 😅
the indentation is off (haha), but do you mean a line like this? And where/how would you indent?
If there were a top text, I would have it aligned with the other "Inherited from" statements
right. and you say that the current indentation of the "inherited from" statements is off somehow?
It's subtle, but the wiki makes it clear with the large indentation
I don't think the spacing of the indentation needs to be changed, in this regard. Focusing, the bit at the top somehow became significant in its absence
A way to describe it might be why the indentation exists, changed
Going from Properties to properties, but then things change with inheritance in the middle somewhere an interruption but why
I get what you're getting at. Now Properties is the table title and the "Inherited from" are just kind of... there. Previously they were the same kind of thing with the same formatting so it was less disorienting to have the "Inherited from" in the middle
Now the "InserterPrototype - inserter" is at the top of the page, so I'm having trouble with coming up with a simple way to do something similar to the old formatting that still makes sense when read
I am confirming that I believe you have my view of it, accurate
To be fair, the wiki page does repeat the information three times
The new page also says "Properties" twice :D
The page title, it's in the descendancy tree, and it's at the top of the properties table
Maybe 4 times if you want to count Prototype/Inserter — "inserter" as 2, though that does present that the way the documentation refers to the prototype and the way the game does is different - if you know to read it that way 
Ironically, the wiki page doesn't use "Properties" until it starts describing things
'this is stuff' and you scroll down to see "properties" "oh, I see"
It worked well enough, not having "Properties" at the top 🤔
A lot of things are also convention. Like, the rails docs (what I showed above) do something like this quite often
entity.name -- => "inserter"
``` and they don't explain on the page that the comment shows the return value. But I read and understand. Monday I wanted to use this format in our lua api docs and suddenly I was wondering if I need to explain it.
And those conventions are hard to pick out for us people who have used the docs for years, because we're so used to them 😒
It's an understandable concern.
A small mention: somewhere in the docs, the landing page, the first Prototype API Docs page, somewhere.
"The point of prototypes is to define parameters for predefined behaviour."
You could even contribute it to yourself. It would be a good "first thing" to understand about prototypes / the data stage.
what adds to this is that this is just the format of the irb. Similar to how you execute python on the command line. We don't do that with Factorio Lua, we always use the in-game console where you need to print to see the return value.
very good point. I keep forgetting what exactly I said, but it was so good. so thanks for the reminder and the wording
Oh, I see what you mean, I think
It's like if you did an immediate type() (in that way), it would show what it is 'as if you typed it at the console at a breakpoint right there'
Or the actual value
That is a little obscure lol
yeah. Ruby has the fun feature that almost everything has a return value - so the return value of foo = "ooo" is in fact "ooo" and the console just prints the return value
I can see Factorio's Lua requiring more deliberation, because there just isn't an interactive console
To that extent.
yup. And when we use the console in examples you're often using game.player and then that doesnt work in actual code and 
Well, that could be made clearer, but writing commands has a pretty sharp distinction, after learning the minimum about player_index and game.players. Which is, conveniently, about the maximum to know, too
The only way it could be made more obvious, maybe code-wise, is having a me object or game.me, but that could be random mod-making chat
I think uhhh it's been a long talk about API / wiki stuff
I want to space out
thank you for the feedback 👋
note from @sharp condor 's stream:
prototype inheritance breadcrumbs (prototypebase etc) is kinda in there with everything, maybe separate it more visually. "very compact" while pointing at that and toc and saying breadcrumbs were better in wiki

quite similar to this
Hey! So, I've been thinking about it a bit
First, I'll say that with use, I've been getting more used to the new doc layout
That said, there's a few things I'd observe about the new API that I think warrant consideration
First, I think I get what I didn't like about the breadcrumbs -- they go opposite of my expected reading order
The wiki has it in the way I'd expect -- that is, the same way I read directories in a file explorer (in Windows; can't speak for other OS users)
It goes backwards in the API docs, and while people can adapt, that's a thing
Second, I think I can pin down why I find the wiki layout to be 'cleaner'
The separation between areas isn't done with hard borders, but rather, just layout choices
When I takea snippet like this, it's pretty easy to tell that the inset light-grey area beneath is being titled by Inherited from PrototypeBase, but it's a thing my eyes miss as I scan
another thing is that the ::'s don't line up across chunks:
For the longest time, I thought they were like, totally different categories of thing
Contrasting that with the wiki:
My eye follows this flawlessly. That said, I'm accustomed to tab-indentation segmenting things like this, so I am not gonna claim my experience is universal
It geels easier to read
Once we get down to here, there's only a few small things that trip me up
The boldface word Default is grabbing my attention harder than the property itself
In the wiki, the properties had a larger font size, and it was a LOT easier for my brain to just scan-and-find
Yes, often I navigate there by clicking on the property in the list above -- but just as often, I don't, because I've already navigated my browser there and I'm just scrolling-and-finding
Then ... there's this
The idea behind it is sound
But there's another few snags here to consider
- I prefer hierarchical ordering (like from the wiki) better than alphabetical ordering.
This is another spot of personal preference -- but I also feel like there are a lot of objective benefits to the hierarchical ordering
It helps people really piece together the inheritance structure of prototypes. Like, this right here:
That Furnace and AssemblingMachine are just child 'classes' of CraftingMachine leaps off the page at me
to the point where I was able to incorporate that into my mod
It doesn't here ... and searching for it isn't any help either
And I'm not getting that from the breadcrumb trail either
- (seemingly) random stuff is blended in here. As a list of all the prototypes, sure, they belong, because ... it's a list of them
table.panel-hole.docs-table {
table-layout: fixed;
}
td.td-modif:nth-child(1) {
width: 60%;
}
td.td-modif:nth-child(2) {
width: 40%;
}
But like, I feel like if I'm building prototypes, I'm probably going to try to access stuff like MouseCursor only when I'm led there via a prototype I'm working with.
That doesn't mean it shouldn't be searchable, but ... perhaps there's a way to organize that into something different?
What's that? 🙂
But don't get rid of it entirely -- I actually think it's great to expose ALL data structures like that in a searchable fashion somehow.
Some CSS style implementation details that makes :: position constant 60%, for Bilka
Just in case
- Dovetailing off of that, the properties tend to blow up the search list too, and it wasn't quite obvious to me at first what was happening. For example, this.
This may become a tree but that's hard to digest for how to structure it
I would say 99% of the time, me personally, I'm trying to get to ItemPrototype. Or something that starts with the word 'item.'
So, my suggestion here is twofold
a) Make the properties that are coming up in the list either a slightly smaller font, or perhaps a slightly darker shade of burnt orange (though this gets into accessibility problems).
b) Force-percolate to the top of the list 'classes' that start with Item, and have everything beneath be whatever they are
Structuring the tree is perhaps not so bad
Actually, I think structuring it like a tree would be super useful
okie, gonna stream for a bit
come yell at me whenever lol
I suggest to click that "Inheritance Tree" link at the top of the sidebar
Huh. I did not know that was a thing. I looked right past it
it's new-ish, so it might not have existed yet when you were first exploring the page
I already noted "Show exact match on top" based on your AmmoItemPrototype + ItemPrototype comment. I'm not happy with the search yet and this gives us more options to look into, thank you
also thank you for the detailed/direct style feedback. It can be rather hard to pick out what exactly is wrong when something feels off, so this is very valuable
Very welcome, glad I can help. 🙂
-- Cases:
-- * Items can have some, or all of: 'icon', 'icons' or 'pictures'. Recipes can have 'icon', 'icons' or none of those
-- * Pull icon data from products if we're badging a recipe with no `icon` or `icons` data. It will be one of three things:
-- * 'result'
-- * 'results' with 1 entry
-- * a 'main_product'
-- * If there's no 'icons', there's a 'icon' data; make an 'icons' entry from the 'icon' data
-- * Only make 'pictures' out of 'icons' data if needed for belts
-- * Pictures can be one of four structures:
-- * A spritesheet
-- * A struct with a sheet = spritesheet property
-- * A single layers = array entry
-- * An array of things that have layers = array
-- If "Only GUI" is picked, then all items and recipes gets an 'icons' with badges and items without 'pictures' have one made from 'icons' without badges
-- If "Only Belts" is picked, icons and recipes aren't touched but every item gets 'pictures' with badges added
<3
-- Make and badge an item with a sprite-sheet for testing purposes
local item = {
type = "item",
name = "globulent",
stack_size = 1000,
icon = "__icon-badges__/graphics/globulent.png",
icon_size = 64,
pictures = {
sheet = {
filename = "__icon-badges__/graphics/globulent.png",
height = 64,
width = 64,
variation_count = 4,
scale = 0.25
}
}
}
data:extend({item})
data.raw.item["globulent"].ib_badge = "Hi"
and now back to regularly scheduled doc website feedback :D
I'm still missing the capability to collapse that "tree" like you can on the wiki :/
also maybe having the tree directly on the main prototype page like it is in the wiki would make it more visible
rather than being kind of hidden behind 1 small link
actually I just noticed, the main wiki does link to that page aswell
problem with moving it the the main page is that it pushes down the search on mobile, since that's below the main content there
hmm that is a problem I guess..
could it be made as a side bar thing that you can open/close instead?
we've considered adding an extra search at the top somewhere so we dont need to do the workaround with the sidebar on mobile.
galdoc noted that it might be neat to have the tree in the sidebar at the start and only change to the list when you start searching. not sure if I like that/how viable it is.
hm, this somewhat reads like I'm just saying no. To be clear: Putting it on the main page was also an idea we had. it's not done currently for the given reason and because I think it's not the best entry to the prototype docs (but neither is the current state of the main page, it's missing a mention of the available global classes like runtime stage has it)
this should default to on
@hollow loom this would be a good place to share your thoughts
humans tend to have an easier time reading something if the column isnt super wide. that's why it's off. and that's also why, when it's on, the index page text still doesnt take the full width
I have a harder time reading the table when the rows are interlaced
I keep wikipedia on skinny mode because it's easier to read a paragraph
when the descriptions are between properties and methods, it makes it harder to see anything at a glance
I have introduced two people to modding recently, both of which I have told to click that button and immediately went "oh that's so much better"
small sample size, but the point stands
an option I can see is to get rid of the button (or change the default state) to make the tables wide, but keep the free floating text wrapping earlier
perhaps
you'd end up with something like this
that's not bad actually
another thing I think that may have been mentioned before is that some of the pages are wiki exclusive, which I'm fine with for tutorials, but the settings stage just doesn't have any normal documentation
yeah settings stage doc is kind of hidden in a wiki tutorial and the only thing of the 3 stages that is like that
I know that was a WIP thing after getting the main prototype docs finished
yeah it's been noted before, I agree with your points. It's indeed WIP
I also remember having a discussion a while ago about how to make which stage you're on more obvious (which I think one of the suggestions was changing the link colors) but I think having runtime/prototype visible at all times instead of only being at the top would help with that, and that also makes it so you can switch between them much easier if you realize you're on the wrong one
instead of having to scroll up to the top, especially on longer pages like LuaEntity
last small thing, I couldn't find where data:extend is documented, if at all
that's an important thing for new modders
yep, noted that just today. Plan right now is to have a list of available global classes (mods, data, settings) on the index page, like the runtime docs do
time to make it a sticky bar at the top, though people tend to hate those 🤔
that also scrolls down though
isn't data:extend provided by the games util.lua or am I misremembering something?
it's in data-loader in core
data_loader? dataloader? whatever it is
not exactly somewhere people go looking lol
yeah, but it's not a bar over the whole width of the page at least
if it were to not scroll, that is?
yes
@topaz hill do you have pc vs mobile usage stats?
the docs site doesnt have analytics, so no
I have stats for the wiki, but that's mostly gameplay parts, not the prototype docs
And what is stats?
Honestly I would expect 95+% of api hits be from pc
see this
I'm honestly not sure how best to phrase this.
A lot of the documentation is rather.... dry. There's a lack of cross-linking keywords. So you get a really technical mumbo-jumbo statement about what some function does, and have to go somewhere else to search for all of the words rather than center clicking on stuff and opening a few tabs.
It's really difficult to parse what sublevel you're operating at because of how the pages are formatted as well. The inheritance of various functions/properties is.. idk... not obfuscated, but it's really unintuitive because you have huge list with definitions, the spacing isn't consistent and the section headings are tiny fragments of the overall page length. Hovering elements or some kind of "you are in this subsection" on the side would be useful.
Stuff like java documentation has lists of functions and each function has it's own page. That makes browsing for a bunch of "this sounds like it's probably pretty close to what I want" things easy. Skim through them, center click a few pages, make your selection. With the current system it's really hard to skim, and the search is kind of useless because someone new to the system doesn't know which keywords to search for, and 90% of the time you get flooded with dozens of possibilities for entirely unrelated things.
Just having a "tree" style layout of various properties and their subproperties would be useful. If that already exists, I haven't found it.
There's a lack of cross-linking keywords So you get a really technical mumbo-jumbo statement about what some function does, and have to go somewhere else to search for all of the words rather than center clicking on stuff and opening a few tabs.
For this it would help a lot to have concrete examples/issues we can tackle, so it'd be nice if you could link what you can think of right now/what you stumble across as you use the docs. https://forums.factorio.com/viewforum.php?f=233 is made for issues like this.
For your second paragraph it's not clear to me what you're referring to. There are only two sections per page (properties, overridden properties), which is less than the wiki (mandatory properties, optional properties, ignored properties, mandatory values, differing defaults) so I'm guessing those are not the sections you mean. Could you elaborate, maybe provide screenshots pointing out the inconsistent spacing?
Place to report issues and suggest improvements to the API documentation.
I see the equivalent to "a bunch of functions" for the prototype stage API as picking between the different prototypes to find the one for you need, which is why we list them on https://lua-api.factorio.com/latest/prototypes.html with short descriptions of what each of them is good at. Similarly, we list the uses of types like RenderLayer so that you can easily find a prototype with a controllable render layer (a common usecase).
However, I agree that the search isn't ideal, especially because the properties are sometimes not well named. My "weapon" against it so far is to use my browser search on the prototype overview page since it has the short descriptions which provide some more (better) keywords. Or when I'm searching for something for a specific prototype, I ctrl + f that prototype page, since it will find things that aren't mentioned in the short descriptions at the top. Do you have suggestions for how to improve the search? E.g. would an optional full text (that is, property names and descriptions) search help you at all?
Just having a "tree" style layout of various properties and their subproperties would be useful. If that already exists, I haven't found it.
We try to make examples to give a quick overview, e.g. https://lua-api.factorio.com/latest/types/Animation.html. But as you can see that's already abbreviated because it would get big if you do for example a full layers + hr_version definition. So I think a whole tree for a whole prototype would get quite huge and not useful due to information overload. E.g. CraftingMachine uses 2 Animation4Way, so it would have 8 animation definitions each with their like 30 properties in its tree. And that just for two properties of the prototype...
Question: As I use the docs, could I throw examples your way that may help others who use them later? I'm thinking in particular of Pictures and Icons
yep! preferably on the forums (subforum linked above). dont worry about too much formatting, just like title it "proposed example for Thing" and plop the code into the post
it's linked at the bottom of the doc page, behind the feedback link
Cool, thx 🙂
because it was a topic here: I added examples for Sprite (simple, layers, hr version, layers with hr version), SpriteVariations (array, sheet property) and AnimationVariations (array, sheet property) for the next version
also added a note on ItemPrototype::pictures about the scale for the 64 size
Unfortunately such a simple solution doesnt work due to how the table adjusts depending on screen size (moving the description around)
I also recall that we had issues with overly long property names or types, for property names UtilitySprites has the worst I think and for type + property name combination the filtered prototypes on LuaGameScript are pretty bad
EntityWithPersonalityButNotEnnuiOrUnbridledOptimism
max_successful_attempts_per_tick_per_construction_queue_modifier_constant 
wait is that for real
now documented, will be released with 1.1.102
(this too)
so settings will be in the lua docs now?
no, that's about the data stage access to the settings values, not the settings stage prototype creation
ah
settings stage prototype creation docs are here: https://wiki.factorio.com/Tutorial:Mod_settings
yeah I know that they are in the wiki at the moment
they will be moved to the doc site at some point in the future™️ but it is not high priority
your doc diffing thingy will have a lot of work with https://forums.factorio.com/viewtopic.php?f=234&t=110403 btw, it's a lot of changed lines
There are a number of places where things like function parameters and concept fields have a type of string, but can only be strings from a defined list. Wou…
I feared as much yeah
ah wait not that's runtime nevermind, you dont care about that
but its not that usable anyways, would need a proper web ui or something to display changes in a more structured format
I did some searching in the prototype docs but I couldn't find anything
that seems to be good from the start
yeah we converted those when we did the migration from the wiki. sounds like we didnt miss anything then :D
almost forgot - also done for 1.1.102
more updates on done things for 1.1.102:
wide mode is the new default. it has restricted paragraph width so the text wont stretch your whole widescreen monitor
better formatting for the properties (default no longer stands out as much, property name stands our more)
thanks for the feedback here, the larger items are also on our todo list for when we have time for them
I still go to the old docs to find community edits for confusing parts of the API. Like I made some edits for turrets and attack parameters and they saved my butt months later. I don't know how to add those now
To be clear, the community contributions from the wiki were also migrated to the website. But new contributions are done via the forums.
It's hard to tell what track which doc suggestions actually happened in the forum. It might be a little easier if it used a bug/ticket system to clearly see "this suggestion was fixed/refused/whatever".
I remember seeing forum threads being crossed off but it's not like I got a message or something later to say my suggestion happened/was refused. Not getting a confirmation later made me not as interested in filling another one later, whether or not the suggestion was actually adopted.
But you guys seriously rock. You're more responsive than my coworkers and the docs are better than everything at my job.
isn't there a resolved requests subforum?