GSoC Status Report 8/13-8/19

A few days late with this status report, quite overwhelmed by starting my new semester of classes. Things have been going well enough but I was unable to wholly integrate the TPCL EE into the RDE. Rather than rush to complete an inferior product I decided to postpone completion of the project until after things got settled here. Ah well...off to class >.<

-Fro

GSoC Status Report: 8/6-6/15

This past week went pretty well. Things moved pretty quickly with the Expression Editor. Features added include:

• Indentation in Expressions
• A new GUI layout somewhat reflecting mithro's comments and input
• Added support for variable length expressions...that is...expressions that can have an arbitrary number of subexpressions [(+ arg1 arg2 ...), (cond ((test1) (when-true)) ((test2) (when-true))), etc]
• Literal expressions supported as well (numbers, strings, etc)
• Refactored the internal representation of Expressions
• Put in the BlockStore which maintains the TpclBlocks in a nice structure and will allow blocks to be referenced by an id number so that we can have some persistence and also establish an MVC pattern with things that have to display the tree.
• Also added a "Quick Insert..." menu that allows access to commonly used functions and symbols, I plan on making this editable by the user.

For this coming week (the last week of GSoC) I plan on making all of the current features of the TPCL EE work consistently and as bug free as possible and then integrate it into the RDE. Some convenience functionality may not make it in by the end of the program but I'll add it in slowly but surely on my own time.

-Fro

On The Generalization of Servers

At the end of last week nash asked me to give some thought as to how much of a ruleset the RDE could be used to develop. At the moment there's not that much that it can be used for, aside from things like components, properties, designs, resources, or planetary systems and the like. And entire ruleset cannot be constructed from within the RDE. That does not mean that there cannot be, only that at the present moment it is not possible. I have given some thought to the issue, however, and believe that it would be possible to design the majority of a ruleset in a server-independent form if a few things were to occur:

1) A basic set of Order types would be available for use by a ruleset from a server. That is, a ruleset could choose to make use of a stock set of common Orders such as move orders, fleet construction orders, colonization orders and the like. It would also be possible for the ruleset to not use the available orders, or to simply extend and override the base Order with its own.

2) Any new major features (such as resources and trading as seen in TimTrader) should be implemented in a server-agnostic format. Instead of writing the plumbing in Python, as is the case right now, the TPCL language should be extended and exploited. In much the same fashion as Components affect the value of a Property so too could TPCL (or rather, TPSL [Thousand Parsec Scripting Language]) code could be written that allows Producers to generate Resources on a planet and the Consumers to consume those same resources. With a bit of forethought, then, it would be a fairly simple process to put the majority of the processing and functionality of the feature in a server-neutral format which could be stored, edited and tested in the RDE.

Now, certainly not all Orders can apply to all rulesets. And different rulesets will have different variations on the same Order. And it would not be the most efficient thing to do to go about interpreting TPSL code for all of the interesting things that happen on the server. However I believe it should be a goal of the TP project to make the building of new rulesets accessible and easy.

Games like Neverwinter Nights have such a large and active fan and hobbiest base because of the fact that it is quick and easy to create objects or features and share them. More importantly it is extremely easy to use the work that other people have already done in your own efforts. The more Orders that the servers can provide for use by rulesets by default the quicker rulesets can get up and running. If the ruleset needs functionality that isn't already present then it can be put in manually, hopefully to the benefit of all the other rulesets as well.

The same applies to features. Making resources, for example, accessible and easily sharable would make it more likely for people to make an effort at starting a creation of their own.

Anyway, those are my two cents (or rather, two ideas). I'm sure there's plenty that I haven't considered, but it seems to me that there a bit of an opportunity being missed in some ways.

-Fro

TPCL Expression Editor Taking Shape

Well, as can be seen above the TPCL Expression Editor is taking shape. After taking a look at the R5RS specification I decided that going about trying to fit TPCL expressions into categories would be artificially limiting and error prone. The result is that I plan on displaying all available tpcl blocks, both built-in and custom templates, in a tree control. These will be inserted by clicking on an expansion point and choosing the "Insert" option. I will also likely add a small menu within the insert menu that will expand into a subset of the available built-in expressions so that booleans, literals, arithmetic functions and other similar simple expressions can be quickly and easily accessed (thanks, mithro, for that idea)

Anyway...things are progressing well. Expressions created with the editor are now formatted nicely with newlines and indentation so that the output is still human readable. Anyway. More work tomorrow.

-Fro

GSoC Status Report: 7/30-8/5

Meh, quick status report. At this point it's still probing around in the dark a lot so there's not a concise checklist that I can mark off on.

I got a basic build of the expression editor working last week which made me happy. I've also got some thoughts put together for nash about how the servers can be massaged to make them more amenable to rulesets being written in a form that is general enough to be applied to both with minimal effort. A post with my thoughts in that respect will be coming later today.

Anyway, back to coding. Working in a new view for the TPCL Blocks and making the code nicely indented. Screenies later.

-Fro

A few more thoughts on the TPCL EE

What I've got in place works just fine for predefined expressions. However there are going to be issues with expressions that take a variable number of arguments (i.e. (- 1 2 3 4 5...)). That and allowing the user to put in numbers and string literals. But that's an issue that will be dealt with as I develop the editor itself. Now that I have something concrete backing up what I'm doing I'll be able to better find solutions to these issues.

Functional TPCL Editor

So. I got the GUI working. All of the stuff in the screenshot was put in with mouseclicks. The progression was:

(lambda (design) *EXPR*)
-> (lambda (design) (if *BOOL* *EXPR* *EXPR*))
--> (lambda (design) (if (= *VAL* *VAL*) *EXPR* *EXPR*))
---> -> (lambda (design) (if (= *VAL* *VAL*) #t *EXPR*))

And I got the TpclExpression class to the point where it actually functions pretty well. Expressions can be inserted and removed from other expressions which is basically what I've been aiming for. This will remove the human error of hand coding and make a large database of premade code snippets available (at least, that's the hope).

So now that I know the system works I just need to make sure that it's basically what mithro, nash and llnz wanted out of this and then I can start moving forward with introducing nice formatting to the expressions and expanding on the database of TPCL code.

I had originally planned to attempt to limit the types of expressions that could be nested inside of others. But that's just silly. It will introduce more problems than it's worth, I think. At most pointers can be added that help a ruleset designer make smart choices.

-Fro