Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - stdgregwar

Pages: [1] 2
Bugs & Feature requests / Re: Android crash
« on: April 18, 2019, 09:17:37 am »
Hi Karl,

Sorry to be rough about the git thing.
While your contribution is appreciated. Could you please put your patch in a code block ?
Also, I had in mind to have virtual buttons not triggering key events but SDL Joypad events. So that
Quests can view the android touch controls as a Joypad.

If you are willing to contribute we are really open to accept merge requests as long as the code
respects the style of the rest of the code base. Since you were able to hack this example so quickly,
consider contributing if you have the time.


Bugs & Feature requests / Re: Android crash
« on: April 15, 2019, 11:36:21 am »
For compilation, after a checkout of solarus-android and solarus, solarus has to be copied or linked to solarus-android/app/jni/solarus .
   ( this should be in the readme or ).

you simply forgot to checkout with --recursive option to fetch the solarus repository that is registered as a git submodule. This would have pointed you to
the right solarus commit in which the two other problems you had would not have existed.

I agree the --recursive option should be stated in the options tough.


Your projects / Re: Ocean's Heart Beta Testing
« on: April 14, 2019, 08:56:06 pm »
Hi Max,

Congratulations for reaching so far in the development of your game.
I'm interested in testing it. I can't promess to go through all of it but I
surely can give it a shot.

Looking forward to it!


Development / Re: Building Solarus on the Gameshell
« on: February 28, 2019, 02:47:53 pm »
Hi Dowdheur,

Those separate blendmodes attempt to fix bugs when compositing semi-transparent surfaces on-top of another (with premultiplied alpha).
By reverting this code to "simple" blendmodes you might experience some graphical inaccuracies. But solarus had those for a long time so it will already be a really enjoyable experience.

Also note that as long as you manage to launch the engine with the opengl (GL ES in your case) backend. The SDL graphic code is not used and you will get the full working transparency stuff.

Anyway, thank you very much to put effort into spreading solarus engine a lovely open-source platform. We love it !


Bugs & Feature requests / Re: Android crash
« on: February 24, 2019, 09:23:15 am »

You must probably have found the old hacky android port of Solarus DX which is not done by us.
A new android player for solarus quests is in preparation. This will not be an app generator but a .solarus files player.

But the team is busy with other business for now. I don't really know when this android port will be ready. If you are interested it's  on gitlab :

I would be happy to receive feedback on this one instead.



Bugs & Feature requests / Re: Cutscene builder bug
« on: February 20, 2019, 05:28:46 pm »
EDIT: Btw, can the coroutine helper be expanded to have more features, such as freezing or unfreezing the hero, or having the camera move to a certain location on the map? Plus, does this script only work on Solarus 1.6?

Coroutine helper works very differently of cutscene builder. Whereas in cutscene_builder the only actions you could do were things allowed by the script, in coroutines you can call any engine function during the cutscene as long as they do not require waiting. (hero:freeze() for example). For the engine features that take a callback you can use wait_for to suspend the coroutine until the callback is called. I hope this is clear. If you need more help you can ask questions on the discord server.

Happy Making!

Bugs & Feature requests / Re: Cutscene builder bug
« on: February 20, 2019, 02:11:27 pm »
Hi boaromayo,

Glad to see you found some use for this old little helper. Where did you found it ? On the forum ?

The fact is that it is no more maintained because Solarus 1.6 can use coroutines to express this kind of asynchronous behaviour.
So yes this could be a bug... but it won't be fixed as  far as i'm concerned.

The new way to write cutscenes (among other things) easily is to use `coroutine_helper.lua` from the free-resource-pack. (

This will allow you to write cutscene even more easily.


Development / Re: Lua promises
« on: December 04, 2018, 12:13:03 am »
Nice, you can take a look at the changelog.txt in the solarus repo if you are interested in the new features of Solarus 1.6. Like shaders, sprite rotations , scale and more.

Development / Re: Lua promises
« on: December 03, 2018, 11:06:37 pm »
Dear Alexgleason,

I was also not satisfied with the look of the code when doing cinematics. And lua is not very famous for the syntax of its promises (the reserved keyword then is iritatingly unavailable). So I saw that lua had a coroutine system. That's why we upgraded solarus to support coroutines and developped an helper that allow to write cutscenes and all kind of asynchronous code without nesting callbacks.

Example :
Code: [Select]
    local options = {
      entities_ignore_suspend = {dungeon_1_entrance}
    map:set_cinematic_mode(true, options)
    local camera = map:get_camera()
    local camera_x, camera_y = camera:get_position()
    local movement1 = sol.movement.create("straight")
    movement1:set_angle(math.pi / 2)
    movement(movement1, camera)
    local shake_config = {
        count = 32,
        amplitude = 4,
        speed = 90
    camera:set_position(camera_x, camera_y - 72)
    animation(dungeon_1_entrance:get_sprite(), "opening")
    local movement2 = sol.movement.create("straight")
    movement2:set_angle(3 * math.pi / 2)
    movement(movement2, camera)
    map:set_cinematic_mode(false, options)
    game:set_value("main_quest_step", 7)

The functions movement, wait, wait_for , animation and others are injected into the execution environment of your unique callback (it has to start somewhere) which is tranformed into a lua coroutine that execute asynchronously.

I can't remember if you are developping your game on solarus-dev or the 1.5.3. But if your game's release is planned for 2019 or beyond you can develop it on the solarus 1.6 dev branch which is coroutine enabled. And we'll be happy to provide the coroutine_helper script and getting started.



I plan to adress your Joystick issue but it will be in 1.7 that will be released only god knows when... sorry.

Development / Re: Will reflections be possible in 1.6
« on: November 12, 2018, 05:49:50 pm »
Hi Starlock,

Yes it will be possible.  8)

Basically, pretty much any effect that you could do, say on GIMP, will be doable with the shader system.  :D


Development / Re: Has anyone tried compiling Solarus for the web?
« on: November 04, 2018, 09:41:42 am »
Hello AlexGleason,

I looked at emscripten a lot of time and finally choosed to do the android port first.

The difficulty is the fairly high amount of solarus dependencies that need to be met. The second problem is that solarus uses some secondary threads to do some work like music playback and background loading. And emscripten does not support multithreading well... (nor does EScript).

I'm also really looking forward to it but it's not as simple as
Code: [Select]
CXX=emscripten make. But there huge probability that this will be done next year or in few months... When I or another team member finds the time.


Your scripts / Re: [Big Layer] Solarus-online
« on: April 24, 2018, 10:40:16 am »
Wow, I haven't been on here for a while so I've only just seen this...this is amazing! I haven't tested it or anything but it started my imagination going crazy with new types of quest that can be modes and types of gameplay....

can the users interact with eachother? so that you could make something like...zelda bomberman for example? or a battle arena? Not what I intend to use it for, just wondered.

Hi ponderitus,

Yes the users can interact with each other. The library will be cleaned for the release of Solarus 1.6 and proper documentation/tutorials/demo will be made.

No release date is scheduled for 1.6 tough, so stay tuned!


Your scripts / Re: [Big Layer] Solarus-online
« on: January 21, 2018, 02:15:37 am »
A small remark: LuaJIT is needed because of ffi stuff in Vector.lua. I don't know if you were aware of that but it might be a limitation on some systems. It should be mentioned in the readme if this is normal.

Yes i knew this... and in fact this is not needed... that's a bit silly from me, I took this vector class from another project and forgot that it was LuaJiT only. I will certainly revert it to a plain lua version.

Anyway… this is a big step for Solarus :D

Glad that you take it this way! ;D

Oh wow so lan multiplayer is now a thing

Not only lan actually, it works quite well across the internet. There is still solutions to be found to smooth the movements when ping increase but this is not a priority.

This is awesomly awesome!!!  ;D


What excites me the most is the new ways that it opens in terms of crazy puzzles and quests. Running through dungeons with a squad of 4-8 players, with epic boss fights at the end.

Your scripts / [Big Layer] Solarus-online
« on: January 20, 2018, 04:50:20 pm »
Hello everyone!

As I promised to Christopho and others during his live on Monday. I'm unveiling my work of the few past months: Solarus-online.  8)

Demo footage :

This is basically a set of lua scripts that uses luasocket and a small server to synchronise clients across the network.


  • server
  • fully working 'async' networking
  • asymetric mob simulation
  • symetric map,object simulation
  • movement replication primitives
  • api adaptation for multiplayer aware ennemies
  • network synchronised states and actions

In practice the following engine entities are synchronisable :

  • hero
  • ennemies
  • npcs
  • destructibles
  • maps

But this require light to heavy modifications in the enemy,map,object code!

Code is not bigger, thank to a reconstruction of an api similar to solarus one. But it's different.


A small demo serve as template on my github:

You can launch it as any solarus quest, provided that you have 'luasocket' and 'luajson' in your lua5.1 path. and Solarus 1.6 (dev version)

The save selection screen serve as a server selection screen. You can edit data/scripts/serverlist.lua to replace the three default servers.

There is more details in the readme.

Demo server opened h24 for a while

A demo server is open from know on at, the server is already in the provided serverlist.

I strongly encourage you to test this on this server. As it is not very demonstrative if there is no other one on screen.

It is also more fun if you use a proper pseudo (not like on the screen  ::) ).

Be aware the server might crash, after all this is an alpha and I never tested all of this with more than two clients, so it's probable that everything breaks. If
this is the case, put a message here or ping me on github.

I might post some video footage in a week or so


If enough people are interested in this I could make a tutorial on how to use it. Or at least develop a nice wiki to explain what it implies in terms of code.


There is still plenty to do to really make this usable. The movement replication part is still in a very early stage and suffer when ping is too high.

Please contact me if you want to contribute.


You can ask me anything about the way this works and what are the limitations. As well as proposing any improvement, ideas.


I don't know if this is really the multiplayer mode that everyone was waiting for. But it's a light solution in terms of engine modification (2 pull-request) and
can be extended to make anything.

Development / Re: Custom movement. Way to go?
« on: February 01, 2017, 01:03:07 pm »
Hello Again,

I managed to find that the 'target' movement was perfectly suited for this.

I still have a problem with the animations of the npcs. They don't switch well from 'stopped' to 'walking'.

Here is the full entity script, it is already usable and could easily be modified to create enemy crowds.

Code: [Select]
-- Lua script of custom entity npc_crowd.
-- This script is executed every time a custom entity with this model is created.

--Emulate a crowd of npc following a random path
--Avoiding themselves and the hero

local entity = ...

local Vector = require("scripts/Vector")
local random = math.random

local game = entity:get_game()
local map = entity:get_map()
local hero = map:get_hero()

--physics constants
local dt = 1.0/60
local rep = 9000
local coh = 3
local mrep = 16000
local hrep = 128000

--all npcs of the crowd
local ents = {}

-- Event called when the custom entity is initialized.
function entity:on_created()

  -- Initialize the properties of your custom entity here,
  -- like the sprite, the size, and whether it can traverse other
  -- entities and be traversed by them.

  local sx,sy = entity:get_size()
  --entity count based on custom entity size if not provided
  local n = entity.mob_count or (sx*sy)/64 

  --take default sprites if not given
  local sprites = entity.sprites or {"npc/villager1","npc/villager2","npc/villager3"}

  --set phantom mode to crowd 'core'

  --params of the generated npcs
  local w, h = 8,8
  local x, y,layer = entity:get_position()
  local sq = math.ceil(math.sqrt(n))

  for i=1,n do
    local ex = x+(i%sq)*w
    local ey = y+(i/sq)*h
    local ent = map:create_npc({
      name = "crowd" .. i,
      layer = layer,
      x = ex,
      y = ey,
      sprite= sprites[random(1,#sprites)],
      model = "extended_npc"
    local pos = Vector(ex,ey)
    local mov = sol.movement.create("target")
    ents[i] = { --crowd character table
      ent = ent,
      pos = pos,
      mov = mov,
      f =,0)

  --set random movement to crowd core
  local mov = sol.movement.create("random_path")

function entity:on_pre_draw()
  local epos = Vector(entity:get_position())
  local hpos = Vector(hero:get_position())

  --compute all forces
  for i,ent in ipairs(ents) do
    ent.f = Vector(0,0)
    --reset position to effective position
    ent.pos = Vector(ent.ent:get_position())
    --compute pairs repulsive forces
    for j,ont in ipairs(ents) do
      local r = ent.pos - ont.pos
      if r:lenSq() > 0.00001 then --if force not huge
        ent.f = ent.f + rep * (1/r:lenSq()) * r:normalized()
    local re = ent.pos - epos
    local rh = ent.pos - hpos
    --cohesive force (to the center of crowd)
    ent.f = ent.f - coh * re
    --repulsion from crowd center
    ent.f = ent.f + mrep * (1/re:lenSq()) * re:normalized()
    --repulsion from the hero
    ent.f = ent.f + hrep * (1/rh:lenSq()) * rh:normalized()
    --speed damping
    ent.f = ent.f - 1*ent.speed

  for i,ent in ipairs(ents) do
    --integrate forces
    ent.speed = ent.speed + dt*ent.f
    ent.pos = ent.pos + dt*ent.speed
    --update target movement

The simulation could be optimized by updating the pairs forces at a smaller rate with a timer. But this already works for small crowds of like 40 npcs.


Pages: [1] 2