Could we get some examples refferences in the manual?

No no, I think you misunderstand me, the description is fine. I understand what it does and what it is for; But having a code example of it in use goes miles to help avoid making dumb mistakes and show it in propper context. and JS never tells you until you get the thing exported, plugged in, and it doesnʻt work. An example with the description makes it easy to see how it is implemented. I only brought up that particular item to show, like most entries, there is no example code.

Iʻm not saying "why donʻt you make this like unity". That feels a little like a straw-man. Pretty much any api documentation I have ever seen includes at least a single code snippet of the item in use, which is fair. Iʻm using unity as an example because it perfectly illustrates "...what more there is to add." (namely code examples with comments). But if that still feels unfair, these other examples will do just fine and are made by solo devs.

Here is documentation for a tool made by one person: ludiq.io/chronos/api/timekeeper.

Documentation for another package made, originally by one person.

corgi-engine-docs.moremountains.com/API/class_more_mountains_1_1_corgi_engine_1_1_a_i_action_jump.html

Constructʻs api isnʻt insanely huge, so comparing the effort needed to maintain or build documentation in contrast to unity isnʻt fair either.

On a favorable point, constructʻs documentation is well written, much better than gamemaker. And honestly, when it comes to the eventsheets, it is pretty much perfect, plenty of examples too. It just is missing examples for the api.

Ashley

If it helps to know, construct is a great product. I was/am salty about the rent model, so I have most of my work still in c2, but Iʻve been doing more and more in c3 and the number of improvements is great. I know I complain alot.

But c3 is a great product and I do recommend it to people. and I am rather astounded by how insanely productive you are. It takes me forever to get something out the door and I never have to make my tools stupid proof for the masses (Iʻm included in the masses too lol).

Iʻm not being sycophantic - just trying to add context to all my complaining and poo pooing.

I also have gotten stuck a little here and there and I think a one-line codeexample would have answered all the questions I had.

For example:

Create probability table from JSON

Create a new probability table from a JSON string. The input should be an array of (weight: number, value: number|string) tuples.

Google "What's a touple?" and only find a bunch of references to python scripting. Uhh... I ended up adding entries with events and then using "ProbabilityTableAsJSON" to export the json so I could figure out what it wants from me.

All I needed was a single example like:

	"[[100,'foo'],[50,'bar'],...]"

There isn't always a simple example snippet to show. A realistic example of static conditions might involve hundreds of lines of code for a niche use-case that most people don't even need. It's kind of a complicated escape-hatch for when the usual picking algorithms aren't appropriate. My point is Unity can throw dozens of staff at such things, but it's difficult for us to justify. The other alternative for us is just to not document stuff like that and leave it as unsupported engine internals. Then at least people won't wonder what it means or how to use it, but I'm not sure that's preferable.

If I download the full Construct manual it currently comes in at around 900 pages. It's a huge body of work, and "just sprinkle some examples all the way through" is probably a major project that would take weeks.

Being a smaller company I think we have to rely on our community more than huge companies that can just throw loads of staff at something. For example there's no way we can possibly do our own Construct integration for all the third-party services out there - it's year's worth of work. So we have an addon SDK so third-party developers can potentially do it themselves without having to wait for us to get round to it. I think it's a similar situation with documentation - if you want tutorials for specific kinds of games, useful code snippets for specific features, demonstrations of useful approaches and algorithms, then we have a public tutorials system for that too, so the community can share their knowledge rather than relying on our already-stretched team to provide everything. To be clear, that's not an excuse for us to have inadequate documentation - I think we do a good job with the resources we have available - but when it comes to samples, guides, tutorials etc. there's just an endless array of things to be covered, it all takes a great deal of work to do well, and the fact is we're a small team.

If it comes to it, I would much much much rather "supported engine internals", even if that means documentation isnʻt extensive or robust.

Lol, A bigger issue I have is that there isnʻt enough internals listed :D

So I def prefer a larger listed api over a smaller, but very well documented api.

I mean... I do make api calls that arenʻt officially supported, because I donʻt feel like I have a choice. I need them, and figure since I am using them the same as some built in behaviors use them... should be okay... hopefully.

I should also add that I'm not looking for a full on "found in the wild" example either.

Literally just one line, as WackyToaster mentioned.

So in this example, the code would literally just be the ace declaration with the parameter in use that makes it static.

The only code snippet is for the most basic declaration:

{
	"id": "every-tick",
	"scriptName": "EveryTick"
}

{
	"id": "every-tick",
	"scriptName": "EveryTick"
	"isStatic": "True"
}