Recent Posts

Pages: [1] 2 3 ... 10
Development / Re: Make 2nd hero un-attackable by 1st hero
« Last post by gzuk on September 24, 2022, 09:18:03 PM »
Thank you very much. I've checked out your additions, and the on_attacking_hero function works very well. If you define it on both heroes and leave it empty, then the heroes won't hurt each other any more, like for a coop game.

I'll play around some more with the multiple heroes, and make a new post when something else comes up.
Development / Re: Make 2nd hero un-attackable by 1st hero
« Last post by stdgregwar on September 21, 2022, 11:02:48 AM »
Hello !

You are right disabling friendly fire is a lacking feature. I added a way to do it in this merge request :

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 !

Development / Re: Make 2nd hero un-attackable by 1st hero
« Last post by gzuk on September 19, 2022, 08:57:48 PM »
I saw that you can call state:set_can_be_hurt on a state object. And in the parameter function you could probably check if the attacker is another hero, and then do nothing. But I'd have to set that on all the default states ("free", "running", "sword swinging" etc.), and I don't know where these states are created or stored. Does anyone know how I could get a handle on all the default states?
Development / Make 2nd hero un-attackable by 1st hero
« Last post by gzuk on September 15, 2022, 09:37:01 AM »
Hi, I tried out the new multiple heroes feature, but the default seems to be a player vs. player setup. The heroes hurt each other with their attacks, as in the "friendly fire" test map. For a coop quest, it would be nicer if you could also configure them to be immune to each other's attacks.

There are functions on the "enemy" type to configure attack reaction (set_attack_consequence), but these functions don't seem to exist on the "hero" type. In the CPP files, there are even more functions (is_sword_ignored), but it seems they have no Lua bindings.

Have I maybe overlooked an easy way to set this up? Or could it be implemented easily?
Development / Re: Have a 2nd hero move, attack and be attacked
« Last post by gzuk on September 14, 2022, 10:56:26 PM »
Ah, I got it working by registering "on_map_changed" for the game metatable. If added to main.lua on the current develop branch, the following script will on every entered map spawn a 2nd hero in blue next to the 1st one, controlled with the WASD keys. They both hurt and are hurt by enemies, and can coop-kill them together. Neat. There's still plenty of stuff to add, but I'll ask that in other posts.

A big thanks to all devs for the 2nd hero addition, and everything else!  :)

Code: [Select]
local game_meta = sol.main.get_metatable("game")
game_meta:register_event("on_map_changed", function()
  local map = sol.main.get_game():get_map()
  local hero1 = map:get_hero()
  -- Adjust controls for hero 1.
  hero1:get_controls():set_keyboard_binding("pause", "p")
  hero1:get_controls():set_keyboard_binding("attack", "right control")
  local x, y, layer = hero1:get_position()
  hero1:set_position(x + 8, y, layer)
  -- Create hero 2 next to hero 1, with WASD controls.
  local hero2 = map:create_hero({x = x - 8, y = y, layer = layer})
  hero2:get_controls():set_keyboard_binding("pause", "")
  hero2:get_controls():set_keyboard_binding("up", "w")
  hero2:get_controls():set_keyboard_binding("left", "a")
  hero2:get_controls():set_keyboard_binding("down", "s")
  hero2:get_controls():set_keyboard_binding("right", "d")
  hero2:get_controls():set_keyboard_binding("attack", "left alt")
  -- Give them swords and extra life for testing.
  hero1:set_ability("sword", 1)
  hero2:set_ability("sword", 1)
Zelda Mystery of Solarus XD / How can i save the game?!?
« Last post by zelda_chris on September 12, 2022, 09:26:13 PM »

How can i save the game with which buttons on the keyboard or on my Nintendo Pro Controller?

Please help!!

Development / Re: Have a 2nd hero move, attack and be attacked
« Last post by gzuk on September 12, 2022, 05:41:07 PM »
Thanks for the tips. But so far I'm still having trouble to even get the single-map usecase to work.

How or where would I override or append to game:on_started? Is there an example? I also found I need special behavior when starting each map or multimap area, for spawning the 2nd hero with the map functions. Is there maybe a way to override map:on_started for all maps?

When I tried to register "on_started" on sol.main.get_metatable("map"), it was never called. When I tried register "on_started" on sol.main.get_metatable("game"), the returned hero from create_hero was nil. That using the map metatable with "on_started" doesn't work has apparently been reported by other users. The reason may be that the map already has the function, and the docs say that the instance field always has priority. However, I haven't found any other hook in the map startup that I could use.

Code: [Select]
local game_meta = sol.main.get_metatable("game")
game_meta:register_event("on_started", function(game)
  local x, y, z = game:get_hero():get_position()
  local hero2 = game:get_map():create_hero {x = x, y = y, layer = z}
  print("This is called without error, but hero2 is nil here, and doesn't show: ", hero2)

local map_meta = sol.main.get_metatable("map")
map_meta:register_event("on_started", function()
  print("This is never called.")
Development / Re: Have a 2nd hero move, attack and be attacked
« Last post by stdgregwar on September 12, 2022, 02:53:17 PM »
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.


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.
Development / Re: Have a 2nd hero move, attack and be attacked
« Last post by gzuk on September 12, 2022, 02:33:43 PM »
Ah, thanks. hero2:get_controls():set_keyboard_binding("pause", "") (to empty string) did the trick to remove the "d" binding also for the 2nd hero. Interestingly, if you instead reassign "pause" to "p" for both heroes, then it breaks the pause, i.e. the game doesn't pause anymore. I'll have a look at the rest of the new controls API and try to remove all of the now obsolete entity code...

I'd be grateful if you could give me a suggestion as to where custom hero code belongs, if an entire game was to be written for 2 heroes coop. In the testing_quest, it's in the map code. Where should it go if it's used on all maps?
Development / Re: Have a 2nd hero move, attack and be attacked
« Last post by stdgregwar on September 12, 2022, 11:51:15 AM »
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 :

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 !


You can find the name of the methods of the "controls" objects here :

They work similar to the legacy methods of the game object.
Pages: [1] 2 3 ... 10