I don't rly get it. But what you mean is: if space is less then max space -> add item, only if weight is also less then max weight.

Add item instance vars(weight 10, space 3)

If item weight+current weight <= max weight AND current space + item space <= max weight

Pickup item to bag, else don't

reedit: current space + item space <= max weight /// should be less or equal to max Space

Yes that blocks it from opening. Get used to it. Post it into github issue tracker or link C3 dev, which can look into it at forum.

Cases like this need own forum category.

The main potential issue for an unaware individual is that a collapsed group will not give any indication of this default selection mechanic when dragging groups, as the only thing you can see is the group header of a collapsed group.

Stuff like this never get added. Thous fall into 0/1 vote suggestion category, that C3 devs consider as user forced work onto them or user super cool idea and not as possible helpful case, which is there to help engine/editor workflow.

I think that is the wrong decision and the feature should not work like that, but it's probably too late to change now for backwards compatibility reasons.

This is one C3 flaws. Why not give users a way to make small changes and make it somehow work. Any other engine, js or some other library, developers would give correct code snippets or a possible solution, so others can change behaviors. But not in C3, why sooo ?

	ExpObject(...args) {
 const objectClass = this._objectClass;
 const instances = objectClass.GetCurrentSol().GetExpressionInstances();
 const len = instances.length;
 if (len === 0)
 return this._returnsString ? "" : 0;
 const index = WrapIndex(this._owner.GetSolIndex(), len);
 this._eventStack.GetCurrentStackFrame().SetExpressionObjectClass(objectClass);
 return this._func.apply(instances[index].GetSdkInstance(), args)
 }
 ExpObject_InstExpr(instIndex, ...args) {
 const objectClass = this._objectClass;
 const instances = objectClass.GetInstances();
 const len = instances.length;
 if (len === 0)
 return this._returnsString ? "" : 0;
 const index = WrapIndex(instIndex, len);
 this._eventStack.GetCurrentStackFrame().SetExpressionObjectClass(objectClass);
 return this._func.apply(instances[index].GetSdkInstance(), args)
 }

I have kinda wished for a while there was a way to edit the code of things like the platform behavior per project. Or if we could alter the plugins per project, I could just add collision tags to the jump-thru instead of having waited I think 3 years now.

Yes, this is only possible solution for current case, with official guidelines for it.

Not to mention waiting 3 years. Who in right mind will start to develop something, hoping maybe it gets added in 3 years, even 1 year would be to much in this case.

Baseline C3 plugin is just more complicated than a simple, baseline component for other engines, so it's a bit of an apples/oranges comparison. But the bottom line is there's a lot of friction with getting started writing C3 plugins. Having some built-in software to help manage complexity in C3

I always though their sdk manual is more for themselfs, place they can look up correct code.

Besides, lots of Construct users are not very experienced programmers.

Saying this is pretty much counterproductive to everything. In such case, you won't get it in 10 years or 20. As it goes, if idea is somewhat possible or it simplifies 3 step to 1 or helps a bit with performance, then in MOST cases such idea will never be developed. Only possibility is: you do it or someone else, but currently nobody can, past scirra.

This is the case that makes your 'array noSave' never to come existance. Why would new, passing though or not very experienced devs want it? Only way this benefits someone, if they make or do some sort of community and then force feed ideas to be voted. Overall it still benefits 1-2 guys.

This would also make C3 pretty much a 3-5 month toy. Problems that new users face are voted and developed, while users who been here longer, would never get their specific stuff, because nobody cares. Or when new users does very specific thing and sees engine flaw, noone else would vote for it.

Example: if some old C2 plugins would never been developed by modifing official code, thous plugins or features would not even be in C3. Currently users only demand them, because they saw that case was good. Because based on just idea, nobody or 'passing though devs' would never vote for.

reset of the suggestions platform every 6 months

Suggestion platform also consists 'almost bugged behaviors' ie flaws in C3 that are labeled as ideas. They are not gonna change. This just would remove or hides them.

Over the years, from forum to every other place, if user found or faced massive flaws/shortcoming, then user went to suggestion platform, as place to write them down. Thous flaws n shortcomings are still there. Most cases are even like 'I want to do X' -> Official statement 'do this' -> but 'do this' has massive problems -> post it on suggestion platform -> baam never get it.

In C3 development cycle, the 6 month is very short. A much better idea in such extreme case would be: if idea does not get X votes, it will be removed in 2 weeks. This would least make forum more active with specific topics, on a daily basis.

I think the only reasonable solution for this, is not to jump around the issue but to find a way and invest time to fix the source of this problem.

It does not matter how the issue or feature suggestion website changes, only outcome of it can be: few Y features would be implemented instead of X, if there is limited dev time.

Only solution which I can see:

Better guide, tutorial, manual for scripting or plugin making. Plugin and simple change automation for runtime and editor, which simplfies work enough, so users can do their own version of stuff. Case, which in overall should make scirra work easier too.

Sometime like:

*Plugin maker - with set of rules to avoid compatitibility problems. User should be able to modifie simple templates and add features to templates of official plugins. Allows users to do small changes to plugins to add some expression, condition or simple change.

I don't know if something like that is feasable, but case where user could possible wait 10 years or more for some change, it should be reasonable to give user better tools/guide/features to allow him to do it himself. Scirra should invest time to win time, I don't see any other possible solution. Maybe if they get team of 40 ppl in few years, but even then same tools/guides should help them too.

You should'nt rly bother with theme, ofc if you really want to do it.

It will be non-stop time sink, time you could use to develop something in C3, get better at it or get better at something else.

Past simple color change, you would need to:

*Make selection, hover, focus colors, backgrounds and borders. Also selection+focus and selection + hover. Then also consider if something behaind is already selected/hovered/focused and account for that

*Need to change all coding colors in multiple places for all types of files.

*Colors for new mesh, sprite and all other object types. Also when they are selected and modified etc.

*Custom coloring for all the main dialogs and all other small dialogs.

*Everything you do, you also have to make sure they look good, if you make them very big or small.

*And bunch more cases, if you like to change something past color.

You would also have to consider, if something is missing, then you have to get it from Default theme or add it.

My aim was to get better with CSS, while editing something big as C3 editor and change thing to how I like them to be. So I did'nt really care that it was huge time sink.

Anyway, good luck with it.