Messages

Hello !

You are right disabling friendly fire is a lacking feature. I added a way to do it in this merge request : https://gitlab.com/solarus-games/solarus/-/merge_requests/1421

It adds the `on_attacking_hero` event that can be used to short circuit the default behavior and decide what to do. To disable the friendly fire quest-wide you can add the event to the hero's metatable.

Thank you for testing the multiplayer features !

I think that in the case where the whole game is coop, you want the code spawning and setting up the new hero in something like game:on_started or another function that gets called early when game is reloaded.

Pay attention to the fact that other heroes than the default one do not get their inventory/equipement saved automatically by the engine. It is up to you to decide how additional heroes equipement is setted up from custom variables or replication of the default hero stuff. Up to you. It is also true for getting items from chest. The items giving  abilities to heroes should check which hero opened them and/or give ability to everyone. It is up to the quest maker to make this work, engine cannot assume a default behaviour here I guess.

EDIT :

You also need to handle map transition kind of yourself in this case. If you have a single camera and multiple heroes you need to teleport the heroes without cam when changing map. If you were to do map transitions like in four swords, for example, you would need to have a custom entity for side transition that waits for all hero to push on the edge of the map before teletransporting everyone. Engines only gives building blocks for multiplayer and the rest is still up to you.

Hi !

The multiple heroes stuff comes with multiple control sets features as well.
This means that  the game:set_command_keyboard_binding only affects the default key bindings but there are now more of them. When you create the second hero it comes with his own set of controls that you can get and modify with hero:get_controls() as you can see here : https://gitlab.com/solarus-games/solarus/-/blob/dev/tests/testing_quest/data/maps/multiplayer/heroes.lua#L87

I guess that what is happening is that the D key is default mapping for the fresh controls of the second hero. So you must get them and change them.

Of course once your second hero is a real hero. Most of the control script you have here is kind of obsolete. Just settings the key bindings for the second hero controls will grant you the exact same moving scheme without having to manually do the direction / animations. On top of that the second hero will be able to take teletransporter if he has a camera attached.

Feel free to ask more questions. It is a shame that documentation can't be published (because it was written) but we have a doc rewrite pending for to many years now...

Have fun with your multiplayer tests !

Greg

EDIT:
You can find the name of the methods of the "controls" objects here :
https://gitlab.com/solarus-games/solarus/-/blob/dev/src/lua/ControlsApi.cpp#L29

They work similar to the legacy methods of the game object.

Hello !
Wait... I don't get it... Because you are bad at coding, you will code the solarus games from scratch on 3DS instead of "just" porting the engine ? 
Greg

A very late thank you to you 20degree.

This is a very usefull feedback.

Sorry to not have answered sooner.

Greg

There is a cross-compiler that can generate WebAssembly or JS from C/C++ :

https://en.wikipedia.org/wiki/Emscripten

If someone motivated manage to compile libsolarus with this (the problem lies in the dependencies) then it is just a matter of 20 lines of JS and html.

I have myself no time to tackle this this semester but I wanted to do this at some point.

Greg

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.

Greg

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 readme.md ).

No,
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.

Greg

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!

Greg

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 !

Greg.

Hi,

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 :
https://gitlab.com/solarus-games/solarus-android

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

Thanks

greg

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!

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. (https://gitlab.com/solarus-games/solarus-free-resource-pack/blob/dev/data/scripts/coroutine_helper.lua)

This will allow you to write cutscene even more easily.

Best

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.

[then]

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 Expand


map:start_coroutine(function()
    local options = {
      entities_ignore_suspend = {dungeon_1_entrance}
    }
    map:set_cinematic_mode(true, options)
    sol.audio.stop_music()
    audio_manager:play_sound("others/chest_open")
    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)
    movement1:set_max_distance(72)
    movement1:set_speed(75)
    movement1:set_ignore_suspend(true)
    movement(movement1, camera)
    wait(1000)
    local shake_config = {
        count = 32,
        amplitude = 4,
        speed = 90
    }
    wait_for(camera.shake,camera,shake_config)
    camera:start_manual()
    camera:set_position(camera_x, camera_y - 72)
    audio_manager:play_sound("others/secret2")
    animation(dungeon_1_entrance:get_sprite(), "opening")
    map:open_dungeon_1()
    local movement2 = sol.movement.create("straight")
    movement2:set_angle(3 * math.pi / 2)
    movement2:set_max_distance(72)
    movement2:set_speed(75)
    movement2:set_ignore_suspend(true)
    movement(movement2, camera)
    map:set_cinematic_mode(false, options)
    camera:start_tracking(hero)
    game:set_value("main_quest_step", 7)
    map:init_music()
  end)


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.

Greg

PS:

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