Bay 12 Games Forum

How about this?
#v^#
^__v
v__^
#^v#

^#v^
v__#
#__v
^v#^

v^#v
#__^
^__#
v#^v


I sort of did the same thing in my latest fort, except not through cheating. Should be easy to just pierce all caves to reveal a large area and see if there is a big enough place for the piston. If not try pierce elsewhere and so on, although I found a 11x10 area at the first shot.

Ok, finally updated. I haven't had any chance to test the latest changes on windows though, but it should still work. If it doesn't, I'd be happy to know about it.

You can simply clean out the cavern section of the piston so its flat and then drop the top section on the bottom one. I guess what Fenwah means is that its already only being supported at the top, but the bottom section would otherwise fall when you flatten the cavern section.

   There has been a delay in the release of the next version for a couple of reason. One being that there are several major features that I'm slowly trying to implement, and the second being that doing this, I had to restructure the program in major ways resulting in a whole bunch of bugs that took me ages to track down. At the moment they have quieted down so I hope I can release something somewhat stable. Since most of the work went into preparations for the major features, which will probably take a lot more time, the upcoming release will not have any of the major features in a usable state. However there are still a bunch of goodies in it and some bug fixes.

Here's a full list of features I'm planning for upcoming releases:

Note:
 - green means this feature has already been implemented and will be in the upcoming version 0.13
 - yellow means this feature is partially implemented.
 - cyan means this feature is just planned.


Major features:

1. multithreading and timer support

Most of the time has gone to restructure the program in preparation for this feature which allows the instantiation of threads which all have their own private stacks, but can communicate using the global variable namespace, as well as by picking up certain arguments. In addition threads can be put to sleep for a specified amount of milliseconds. This feature should allow developement for scripts executing in the background checking for conditions in df triggering scriptable events

2. Views management

"Views" is an arbitrary name I picked for an area of the screen showing certain information.
The previous version has incorporated 5 views in a haphazard manner, specifically
  - the operand stack, which shows what operands are on the stack
   - the execution queue, which shows what functions are to be applied on the stack given the current command line
   - the command line, which shows the string you are typing in to be interpreted and executed
   - the errors view, which shows any errors that occur during interpretation or execution
   - the output types given by the command
   Some of these are implemented right next to each other, and none of these respond well when going past the width of the console.
   For the next version, I have already implemented a function that caps these to a specified width and allows scrolling of the output, however I'm also in the process of implementing a system to manage and configure views in a way the user finds desirable. In addition I have planned several new views:
  - intellisense
      - lists applicable functions within current context alphabetically sorted
      - autocomplete
         - grey text of letters that are the only way out of current context
         - up/down select between multiple functions
         - right key(or space?) autocompeltes
   - function help (lists inputs, outputs as well as a description of what it does with these, of the function currently under caret)
   - a memory scanner (for aiding finding offsets)
   - split view (allows display of 2 views side by side, can be used recursively for more than 2)
      modes of split views:
        - fixed (split in half by default, but splitter can be moved using ctrl-left/right)
         - left priority (prioritizes the left side allowing its length to determine the splitter position
         - right priority (same but for the right side)
      note that the current execution queue/error view represent left priority behaviour overlooking the behaviour when they hit the console width limit.
   Also there will be a few improvement on the existing views:
      - the command line will be color coded, with red color representing errenous code for easy identification
      - background color could be used with commandline to display what arguments are taken by the function currently under caret
      - up and down keys will go through commandline history
     - errors during parsing will provide
         -line, column
         - excerpt that is a scrollable view in itself (useful for evals and function template instantiations)
         - command line view will also paint the relevant code red, whether in the command itself or the function which could not be parsed.
         and exerpt of code where error occurs (for evaluated strings) or point to code in the command
    view (e.g. blinking or red text)
     - errors during execution will point to the location in the execution queue (blinking section?)
      - execution view will have its own caret for selecting and getting help on a particular function
      - execution view will have collapsed functions by default, pressing enter will open/close them.
      - during debugging, executed steps will be shifted out of view
      - during debugging, one step will involve opening the collapsed function
      - during debugging loops, an iteration will be instantiated beside the "blueprint" of the loop
So how should views be managed?
  - using the alt key, moving up and down will switch between views vertically,
   - using the alt key moving left and right will switch between views horizontally, in case of split views.
   - using alt+del to delete a view (deleting a split view will unsplit the view in favour for the other side)
   - using page up/down to switch between view types
   - using ctrl left/right to configure splitter, ctrl up/down to configure split view mode, or alternative have separate view types for each mode
   - left/right scrolls views

3. Lists

At the moment there is no kind of container in Dwarf Script at all, except for perhaps the potential to use the global namespace + string concatenation to dirtily implement arrays/associative arrays. So, the next step would be to have a basic list container which will be a new datatype.
  - head function gives the top element of the list
   - tail function gives the list without the top element.
   - head or tail on an empty list will throw an error.
   - empty will return 1 when its size is 0
   - size will return the size of the list
   - list constants declaration using {1 2 3} syntax
   - in addition to inputs which are passed by value and outputs which passed by reference, user defined functions will be able to take inputs by reference, allowing the direct manipulation of stack elements, making list processing and later to be implemented data structures efficient.

Minor features:
  - capped views with scrollable output
   - commenting is possible in two variants like in C/C++/Java:
      /* blah */
      // blah
   - stack data is now completely separate from type info, allowing faster execution without passing around type info at all.
   - stack is restored if execution fails (solved a bunch of problems i didn't want to deal with, implementing the above)
   - ascii 0-32 show as "?" inside strings in stack.
   - \123 inside string constants converts to ascii char 123
   - bitwise not
   - the ability to set or unset flags (untested)
   - loop mismatch error is more informative
   - rearranged views
   - used commands are now shown for easy copy/paste until history scrolling works.
   - history scrolling is now also implemented (use up and down keys)

   - the semantic separation of "" strings and () clauses. Yes, currently these are interchangable.
   - the syntactic separation of function declarations [] from loops and conditionals ()
   - once the above separations are made, typing loops and conditions in commandline can be more informative than currently (just showing as a string)
  - inlining &/ optimations
      I intend to have 4 optimation levels that a function call and utilize:
      1. inlining (internal + external merge compiling + simplification)
      2. internal interpretation + simplification
      3. internal interpretation
      4. text (evaluation at execution)
   - save string to file
   - enumerate template functions
   - extracting text from a template function
   - enumerating variables
   - using something else than STL string, it weighs down heavily on the size of the executable in the windows version
   - function pointers (almost implemented)
   - user defined types
   - scriptable error handling
   - scriptable coloured output
   - more string functionality
   - improved eval, that allows specifying output and input types
  - recursion, through specifying input and output. A specific form of function template instantiation (there is a way to cheat and do recursion at the moment by overwriting a mock function of the same name having the same signature.)
Bug fixes:
  - view disruption is fixed through capping and scrollable output
   - fixed disruptions caused by ascii chars 0-31 in strings on the stack
   - $ now displays in execution view
   - code now fetched rather than recompiled at every function call, and various sleeping bugs that this triggered
   - enter no longer executes when there are parse errors
   - fixed a bunch of memory leaks
   - multiline text outputs is now clean
   - functions should now list correctly
   - linux: fixed read4 bug when highest bit set, due to pread having a stupid 2G limit so switched to pread64

I've released a new version for both Linux and Windows

Added addresses/offsets for linux, except for skills vector

Also fixed:
   using escape characters no longer leave the escape character used
   errors during execution are now no longer overwritten
   linux "reads" reads now full string, not just first character + garbage
   linux "readstl" fixed
   made possible negative numbers
   "set" now works again
new feature:
   getfirstnames gets the dwarf first names rather than nicknames - can be combined with nicknames

Part 2 of the tutorial

Once you have understood the basic idea behind postfix, you can easily code any simple sequential script. But that is still a bit limited. So next you would probably want to do something more advanced like, using conditionals and loops.

A conditional is quite easy, but I'll demonstrate how for instance you would make a max function, that is a function that picks the bigger of two numbers. Lets assume we have 5 and 7 on the stack:
[5:7]
Then if we do:
a. b. a b > (a)(b)?a. <-- this gives the name 'a' to 7 and pops it off the stack
b. <-- this gives the name 'b' to 5 and pops it off the stack
a  <-- this picks out 'a' and puts it on the stack (7)
b  <-- this picks out 'b' and puts it on the stack (5)
>  <-- this compares the two and gives 1 =true (note that all integer values except 0 are interpreted as true in a boolean expression)
()()? <-- this basically is a conditional. unless the preceding value is 0, the first clause is executed, otherwise the second.
a <-- since it is 1 means true, the first clause is executed and a (7) is pushed on the stack.

The bigger value got pushed on the stack. Try the other way around on the stack. It will always give you the bigger one.

Now you might want to make a function out of this, so you can use it without having to retype the whole thing.
(a. b. a b > (a)(b)?)max;
Then you can try:
12 5 max
So now you've learn not only how to make conditional statements but also how to write functions, and how to define and use variables.

A couple things to note about the conditional though:
- The preceding value must be of int-type
- Both the true-clause and the false-clause must have the same input types (arguments) as well as same output types (return values). If they don't match ds will complain about it. Note, that DS will not execute anything half digested but interprets the whole string so that the input/output types of every expression is known before execution, which is why you can't have conditionals at odds with this rule.

Next on to the while loop which is a bit more trickier. Might seem easy at first but there are some things you have to keep in mind.
int i=5;
while(i--){
   cout<<i;
}Here's a typical C++ loop. The equivalent in DS looks like this:
5 (1-i. i# i)@The # function prints out i, which is first 4, then 3, then 2, then 1, then 0.
This can actually written in a bit more efficient form:
5 (1-$ #)@And I don't just mean syntactically taking less space, but it executes faster because this saves pushing and popping the named values. Instead $ duplicates the top value and uses the first of those two for printing and the second lives on to the next iteration as the decrement.

However that said, for newbies, the first one is a useful template and names makes it much more readable. And no, once interpreted, the names are stripped out and are replaced with hard physical addresses on a stack, so they are not that inefficient. These are the odd purple operations you never typed in, in the execution queue view.

So, I will make a couple of templates for easy loops for you:

The decrement loop:
5(1-i.      i)@the increment loop:
0 $5<(i.      i 1+$5<)@where you replace 5 with the number of iterations you want.

So far so good. The tricky part comes in when you want to keep a value other than the iterator. Then you have to think more like tail-recursion.
At least at the moment, since there is no way to redefine or reassign a variable. So at the moment this part resembles more a declarative language than an imperative one. But this will soon change, as I will allow reassignment of variables, and then I will update this part of the tutorial. Until then the trick is to have the clause take more values than the iterator. Here's an example of 3 values being pushed out of the loop back in at the beginning.
1 2 3   0 $5<(i. a.b.c.       c b a  i$5<)@
Now there are a few more things to note about while loops:
- it must be preceded by an int
- it takes at least one argument, the first of which is that int
- it returns the exact same types, in the same order so that the tail recursion works.

Btw you might be wondering, why I put together terms without spaces. I just like code taking less space. If you are the same as me, then you will be grateful that DS allows for extreme whitespace compression, more than in most languages. Basically you can remove all whitespace to the point the expression takes on a different meaning. All identifiers are either composed of a-z/A-Z followed by a-z/A-z/0-9/_ or alternatively any character besides these, double quotes, parentheses and whitespace, which can be used to define names so, yes &/*  actually constitutes a valid name for a function. Strings, numbers, both types of identifiers can all be put side by side with the exception for numbers after the a-Z type identifier. You can even put two strings side by side like this: "blah""asdf" But for simplicity and newbies might want to stick to putting space between everything, or at least to the same amount they put in a regular C/C++/java program.

To be continued...

I've just finished working on the first linux version release. It might slightly differ from the windows version since i did a big cleanup and reorganization of code yesterday and ended up altering a lot of code and even fixing some sleeping bugs. Yes, the swap function might be buggy with floating points, so don't use that with floating points in the windows version until the next release.

The linux addresses and offsets are different from the windows version so the current main.ds cannot be used with it unless the addresses and offsets are altered. For starters the creature vector is at 0x9306a00 - thats the only thing I have tested so far and it shows the right number of creatures with count.

I'll upload it in a moment and post replies