search

KSP-KOS / KOS

Fully programmable autopilot mod for KSP. Originally By Nivekk
Other
691 stars 229 forks source link

Vessel needs parts badly #634

Open erendrake opened 9 years ago

erendrake commented 9 years ago

This is a discussion about reconciling the vessel object against the LIST IN and LIST FROM IN syntax. currently the list syntax can get many different types of part lists.

The following is my first stab at how we could accomplish this, i am totally open to suggestions.

SHIP:PARTS gets replaced with a structure that can build all of the different part types from the LIST IN syntax and has an :ALL suffix that returns the full part list.

That same structure is instantiated by the LIST IN function and that function uses the structure's suffix system to fetch all of the part lists, only changing :ALL to PARTS for the purposes of maintaining the LIST IN part types as they are.

This way whenever we add a new part list type. it will be available in both places for free.

Again i am up for suggestions.

Dunbaratu commented 9 years ago

This would be a good place to be able to do a generic query condition:

SHIP:PARTS:WHERE( conditional ).

But we don't really have that language feature in kerboscript.

However, behind the scenes in C# that's really all we need as the workhorse underneath all the other techniques. Keep SHIP:PARTS just like it is - it return a useful list of parts that is a ListValue and works as one in the kerboscript.

But make it be a PartList - a new derived class of ListValue, which in addition to all the other stuff a listvalue does, can also have an :ALL suffix (which just returns the object itself again), a :DOCKINGPORTS suffix, and :ENGINES suffix, and so on.

That way nobody's scripts need to change. SHIP:PARTS is still a list of all the parts and still works that way, It's just that now you also can get subsets of that list for just the parts of it that are engines or are ports etc.

One potential wasted execution expense might be that SHIP:PARTS:ENGINES would wrap ALL the Parts on the vessel in PartValue instances, and then immediately cull that list down again into just the engines (or just the dockingports, etc), when if you did it the other way around ( cull out the unneeded parts, then wrap what remains in PartValue wrappers) it would get rid of the need to construct hundreds of PartValues just to keep, say, 6 of them.

A possible workaround for this (if it's really a problem - this might be unnecessary premature optimization) would be to make the PartList class "fake it" a bit, in that its list might LOOK like a LIST() of PartValues according to all its public methods, but in fact behind the scenes it might just be a list of KSP Part references that only get wrapped in PartValues when you try to access one of them with a '[]' operator or an iterator.

Dunbaratu commented 9 years ago

To make it clear why I don't like it when functionality exists only as LIST FOO FROM BAR IN BAZ and not as a suffix call is because of all the talk of people trying to make other language bindings besides kerboscript. If you take whatever your language's syntax is for "call method foo of object bar with parameters baz", and compile that into OpcodeGetMember and OpcodeSetMember operations, then you've just implemented support for ALL of kOS's suffix calls "for free" without any additional work beyond that.

The more things that have to be done as special case exceptions because they only live inside kerboscript's language parser and not in the "library API", the more work it is to support a second language in kOS.

That's my main motivation for adopting an attitude of treating the 'suffix way' as the "primary" implementation of a feature and any alternate syntactic sugar means of doing so as the "secondary" way.