Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[milo christiansen]

Rubble has a slight advantage there, but it's kinda rendered moot by the fact that literally nobody other than milo has actually released a Rubble mod...

And I would do just about anything to change that, do you have any ideas?

The next version of Rubble will use Lua for scripting, maybe that will help...

In Rubble 7 news: Today I was planning to show a Rubble log that showed Rubble running Lua scripts, but after I had all the scripts I needed ported and all the runtime support for Lua done I discovered that the Lua VM I was using was riddled with bugs. Luckily I had another VM I could use, but now I have to rewrite the whole Rubble Lua API...

Oh, and did I mention that the main reason I chose the VM I did is because the other one has no documentation whatsoever? Fun times are being had (or not).

[Dirst]

Rubble has a slight advantage there, but it's kinda rendered moot by the fact that literally nobody other than milo has actually released a Rubble mod...

And I would do just about anything to change that, do you have any ideas?

The next version of Rubble will use Lua for scripting, maybe that will help...

In Rubble 7 news: Today I was planning to show a Rubble log that showed Rubble running Lua scripts, but after I had all the scripts I needed ported and all the runtime support for Lua done I discovered that the Lua VM I was using was riddled with bugs. Luckily I had another VM I could use, but now I have to rewrite the whole Rubble Lua API...

Oh, and did I mention that the main reason I chose the VM I did is because the other one has no documentation whatsoever? Fun times are being had (or not).

I'm working on making The Earth Strikes Back compatible with Rubble.  And by "I'm working on it" I mean "milo came to me with the converted raws and I just need to harden my scripts to make fewer assumptions about the environment."  Even that has been difficult with work getting crazy busy the last couple weeks.

I was, however, able to update the milo's Rubble version of TESB to the latest version very easily.  The syntax really does need a working example to work from, but otherwise works well.

Edit: milo, processing raws with Lua would be a very welcome feature.  Since this VM lacks documentation, I would recommend using only magma-safe materials for your code.

[Dirst]

milo, you mentioned an "IF" structure that can be used to hide raws that might cause problems.  The specific example was dealing with references to materials that might be deleted by another mod, but it can be a lot more general than that... especially if there are user settings visible to the IF (perhaps dummy add-ons?).

In working out how to add feldspar (from the More Metals mod) and its associated Hidden Xenotime, and I'm thinking for this mod I should wrap every template call in an IF.

[Dirst]

Looking deeper into the IF, it looks like I can use something like the following (give or take some syntax)

Code: [Select]

[!layers = [rubble.raws "inorganic_stone_layer.txt"]]

# A string.find value of -1 indicates the substring was not found.
[@IF;[string.find !layers "[INORGANIC:DOLOMITE]"];"-1";
    Dolomite does not exist in this world, so dolomite caste not created.
;
    {TESB_AWAKE_CASTE;dolomite;DOLOMITE;7:0:1;WHITE:1;BLACK:1}
]
to check for a specific string inside a specific file (e.g., does "[INORGANIC:DOLOMITE]" exist inside inorganic_stone_layer.txt?) but not if a specific tag appears in the processed raws.  Delaying the test until the post-parsing stage might help, but I'm not sure if rubble.raws is looking at the original file or the processed one.  This can make a big difference if the material in question was defined as part of a template (the original file would give a false negative), or if the entire material definition is contained inside a conditional block (the original file might give a false positive).

Is there a virtual file into which all of the processed raws are dumped?  That way one doesn't need to know exactly which file defines a tag, and it doesn't depend on the other mod using Rubble's shared-object infrastructure.

[milo christiansen]

@IF is a template, use it like so:

Code: [Select]

{@IF;a;b;then raws;else raws}

if a == b then the template will be replaced by the "then raws", if they are not equal they will be replaced with the "else raws". Obviously this is only useful when either a or b is a configuration variable or template parameter, so @IF has a fairly narrow use case. If you look in the base template documentation it has examples, plus descriptions of several related templates (@IF_ACTIVE or @IF_ENTITY_PLAYABLE for example).

The code you show seems to be a weird hybrid of Rhino (which goes in ".rhn" files) and template (which goes in ".txt" or ".rbl" files).

In your case (detecting the existence of dolomite) if you want to use a template you would want SHARED_OBJECT_EXISTS (see the base template documentation that comes with Rubble). BTW: The "TESB_AWAKE_CASTE" template *should* already use this template. If you look at it you will see that if the given material does not exist it will replace the caste/tissue with a message saying so.

In a script you would use something like this:

Code: [Select]

(if (exists [rubble:shared_object_data] "DOLOMITE") {
    # Dolomite exists, do something...
}{
    # Dolomite does not exist, do something...
})

Obviously using scripts this way requires knowledge of exactly how the templates are implemented, which is why I recommend you stick to just using templates wherever possible.

In Rubble 7 news:
The Lua API is basically finished, now I just need to port all the scripts. This is easier than it sounds, as Rubble really doesn't have many scripts outside the standard library.

I encountered a simple JavaScript runtime, so it looks like Rubble 7 will support JavaScript as well. So far I don't have a proper API written for it, but simple test scripts work fine The biggest issue will be coming up with a system to allow scripting systems to communicate without knowing anything about each other, after all JS scripts will need to be able to interact with the mostly Lua standard library...

I'll probable end up with some kind of shared "registry" that all scripting systems can read and write in some way.

[Dirst]

It was actually @IF_CODE that I was using (badly).  The version of the caste templates you sent me did not check for the existence of the material, but I'll see if I can put it in there with the SHARED_OBJECT code.  Is every valid object automatically a shared object?  I want to avoid duplication of effort, but I will also try to make some templates for Wyrms and secrets mostly for practice.

[Abadrausar]

The next version of Rubble will use Lua for scripting, ...

Nice move Milo, Rubble DF modding framework could  then reuse the Lua knowledge of the dfhack team and the Dwarf fortress modding community.

... I discovered that the Lua VM I was using was riddled with bugs...
Oh, and did I mention that the main reason I chose the VM I did is because the other one has no documentation whatsoever? ...

If you are evaluating lua VMs as candidates for Rubble scripting and your evaluation is not closed,  you could have a look to refactored Metalua 0.72 http://lua-users.org/lists/lua-l/2014-01/msg00636.html

Metalua http://metalua.luaforge.net/ is used as a Lua code analysis tool in projects like LuaDevelopmentTools https://eclipse.org/ldt/ (the Eclipse-based Lua IDE, so good community support and maybe even some docs...), LuaDocumentor (an LDoc-like tool which retrieves information missing from comments through code analysis), LuaInspect (back-end for SciTE and ZeroBrane) , etc.

If you dont like metalua VM you can also choose another from the list supported by ZeroBrane Studio Lua IDE http://studio.zerobrane.com/ supports debugging with an ever increasing number of different Lua VMs as for LÖVE, Moai, Gideros, Marmalade Quick, Corona, and Cocos2d-x. It also supports general Lua debugging for Wireshark, GSL-shell, Adobe Lightroom, OpenResty, Lapis, Moonscript, home automation, and more.

DFhack is almost a Lua VM or not too far of becoming one. Adding support for debugging dfhack lua scripting to one of the lua IDEs cited could reduce the entry barrier. Adding this support in zerobrane is ,maybe, easier as this IDE is developped 100% in Lua.

[milo christiansen]

@Abadrausar: Sounds like a really nice VM, but I need a VM that seamlessly integrates with Go, as that is the language Rubble is written in. I had three choices:

• go-lua: Which has decent documentation and mirrors the API of the reference implementation of 5.2
• gopher-lua: Which has a not so helpful readme, but no code documentation, and does not mirror the standard API.
• Some kind of binding to the C version (of which there are several): Which all have problems with error handling (Go doesn't like longjump or C++ exceptions), and all of which are harder to use due to memory management issues between Go and C code.

go-lua was what I was planning to use, but I ran into bugs in the VM. I have the binding rewritten to use gopher-lua, so I'm back on track now.

@Dirst: Please don't use @IF_CODE. It will be going away in Rubble 7 because running scripts in slightly more complicated there (you need to tell Rubble what language the script is in), plus Rhino (the current scripting language) is going away, so everything that uses @IF_CODE would have to be rewritten anyway. Did you look at the second version I uploaded (same link as the first version)? That definitely checked for material existence (it also had more stuff wrapped in templates than the first version did, including the wyrms AND secrets).

Is every valid object automatically a shared object?

Nope. Just objects which are wrapped in a call to SHARED_OBJECT, SHARED_CREATURE, SHARED_INORGANIC, SHARED_MATERIAL_TEMPLATE, SHARED_PLANT, or SHARED_ITEM. All the stuff in the standard base (and the First Landing base) are properly wrapped, so there is no need to worry about standard materials being wrapped. SHARED_OBJECT is one of the fundamental parts of the Rubble template system, so it is fairly important to wrap all creatures, inorganics, material templates, plants, and items wherever possible. See, SHARED_OBJECT allows you to replace an object with a new one, add stuff to the end of an existing object, and do things based on whether a named object exists (among other things), so it is very handy to have. I did not wrap anything in the addon I gave you because I was feeling lazy :p (that and wrapping creatures is difficult to do properly, in your case it would require rewriting most of the caste templates to some extent).

In Rubble 7 news:

I hacked together a quick utility to convert Rubble 6 addon.meta files to the new Rubble 7 format (JSON), so addon porting is going faster now. The Rubble 7 template library will also have some new string handling templates, namely @STR_UPPER, @STR_LOWER, @STR_TITLE, and @STR_TO_ID. These templates should make certain kinds of user templates much easier to write.

I am making a concerted effort to provide templates for as many common actions that used to require scripts as possible, so an extended version of @IF that supports more operations than equality may be in the cards

JavaScript is being stubborn, the VM I am using is designed to be simple, but sometimes it is too simple. For example the only way to export a data structure is via an autogenerated interface that uses Go's reflection library. This means that I have no way to limit what scripts can do, and conversely I have no way to automagically convert byte slices into strings and vice versa like the Lua API does. This means that data structure access will all have to be done by functions, no handy "direct access" to the underlying objects and arrays like the Lua API does. Trying to use the autogenerate interfaces for everything would be like trying to export everything with GenII in the old Rhino API, eg powerful, but hard to use and with lots of potential to machine-gun your foot

I may post a few "prerelease" version of Rubble 7 before the next DF version, but 7.0 won't be going live until shortly after next time Toady gives us a new toy 

[Dirst]

Didn't see the update (and can't check it now because I'm on a phone), but I figured you would convert those things... I was doing it for practice.

And yes string functions will be very handy.  No more passing GRANITE;Granite;granite as three separate arguments.

[milo christiansen]

No more passing GRANITE;Granite;granite as three separate arguments.

I see you found my inspiration...

[milo christiansen]

So, I started playing around with the web UI and next thing I knew:

Spoiler (click to show/hide)

Pretty good for someone who's only HTML reference has a large section on the differences between IE and Netscape 4...

The new web UI is much more dynamic. No more HTML forms, changes are sent directly to the server as soon as they are made. Many pages have been combined, with parts showing and hiding as needed. I also finally killed the back button, so no more weird bugs related to going back to a page you should not be able to reach right then.

Many pages are generated via templates on the server, but some still generate client side via JS (mostly just the ones that require lots of logic).

The image is of a section of the addon information page for "Libs/Base" after I clicked the "Show Details" button, followed by clicking "addon.md". As you can see you can browse an addon's files from the web UI without needing to load a new page (in the old UI file contents were on a different page).

[palu]

What JS engine are you using?

[milo christiansen]

For Rubble scripting? Otto (a native Go JS engine). For the web UI? That uses whatever your browser uses.

JS for Rubble scripting will not be ready for the 7.0.0 release, but everything else will be.

Expect a working (but missing some addons) 7.0.0 for DF 42.1 to be up soon (in a thread of its own).

[palu]

Is Otto es5 fully es5 compatible

[milo christiansen]

As I understand it, almost. There are a few problems with regular expressions (it uses the Go implementation of RE2 internally, which does not support back-tracking) and "use strict" parses but does nothing. Otherwise it is fully ECMA5 compliant (according to it's readme anyway).

Rubble 7.0.0 can run JS scripts, but there is no real API for interfacing with Rubble yet, so they are of limited use.