Alexey Torkhov’s blog

Running Fedora ARM on Nokia N900

2010-02-10T16:44:00.001+03:00

When I’ve got mine N900, I thought, pity that it doesn’t have Fedora in it. But now, I’ve managed to run Fedora ARM port on it.

Steps were the following:

Rebuild kernel with FRAMEBUFFER_CONSOLE=y enabled to see console output and flash it. It is well described on Maemo Kernel Guide and Jebba’s notes
Setup bootmenu
Unpack prebuilt rootfs to partition on an SD card
Copy kernel modules to /lib/modules and firmware to /lib/firmware inside new system

Hardware support

Watchdog

To prevent hardware reset by watchdog chip it needs to have chars regularly written to correspondent device. On N900’s board this is /dev/watchdog and /dev/twl4030_wdt. I’ve made simple rpm with config for watchdog daemon and startup script.

Wifi

Wifi is working “out-of-the-box”. Only script to startup it like this one should be prepared and put to PATH, as there is no way to type anything except english letters from console.

Touchscreen

tslib could provide touchscreen support, but to be available in X it needs xf86-input-tslib driver.

Battery

To have battery charging it needs to run bme proprietary daemon.

But it is more useful to run Fedora system in chroot from Maemo to have familiar userspace instead of cripple busybox.

Making an evil initrd with febootstrap

2009-10-14T01:21:00.000+04:00

Иногда, мне приходится админить известную ОС Вселенского Зла. И чтобы производить разные автоматические действия, типа разбиения диска, я сделал специальный initrd который может загрузиться по сети и сделать свою работу. Это просто благодаря утилитке febootstrap. Хотя, мне пришлось пропатчить её чтобы она работала из-под рута — патч в баге 528687.

Скрипт для создания злобного initrd, который сотрёт все разделы на диске, создаст два и отформатирует первый в NTFS в конце заметки. Не запускайте его на своей машинке >:)

----

Sometimes, I have a need to admin an well-known World Evil OS (Windows, yeah). And to do some unattended operations like custom disk partitioning, I've made special initrd that could be booted over network, and do the work. This was simple thanks to febootstrap util. Though, I had to patch it to flawlessly run under root, see bug 528687.

Script that makes an evil initrd that erases all partitions, creates two and formats first to NTFS at the end of post. Be careful not to run it on your machine >:)

----

LANG=C i386 febootstrap fedora-11 fedora-parted file:///home/alex/tmp/repo -i coreutils -i parted -i ntfsprogs -i upstart

MAKEDEV -d fedora-parted/dev -x sd{a,b,c,d}{,1,2,3,4,5,6,7,8}

febootstrap-minimize fedora-parted

cat > fedora-parted/init <<EOF
#!/bin/sh

/sbin/parted -s /dev/sda mklabel msdos mkpart primary ntfs 0 50% mkpart primary ext2 50% 100% set 1 boot on
/sbin/partprobe /dev/sda
/sbin/mkfs.ntfs /dev/sda1
/sbin/reboot -f
EOF
chmod +x fedora-parted/init

febootstrap-to-initramfs fedora-parted > initrd-parted.img

Mounting raw and qcow2 VM disk images

2009-09-21T16:33:00.000+04:00

Mounting a partition from raw image is pretty simple:

losetup /dev/loop0 image.img
kpartx -a /dev/loop0
mount /dev/mapper/loop0p1 /mnt/image

If kernel parameter (as loop in compiled into Fedora’s kernel) like loop.max_part=63 added it is even simplier:

losetup /dev/loop0 image.img
mount /dev/loop0p1 /mnt/image

Alternative way is to specify direct offset to partition:

mount image.img /mnt/image -o loop,offset=32256

To mount qcow2 images there is (at least in F-11 qemu) very useful qemu-nbd util. It shares image through kernel network block device protocol and this allows to mount it:

modprobe nbd max_part=63
qemu-nbd -c /dev/nbd0 image.img
mount /dev/nbd0p1 /mnt/image

If LVM is present on image it could be initialized with:

vgscan
vgchange -ay
mount /dev/VolGroupName/LogVolName /mnt/image

Finishing is done with (depending on how it was initalized):

umount /mnt/image
vgchange -an VolGroupName
killall qemu-nbd
kpartx -d /dev/loop0
losetup -d /dev/loop0

Tasks properties widget

2009-07-14T01:26:00.000+04:00

On last week I had to spend some days on my postgraduate application. Good news here that it is ended now and I hopefully will have more time to work.

Also I've committed the tasks properties widget code but it does not work properly yet. Going to fix it this week.

No progress :/

2009-07-07T03:49:00.000+04:00

Last week was a busy for me - I had to do some bureaucratic things to receive my diploma and apply for postgraduate course. So, was tired and did almost nothing. Anyway, I’m going to some progress on client part next week. And also, I’ve find that we deviate from original plan long time ago (tasks properties were not part of it at all), so it should be rehashed, I guess.

Adding coverage tests

2009-06-30T03:52:00.000+04:00

I've created unit test for my new tasks property code last week. It was useful as it helped to find one problem in code with uninitialised variable. Also, I've started some code to create tasks properties widget in Ember (but didn't commit it yet).

The list of things to do is left unchanged: parameters filtering on server side; Eris changes and widget on client side. I want to do some client stuff on this week.

Task properties are doing something

2009-06-23T02:59:00.000+04:00

On last week, Al helped me to fix the “bug” with python script which turned to be not a bug but simple error.

Also I’ve make a new world initialization script (define_world_empty.py) that creates an empty script. It helps to monitor with cycmd without being spammed with all kind of different event from entities and NPCs from default world. While it is possible create empty world with calling some functions from main define_world.py, I think that having separate script to create empty world, is useful by itself, to serve as a template.

Next, Al made a prototype for some core class that would allow to change task property and I added some logic to it. So now, operation for change of task properties is successfully processed, property changed and exposed back to client.

Next things to do on server side, is to implement filtering to let change only allowed properties, and on client side to make changes in Eris and create widget to select task parameters.

Tasks interface exploration

2009-06-16T03:05:00.002+04:00

On this week I did some exploring on what is needed to implement tasks interface along with some learning on usage of cycmd and cypython tools.

I started wiki page with specification of tasks interface.

Then, I was trying to do set operation from python task script, but this run into a bug in current python bindings.

Next, I did some exploring on client side. Added sample attribute to task class and tried to load the class in Ember. Basic code like request a class and print its attributes does the work.

As I see, all task handling on client is done in Eris. So, I need to add to Eris::Task class ability to store attributes. That is adding some variables and logic to fill them in Task::updateFromAtlas().

From server side, as it doesn't use Eris, something in Character use operation handler should be made. And also nasty python bindings should be fixed.

That’s what I’m going to do on next week. But Al should enlighten me on what exactly should be made on server side.

Tasks interface discussion

2009-06-09T03:22:00.001+04:00

Last week we started to discuss how to express user interface for tasks. To recall, we want to provide an UI for task that would allow player to select the parameters of a task and control it.

We want add additional declarations for attributes that are allowed to be changed to existing declaration of task. This data then should be sent to client and used to present an interface when task started.

And that’s what I’m going to do next week: try to manipulate attributes of an existing task, also write draft specification for attributes declarations in task, add some example attributes and see what should be done for it to be shown in client.

The Void in code space

2009-06-02T00:44:00.000+04:00

Not much happened last week in mason game systems from. Better to say, nothing happened at all. But this is expected, as I had exams.

Now, exams are over and I can get back to work on the project. Seeking forward to postponed replies on my mail on expressing interface for tasks.

Playing with fire and rope making

2009-05-25T17:47:00.000+04:00

So, GSoC officially started, and here is my first report this summer :)

All development for this project is happens on ‘mason_game’ branches in mine gsoc2009/alex-cyphesis.git and main ember.git repos at git.worldforge.org.

I started to work some weeks ago and did a few things. To learn about representations of types, entities and scripts inside Cyphesis server, I decided to change starting place in the world.

One thing for improve was the behaviour of campfires. With addition of proper dynamic lighting and shadows support in Ember we got nights to be dark. And having light source become essential to move without striking against the trees or being trapped by goblins.

In default world, campfire starts with fire but it soon goes out without fuel. On the contrary, if some fuel added to it, then it lasts forever because there is no feature to remove objects when they are fully burned. So, adding some fuel from the start does the trick and sheds the light on starting point place.

To let players have their own light source, I put two torches that players are free to take. Currently, Ember deserve some fixes to properly show the torch when hold by character.

Also, in between, some fixes were made in Ember to finally finish the shadow shader. But this really is not part of GSoC.

Next thing I made is rough implementation for rope making. I read a bunch of articles on rope making and history of agriculture to get some understanding of how they were making ropes in middle ages. Basing on this, I created a wiki page to collect info about farming in Mason. After that, added type definitions for correspondent tools and implemented simple task for making grass rope. It could be refined if that’ll be necessary.

On the ongoing week, I’m not planning to code anything as I’ll have exam at the beginning on June, granting that I did some work earlier. Nevertheless, we will discuss next steps about next sawing task.

Patches for Pidgin

2009-05-20T02:08:00.001+04:00

I’m using pidgin for all IM and chat conversations for some time and there were two things annoying me. And I made patches for them:

Pidgin does not report OS version due to some subtle security reasons. Here is the patch №1 that reports current Fedora version.
No way to change nick completion suffix from colon to comma. Here is the patch №2.

Accepted again!

2009-05-07T18:33:00.000+04:00

I’ll work for WF second time this summer. Yay!
Here is essential part of proposal.

Synopsis

Implement game systems require to build a basic castle fortification from scratch from gathering raw materials to the completed construction.

Benefits for WorldForge

When asked about what WF is, you cannot simply answer “It is a set of tools for making games, look what cool game they made”, because there is currently no any playable game. Completing of this will increase number of things players can do in stock Mason game. It will also act as an example tasks for world creators. And hopefully, help to increase overall number of people who do custom world creation.

Deliverables

In the end, the set of tasks, tools and entity classes for cyphesis for constructing walls should be implemented. Needed core and client modifications will be made along the way.

Detailed Description

Proposal is to improve and implement cyphesis tasks and necessary accompanied things for following mason techs: plants, plant-fibre, logging, rope, sawing, pioneering, palisade, scaffolding, mining, earthworks, walls, gate, and fortification.
List taken from blueprint: https://blueprints.launchpad.net/cyphesis/+spec/gs-fortification

Each tech will require a set (zero, one or several) of tasks, a set of correspondent tools to perform the tasks and a set of entity classes on which action is performed. Some, tasks, tools and classes are already present in current mason impelementation and could be reused.

Here is the list of techs, a brief description taken from blueprints and my comments about how it should work and what should be done for each tech:

plants. Gather plants growing on the terrain.
Cut action could be performed with scythe on grassy terrain now.
An other task could be added for gathering different kind of plants suitable for making ropes, like gather reeds with knife.

plant-fibre. Process the right kind of plants into plant fibres to be used as a raw material.
Gathered plants should be cleaned, dried and somehow processed. This doesn’t require any tool, just time. Needs adding fibre class.

rope. Wind plant fibre into rope.
Here several fibres are winded into rope. Doesn’t require any tool either . Needs adding rope class.
Cyphesis, though, does not have ability to perform an action on several entities. So, perhaps, it require an improvement to server or a workaround.

logging. Gather timber by logging trees.
Chop trees could be performed with axe on trees now.

palisade. Palisade from logs.
Lever action could be performed with pole now.
But logs should be processed before levering so they look pretty, like the palisade around goblins camp.

sawing. Take raw logs and process them into the different types of shaped timber required for construction and crafting.
Slice action could be performed with bucksaw on logs now.
Task for making differently shaped timber could be added.

pioneering. Create rough structures using rough cut timber and ropes.
It is good to have ability to make arbitrary wooden structures, but this proposal is not targeted at this.
This tech could be skipped and simulated by creation predefined wooden structures or by consumption of wood when constructing walls (like Warcraft :)

scaffolding. Construct scaffolding from sawn timber.
This is construction of predefined wooden structure that consume sawn timber and ropes.

mining. Gather rock by quarrying rocky terrain.
This was “quarrying” in blueprint, I renamed it to be more traditional.
Cut action could be performed with pickaxe on rocky terrain now.
It could be modified to produce rocks of different styles and sizes.

walls. Construct walls out of stone or wood.
Constructs a wall section like one we already have in media:
http://amber.worldforge.org/ember/screenshots/tn/screenshot_20081030_001318.jpg.html

gate. Construct a primitive gate from rough wood and ropes.
Like a wall, but constructs section with gate.

earthworks. Modify the terrain by digging trenches, embankments and other shapes.
Creating new and modifing existing terrain modifiers. It could be “flatten” task that is based on Level modifier.
Modifier for digging trenches may be implemented.

fortification. Construct a fortification with stone walls and gates.
A generic tech just head the hierarchy.

Project Schedule

We have 12 weeks on program. Here is the approximate plan on spending that time:

1. Tame the python.
2. Analyse the tasks. Describe what exactly they should perform and document this on wiki.
3. Add/improve simple tasks (plants, plants-fibre, rope, mining).
4-5. Start needed cyphesis core modification or invent the workarounds.
6. Make middle-level tasks that doesn’t require core modifications (palisade).
7. --- Mid-term evaluations: present some working code.
8. Finish cyphesis core modifications.
9-10. Make tasks down in hierarchy (scaffolding, walls, gate).
11. Make earthwork tasks, possibly expanding terrain modifiers.
12. --- The last week is to finish the work.

I was proposing something similar but vague last year: http://alexeytorkhov.blogspot.com/2008/04/improving-mason-game.html

Bulk file renames

2009-02-10T18:49:00.035+03:00

I was always using shell scripts to do mass file renamings. But now there are definitely simplier tools exist. One of them came to my knowledge recently is rename. It is standard tool and does the most simple and common task—replace one substring with another in filenames.

Second useful tool is convmv. It not only allows to convert filenames between different encodings, but also to convert between upper and lower case.

Also mmv deserves mention. It could do replacement basing on pattern.

RPM verify and restore capabilities

2009-02-09T00:18:00.002+03:00

Good that RPM could verify files (-V option) and restore permissions and owner modes (--setperms and --setugids keys). More here: How to reset the permissions of the installed rpm packages with --setperms option. It allow me to repair part of root filesystem with accidentally changed owner.

Typographic layout

2009-02-07T21:43:00.001+03:00

Finally, typographic layout has been included into xkeyboard-config release 1.5 that is available in rawhide now. It enables access to symbols like «, », ©, ≠, —, … from keyboard which is very convenient for typing web texts.

Unfortunately, something makes it non-working when selecting from gnome keyboard config dialog. So, I had to add typo typo:2 to xkb_symbols from setxkbmap -print output and put call of setxkbmap in autostartup programs. Resulting command line is:

$ setxkbmap -symbols 'pc+us+ru(typewriter):2+inet(evdev)+group(shifts_toggle)+level3(ralt_switch)+typo+typo:2'

Yay! I have typographic symbols in both English and Russian layouts switched with AltGr.

Interpretation of old paintings

2009-02-06T12:55:00.048+03:00

Pierre Carrière-Belleuse. La place Pigalle in Paris. 1880.

I’m not frequent visitor of museums, but was recently here in Gallery of Impressionists. And it is interesting how old paintings could be interpreted.

For example, this picture. It clearly looks for me as picture from some pseudo-3D isometric computer game. Really, it has broken perspective close to isometric; it has level of detail—only near people have detail faces; it has sprite-alike layout—carriages and people are moving mainly parallel street edges.

Hmm… my mind is too computer-aligned. Need to go for a walk… :)

Configuring lm_sensors for Asus P5E3 motherboard

2009-01-30T21:06:00.128+03:00

Standard configuration of lm_sensors with sensors-detect find right monitoring chip and it was showing all reasonable data except voltage, that was differing by more than 10% of nominal. And it was slightly bothering me.

Finally, after reading lm_sensors Asus article, I was able to craft right voltage sensor formulas for my Asus P5E3 motherboard that give the same values as BIOS.

First, need to decompile description tables (iasl package had to be installed):

# cat /proc/acpi/dsdt > dsdt.bin
# iasl -d dsdt.bin

Deciphering all ACPI magic that is written to dsdt.dsl is not very easy. I was looking for RVLT function that gives the formula for voltage:

Method (RVLT, 1, NotSerialized)
{
    And (Arg0, 0xFFFF, Local0)
    Store (VGET (Local0), Local1)
    Store (DerefOf (Index (DerefOf (Index (VPAR, Local0)), Zero)),
        Local2)
    Store (DerefOf (Index (DerefOf (Index (VPAR, Local0)), One)),
        Local3)
    Store (DerefOf (Index (DerefOf (Index (VPAR, Local0)), 0x02)),
        Local4)
    Multiply (Local1, Add (Local2, Local3), Local5)
    Divide (Local5, Local3, , Local5)
    Add (Local5, Local4, Local5)
    Return (Local5)
}

Translating to normal language it does approximately the following:

Local1 = VGET(Local0);
Local2 = VPAR[Local0][0];
Local3 = VPAR[Local0][1];
Local4 = VPAR[Local0][2];
return Local1 * (Local2 + Local3) / Local3 + Local4;

To find out Local parameters for each sensors, need to look at VPAR definition:

Name (VPAR, Package (0x04)
{
    Package (0x03)
    {
        Zero,
        One,
        Zero
    },

    Package (0x03)
    {
        0x22,
        0x22,
        Zero
    },

    Package (0x03)
    {
        0x14,
        0x0A,
        Zero
    },

    Package (0x03)
    {
        0x3C,
        0x0A,
        Zero
    }
})

Comparing this to order of data in other places of tables (VCore, +3.3V, +12V, +5V) one can see that right coefficients for +12V is 60/10 and for +5V is 20/10.

Resulting config is here.

Final GSoC gift

2009-01-11T19:44:00.002+03:00

Finally, I’ve received my t-shirt. That was complete surprise for me, as I didn’t get any FedEx tracking number. So, Summer of Code 2008 is officially end for me. 2009 starts! :)

Ember 0.5.4 packages

2008-09-11T16:20:00.002+04:00

I’ve updated ember and ember-media still-waiting-for-review packages to newly released 0.5.4 version. Main change since previous is that all three GSoC projects including mine are merged.

Update: Thanks Spot for reviewing the package! Now it is being build and will be in rawhide soon.

Entity creator screencast

2008-08-25T10:28:00.001+04:00

Erik has created a demo that shows current abilities of entity creator: streaming, original.

It would be great to see it integrated and released with next version of Ember.

The End

2008-08-18T22:43:00.000+04:00

Today was the last day of coding phase of GSoC, so here is the summary of what’s done through second part of the program. During this month, entity creator starting from basic tool gained the following:

preview of entity that has to be created,
placing of entities using mouse-to-terrain feature,
more user-friendly GUI: recipe description, adapters labels, help blurb with note about usage,
expanded documentation in code and on wiki page.

I think, development of entity creator shown directions of what need to be improved and refactored in Ember to ease making of authoring tools. This is things that were difficult when implementing entity preview—detached entities and initialization of them using model mapping with all things like proper scaling and rotation. Would be good be to have this as some generic reusable interface.

I would like to thank Erik and all WorldForge community for help during the program and I hope we will work together in future, as there is many things to do for mature authoring tools and in Ember itself.

Final week

2008-08-11T13:21:00.000+04:00

On last week, I’ve made some tweaks that are improving user interface. In particular, I added help text when entering to create mode that says how to exit from it. Next, I implemented suggested “Random” list element that allows to select random list item without need of implementing some Lua function. Also added is ability to add custom text that is different from item value, i. e. you can add item “Boulder style A” with value “a”.

This week is final. I will try to make real-time update of entity with new adapter values. Though without this feature entity creator is already usable—I currently tweaked UI to be consistent for the case if I’ll not find what prevents CEGUI to pass event back to my application.

Also, I need to finish documentation on wiki page—there is some things that, for example, are useful when writing Lua scripts and should be documented.

And two things are left in Lua scripting provider: first is handling any number of results and second is calling functions with dots in name. There is probably not much work, but they are not needed right now and I’m thinking that I’ll better would not distract from my application and leave them for the future.

Polishing user interface

2008-08-04T12:28:00.000+04:00

On last week I’ve made a lot of fixes that are improving user interface much. First, this is correct preview of entity. And also a bunch of smaller things:

Labels for adapters,
Staying in “create” mode after creating first entity,
Rotation of an entity with mouse wheel,
Fixing a bug when switching recipes.

Also, I tried make to preview (and entity that is to be created) reflect changes of adapter values in real time. I wrote a code that should do the task. It uses standard signal of an adapter. That signal should be emitted on text change event from CEGUI, but that event is never called and therefore signal is not emitted. I don’t know well what can I do with this, but I’ll try to debug it or find alternative way to get that event.

Next two weeks are final. I’ve left only a few tasks:

Real-time update of entity with new adapter values,
Add “random” element for drop-down lists and handle it programmatically,
Small tweaks in user interface,
Improving wiki page with documentation,
Make Lua scripting provider handle any number of results.

This probably will left some time to do some other small things. Anything that would not be finished could go to todo, ideas or wishlists.

Working with model mapping

2008-07-28T16:31:00.000+04:00

I’ve started to work with model mapping framework on last week. It required to reimplement or copy a bunch of methods from EmberPhysicalEntity and satellite classes. It didn’t satify me well and I made an attempt to reuse EmberPhysicalEntity directly but it wasn’t very successful. I’m thinking that it in some places assumes entity properly belong to entity hierarchy. Making it to support detached entity seems to require some changes there. So I decided to drop this attempt and continue to work with model mapping directly to render preview mesh correctly. And that’s what I’m going to do for next week.

Entity positioning

2008-07-21T16:56:00.000+04:00

On last week I’ve made terrain positioning of new entities. It allows to see position where entity will be created. But the preview mesh isn’t the same as entity that will be created.

This is the goal for next week—make preview fully represent new entity. To achieve this, I need to implement Erik’s plan on DetachedEntity class and feeding it to model mapping framework. This is partially done but not commited yet.

Also, user interface should be improved—it should stay in “create” mode after creating first entity and allow create fast as many more entities as user wants. Also minor things like changing orientation on mouse scroll should be made.

More OGRE bits

2008-07-14T18:59:00.000+04:00

Performing ritual

Last week I spend looking and learning on what should be done during the second part of program.

The main feature that should be implemented is easy entity positioning. This means that while moving mouse over terrain it should show preview of entity that will be created. Positioning of entity with mouse was recently implemented by Sean and Erik. So I need to implement showing imaginary preview or bounding box in the world. This carried me in deeply in Ember internals. I’m guessing that this task could simply be solved with some OGRE bits and intercepting some controls but I didn’t find my way to it yet.

It’s working!

2008-07-07T12:57:00.009+04:00

On last week I’ve finally made my program work! Thus finishing goal for first part of program just in time. As there comes a time for midterm survey, I’ll make a summary of what has been already done.

So, at the moment we have a program that can do following basic things:

parse entity recipes,
show widget,
show GUI adapters from entity recipe on its widget,
pass adapters values to Lua function that is specified in entity recipe,
compose entity replacing placeholders in entity specification with values received from Lua function or from adapter directly,
send entity to server.

Regarding on what to do next, it needs at least:

improving GUI—like adding title to adapters, etc.,
adding preview of new entity,
using mouse-to-terrain feature to place entities and
improve current code and features.

This should be discussed and corrected after some kind of review of what’s done.

And one more organizational point. I’m going move to the country since next weekdays. Quality of Internet connection there is not good, so, probably, most of time I’ll not be available on IRC/Jabber. Though, I hope, will read email regularly.
And very good that we are using Git—I can commit regardless of connectivity.

Gluing altogether

2008-06-30T15:27:00.000+04:00

On last week I started to glue all different parts together. That is: wrap current adapters in my class GUIAdapter until (if ever) AdapterBase API would be changed to be more friendly, binding GUIAdapterBindings to adapters and XML element. Also parser for adapter bindings and entity recipe placeholders were written. With placeholders, I forgot at start that entity recipe is semi-atlas because of placeholders and cannot be stored as Atlas element, so this was need to be changed too.

This week I’ll continue to glue all this pieces to make it do some real work. And also general things like error handling over my code need to be improved.

Ember RPM package for Fedora

2008-06-25T14:18:00.004+04:00

Submitted Ember RPM package for review to Fedora. Also, libwfut package is propagated to mirrors and now available in Rawhide.

Improving adapters API

2008-06-23T19:09:00.002+04:00

I was ill since middle of last week (cold or something like that). Now it’s better but perfect :(

Anyway, I did something on my project, not much though.
I stopped with improving adapters API—I need a function that would create adapter just by its type name. With previous implementation, EntityEditor used some internal functions/methods to achieve this. Unfortunately, it seems impossible to convert them to some general interface.

So, I’m added this function to API. But there other problem rises: when creating adapter, atlas message object need to be passed to constructor. Value of this message is used then to populate adapter GUI element for first time and seems nothing like that. But, this element value has to be carefully crafted and be valid for this adapter type. For example, if it is number adapter then it should have number type, if it is 2D-position than it must be list with two number sub-elements, etc.
EntityEditor contains functions for creating all these element types. It is good functions and could be useful in some cases. But in overall, I see this approach as non-scalable—it is hard to add new adapter type.
So, my proposal is to let adapters handle elements of type NONE as some kind of default value.

Also, in some small time slices I was looking into packaging ember for fedora. When doing that, I find some license issues with ember and other libs.

Tweaking entity creator widget

2008-06-16T16:11:00.000+04:00

At this weekend I was tweaking entity creator widget.

I added lists of all recipes to it. When clicking at recipe it creates adapters for it (with static text yet).

I was starting to do it with lua, but find that bindings for some STL classes are not exist and decided to move code that uses it into C++ helper function. I’m going to try to create this bindings eventually as coding this things with lua when proper bindings exist is somewhat easier and faster.

I have also some tasks left: fix lua call context, fix atlas bindings and merge new admin widget into my branch. But I decided to postpone and spend time working on widget. I like it, because of “visial” results available.

So, primary task for this week to do is to populate widget with real (not static) adapters. And on next week, I hope, it’ll be possible to bind values from adapters with entity attributes and create entity :)

Lua call context API is usable

2008-06-09T17:22:00.003+04:00

During last week I was working on Lua call context API. This work in not finished yet because it still has bugs—some cases are not properly processed for example, when error happens during the call, also, notation that is currently used to convert value to object is not very beautiful:
returnValue.asObject<atlas::message::element>("Atlas::Message::Element")
it needs to be reworked.

Anyway, it’s now quite usable for my task. I’ve made an example code that uses it and gets an Atlas::Element from Lua. But here is new problem appear—tolua bindings are not very well handle overloaded functions, so Atlas bindings should be tuned.

Concerning my future plans, I need to design structure of an application, API of its classes. I also find components/ogre/widgets/adapters and need to change my existing classes according them.

I’m unsure how this structure should be organized, but want to start implementing GUI part and adding necessary functions to API along the way.

Working on Lua call interface

2008-06-02T21:08:00.000+04:00

At last weekend I started to look at lua scripting part of my application but “suddenly” find that ember scripting support lacks of ability to get return values from lua calls. Then Erik kindly made an scripting call context interface—it’ll be possible to get return value with it. So, my plan for next days is to clean up and bring it to state where it could be used for my task.

And task itself is stays the same—make a draft for lua scripting in my application.

Coding starts

2008-05-27T14:03:00.003+04:00

As I forgot make weekly reports during last month, here is my report of what’s done up to time.

First, I have a working development platform. I learned how to use git. And have needed libraries installed and working—CEGUI was updated to 0.6.0 in fedora repos by my request. And I’m also asking to include libwfut there. This would allow to include ember also. Probabily, I’ll have to become maintainer of those in order to it happen.

Regarding what’s done in scope of program. I’ve learned somewhat to work with CEGUI, OGRE and Atlas in things that are primarily needed for the project. Also created the skeleton application that doesn’t do much of real work yet but suitable for extending right now.

About my time. Last three weeks I had tests and exams. But starting next month I’ll have less dense schedule and will devote more time to project.

On this week I’ll have spare time closer to weekends. I have a choice do work on either widget or scripting part. I think that is better to start with lower scripting part. It is, populate adapters with some stub values and then call a Lua function that will return an Atlas object from which entity is could be created.

Started wiki page

2008-04-26T16:08:00.000+04:00

Started page to write generic project documentation: http://wiki.worldforge.org/wiki/Ember_Entity_Creator

Improving Mason game

2008-04-25T20:20:00.000+04:00

Here is very first variant of proposal that was changed to entity creator because of lack of mentor resources at that moment.

1. Add new simple tasks with proper gui that represent core things that player can do: open/close box, get/put items to the container, put one thing on another, push/pull, etc. This step will require to consider what tasks could could be done without physics engine and to think what more tasks will be useful.
2. Add more “construction” tasks: shape tree log, connect them together (with nails or just simply put one on another)... Here, if not available in Atlas, format of efficient storing and transmission (if house contains 12000 nails, than we probably shouldn't send them all to client) of composed objects with connection to finite number of existing 3D-models should be invented. At first, existing proposals like “Tiling models” in WF, and mechanisms of OGRE should be worked on.
3. Improve interaction with NPCs. Currently, in WorldForge, NPCs are very user-unfriendly. At least, in client some shop-interface should be done and on server their logic should be improved.

Accepted!

2008-04-22T14:59:00.003+04:00

Yay! Accepted! Posting here proposal of entity creator. It wasn’t so big from start—I’ve made many additions and corrections to it during application period.

I’m proposing to implement advanced entity creator in Ember client. It will consist of script functionality in entities and GUI that could be connected to properties and parameters. It will allow world authors to easier creation of new entities.
First part is script bindings. It introduce hooks (placeholders like $hook) to entity definition that are replaced with script output. It can be single (literal) value or atlas-tree represented by a lua object.
Second, it is an editor widget that has bindings between GUI adapters and script parameters controlled with a specific config. Also config defines bindings of script output to hooks or other scripts. Script input will also include whole entity atlas-tree.

To show how I envision its work, here is use cases:
1. Creation of single items (entities without minds). Some items can have many attributes and these attributes could have linked values (ex. mass/size/density) and some attributes are technical and could be set to constant or random values. For these objects proposed application will reduce overall number of properties that world author have to fill while creating.
2. Creation of NPC. Script can help to fill main part of mind (ex. to what neighbour NPC know). It can help to fill it's inventory. This will let author to concentrate on primary content – what NPC should do.
3. Creation of child objects at once with the parent. Examples: creating house with all contained objects, filling NPC inventory. First edition of editor would allow to create fixed set of contained objects returned from script. World editor that would allow to edit many objects at once with undo feature is out of scope of this program, I think.
4. Bringing variety to the game world. Some games (like Planeshift) have unpleasant look because they have completely identical objects like houses, people, items, etc. In current implementation it is possible to show or hide parts depending on parameters (like in mushroom model). Or may be some future feature will allow to vary texture/model.
Randomizing script could be added to parameters that are responsible for look of entity. This will add variety of created entities and save time for creating the world.
One more example is variation of contained objects when creating a house. This could be helpful when creating a village, for example.
5. Creation of big number almost identical entities. Currently it is possible to do it only with writing a python script. But with this tool it will be probably a bit easier. It can randomly distribute objects’ position, size and any other attributes. Example could be planting dark forest or making orcs army. As in 3^rd use case, it would allow to create only some scripted set of objects.
6. Enhanced GUI adapters. Entity Editor could include some adapters that are not just simple controls. It could be, for example, tool that selects point on map or (if server would allow) drawing panel.

In all this cases proposed tool is letting world authors to concentrate on creation, not technical details of it. Also implementing it will open the way to other authoring tools, like advanced entity editor and also it could be extended to be a user tool in cases where user is allowed to create new object or edit somehow existing one.

Approximated plan of work:
Each step is supposed to take about a week. I’m planning to start some work before May 26.
0-1. Learn the problem in depth. Study needed internals. Probably, code some concepts. Decide on format of semi-atlas specification. Decide on format of binding between properties and adapters/scripts. Document these in wiki.
2-3. Make parser of semi-atlas specification and bindings (reuse existing code). Make script bindings. At first, make only inserting of simple values as properties in place of hooks. Second, start to making insertion of whole objects/xml tree.
3-4. Make advanced entity creation widget. Start to making preview. Look how to do pointer-to-terrain ray tracing.
5. Make all this work together and fixing bugs…
6. --- Mid-term evaluations: present some working code.
7. Enhance scripting possibilities. Finish insertion of whole objects. Next, implement library of useful functions that could be used in scripts.
8-9. Make more advanced controls available as GUI adapters. Make pointer-to-terrain ray tracing. Make easy position of new entity and in-place preview.
10. Improve overall usability of entity creator. Fix bugs.
11. Make some real entities/models with scripts as examples.
12. --- The last week is to finish the work.