Recent Posts

Pages: 1 2 [3] 4 5 ... 10
21
Development / [RESOLU] Besoin d'aide pour le dialogue de début
« Last post by Delltus on December 07, 2017, 03:26:43 pm »
Bonjour j'ai un petit soucis que j'arrive pas à régler, je souhaiterais afficher un message via script mais une erreur apparaît qui est la suivante.
le script viens du projet "Zelda-Roth".

L'erreur en question:
https://gyazo.com/d0a91c3f9f4252c6adc769027aa9b671

Je pense savoir d'ou viens le problème après avoir chercher, mais j'arrive pas à le corriger, si je mais cette ligne en commentaire pas de message d'erreur.
Code: [Select]
game:start_dialog("link_house.zelda_message", function()
Avec le ligne en commentaire:
https://gyazo.com/fc13845fc51b371895c90fc3fdbbeb6e

Languages:
https://gyazo.com/048ff3a8168cfcbafd4613b7e69c1159

Voici le script de la map en question:
Code: [Select]
local map = ...
local game = map:get_game()

local night_overlay = sol.surface.create(map:get_size())
local alpha = 192
night_overlay:fill_color({0, 0, 64, alpha})

function map:on_started(destination)

  if destination ~= from_intro then
    night_overlay:clear()  -- No night.
    return
  end

  -- The intro scene is playing.
  -- Let the hero sleep for two second.
  game:set_pause_allowed(false)
  snores:get_sprite():set_ignore_suspend(true)
  bed:get_sprite():set_animation("hero_sleeping")
  hero:freeze()
  hero:set_visible(false)
  sol.timer.start(map, 2000, function()
    -- Show Zelda's message.
    game:start_dialog("link_house.zelda_message", function(answer)
    sol.timer.start(map, 1000, function()
        -- Wake up.
        snores:remove()
        bed:get_sprite():set_animation("hero_waking")
        sol.timer.start(map, 500, function()
          -- Jump from the bed.
          hero:set_visible(true)
          hero:start_jumping(0, 24, true)
          game:set_pause_allowed(true)
          game:set_hud_enabled(true)
          bed:get_sprite():set_animation("empty_open")
          sol.audio.play_sound("hero_lands")

          -- Start the savegame from outside the bed next time.
          game:set_starting_location(map:get_id(), "from_savegame")

          -- Make the sun rise.
          sol.timer.start(map, 20, function()
            alpha = alpha - 1
            if alpha <= 0 then
              alpha = 0
            end
            night_overlay:clear()
            night_overlay:fill_color({0, 0, 64, alpha})

            -- Continue the timer if there is still night.
            return alpha > 0
          end)

        end)
      end)
    end)
end

-- Show the night overlay.
function map:on_draw(dst_surface)

  night_overlay:draw(dst_surface)
end

Je vous remercie d'avance pour votre aide je débute en programmation lua et j'apprend à utiliser Solarus pour mon apprentissage en essayant de comprendre la mécanique des autres projet déjà crée  :).
22
Development / Re: NPC routines
« Last post by llamazing on December 07, 2017, 03:02:14 am »
I think there's still some insight that can be gained from my scripts. Really, the only key difference I'm seeing between my implementation and what you seek is to replace my hard-coded path movements with a script that does the path-finding dynamically.

Of course, that is by no means a trivial task. When I was doing the planning for how to implement my script, I was thinking it would be nice to be able to draw the paths for the NPCs to follow in the map editor. You could do the next best thing and place the waypoints on the map using invisible custom entities (for example, place a waypoint at every intersection along a path and at every relevant destination). Then you could make use of either a target movement or path finding movement instead of the path movement I used in my script.

This implementation still isn't a slam dunk because I'm assuming that you'd want to only have to specify the end destination and not all the intermediate waypoints on the route to get there, so you'd still need a script to find the ideal sequence of waypoints to traverse to get to the ultimate destination.

There are a few complications that you'll have to consider. One example is when the player enters a map, you'll need a script that will determine exactly where every NPC should be located on the map based on the time when the player entered the map. This can be tricky because the NPCs could be in the middle of their movements, so you will have to position the NPCs accordingly and then start a movement from their current location.

Another complication is the timing aspect. If an NPC takes too long getting to their destination, then the subsequent movement will either be delayed (a problem that can become compounded over time), or there will be discontinuities in the movement where the NPC instantly skips across a segment of the movement in order to catch up. In my case, having a precisely determined path helps mitigate this issue.

One thing you can do to help with this problem is to add slop by having the NPC wandering around randomly for a brief duration between movements. For example, if it takes 20 seconds for an NPC to move from point A to B, you could allocate 30 seconds before having the NPC move to point C, where the NPC wanders randomly in the vicinity of point B until the 30 seconds has elapsed. So then whether it takes 18 seconds or 24 seconds for the NPC to travel from A to B, it makes no difference because the NPC would be wondering randomly near point B for either 12 or 6 seconds according.

To go into more details about how I implemented my event tables...

I used a map based timer for my game clock ( timer starts on map:on_started() ). The advantage of linking the timer to the map is that the timer automatically gets paused whenever a dialog is displayed or the game is paused. The tricky part is transitioning the timer on changes of the map. What I did in on map:on_finished(), save the current time to the save data file and then kill the timer. Then when the next map loads, start a new timer from the time saved to the save data file. See game_clock.lua map_meta:register_event().


My initial thought was to "register" each NPC's routine when they're created on the map, then have a function that re-arranges this routine in order to place each NPC/waypoint into an hour table.

That is basically the implementation that I used. I have a static table of events for each NPC in my data/events directory. When a map loads (map:on_started()) the relevant table entries corresponding to the current map for any NPCs present are extracted and assembled into a new events_list table with the event start times as keys. (see game_events.lua game.events:load_map_events()). This is the table structure (keep in mind the table is generated dynamically, hard-coded here for clarity):
Code: Lua
  1. local events_list = {
  2.         ["8:00"] = {
  3.                 { --NPC_1
  4.                         npc_id = "NPC Name #1",
  5.                         location = {x=96, y=157, layer=0, facing=3},
  6.                         path = {4,4,4,2,2,2,2,2}, --hard-coded path
  7.                         target = "to_house", --you could do something like this instead, corresponding to a custom entity with this name
  8.                 },
  9.                 { --NPC_2
  10.                         npc_id = "NPC Name #2",
  11.                         location = {x=160, y=237, layer=1, facing=1},
  12.                         path = {1,2,3,4}, --hard-coded path
  13.                 },
  14.         },
  15.         ["8:23"] = {
  16.                 { --NPC_1
  17.                         npc_id = "NPC Name #1",
  18.                         location = {x=216, y=109, layer=1, facing=3},
  19.                         path = {2,2,2,2,2}, --hard-coded path
  20.                 },
  21.         },
  22.         ["9:00"] = {
  23.                 { --NPC_2
  24.                         npc_id = "NPC Name #2",
  25.                         location = {x=72, y=61, layer=1, facing=3},
  26.                         path = {6,6,8,8,2,2,4,4}, --hard-coded path
  27.                 },
  28.         },
  29. }
  30.  

Then every in-game minute the event manager script (see game_events.lua game.events:new_time(time_str)) can get a list of all the events that need to be started at the current time by calling events_list[current_time].
23
Game art & music / Re: A Free Music / SFX Resource - Over 1200 Tracks
« Last post by Eric Matyas on December 06, 2017, 11:16:55 pm »
I have more new free tracks ready for this week:

On the Fantasy 7 page:
"Kingdom of Darkness" (Looping and Standard)
http://soundimage.org/fantasy-7/

On the Horror/Surreal page:
"City of the Disturbed" (Looping and Standard)
http://soundimage.org/horrorsurreal/

On the Sci-Fi 6 page:
"Dystopian Wasteland" (Looping and Standard)
"Mysterious Anomaly"
"Sci-Fi Trance 2" (Looping)
"Sci-Fi Trance 3" (Looping)
http://soundimage.org/sci-fi-6/

I hope everyone's having a good week!  :-)
24
Development / Re: Moving the player around without taking away control
« Last post by Diarandor on December 06, 2017, 10:27:55 pm »
For a platform, easy way: use the event on_position_changed to find all movable entities over the platform and move them. Note that you need to check the entities in the rectangle corresponding to the bounding box but before the platform had moved. Use test_obstacles to know if entities can be moved. Check the ground position, instead of the usual position, to know if entities are over the platform (at least for the hero, or you will have problems).

For enemies pushing the hero you need something different.
25
Development / Moving the player around without taking away control
« Last post by Satoh on December 06, 2017, 08:41:55 pm »
So, I find a lot of circumstances where I need to push or pull the player around, but I don't want them to lose the ability to push and pull in return...

That is, objects that suck the player toward them or push them away, or platforms that move around, but the player can always move around in conjunction with this other applied force.

I know this CAN be done by calling hero:set_position(...) in a timer, but as I've been finding multiple reasons to need to do this, I'm starting to think I should at least ask if I'm doing it the hard way and there actually is some way to multiply force vectors together on an existing movement or something... yknow, just literally anything other than continually hardcoding the hero's X and Y positions, which I'm led to believe is somewhat going against the 'intent' of solarus' movement system.

(I noticed that if I call a timer at 0ms interval, and move the hero 1 px each time, it only equates to about 60 px/s, as a hero walking at speed 60 will basically stand still under that force, using my method... but 0ms and 1px SHOULD be a force >1000px/s... interestingly enough this force does drastically decrease when set to 1ms interval, such that a player moving at speed 60 can easily walk right through it. This is the other reason I want a different 'better' method. I can't control the 'speed' in a logical way using timers and set_position... it just doesn't behave the way it logically should, given that 1 pixel every millisecond equals 1000px/s, and the timer system only seems to go as high as 60px/s.)
26
Development / Re: NPC routines
« Last post by Satoh on December 06, 2017, 08:22:08 pm »
you'll probably need more than 24, since each NPC will have a different daily schedule.

Also, are you aware that a table can have a function as a member just like any variable?

if you define table[8] = function [...] end

then calling for the value of table[8] will execute that function.

if you really wanted to make this be a universal AI module, you're looking at a lot of scripts. Don't get me wrong, it's a great idea, but it will take some effort.

For example, you'll have to develop your own sort of scripting shorthand language to handle pathfinding, which is a script to itself.
You'd have to write a pathfinding algorithm for go_home, that doesn't know where home or any of its waypoints are, (because they're unique to each NPC) but instead must be fed a table of waypoints from its calling NPC. That NPC would have a table named go_home, possibly inside a bigger table of things including other entries like go_work, etc.

an NPC's schedule would likely be a table as well, defined as you did in the first post with [8]="go_work" and so forth.

You'll want all of the actual handling to be done in one file, so you don't have to copy all of it to each NPC, so...
What you could do, is write a file that reads "go_" instructions and uses a specific function for all of them, looking up the appropriately named tables inside the calling NPC ( schedule_table["go_work"] ) to find the list of waypoints the NPC needs to be pushed toward.

similarly you'd have a function that exclusively handled "do_" functions, for things like playing animations and such without moving.

This script would be called with a require at the top of each NPC who uses the schedule system, and you'd have a timer that calls the scheduler function every x milliseconds (the duration of one game hour) or something similar.

27
Bugs & Feature requests / Re: Improve gamepad support
« Last post by Christopho on December 06, 2017, 05:22:34 pm »
Don't worry about that, you can make a PR to the dev branch and if I want to put it in a new branch I can still do it.
28
Bugs & Feature requests / Re: Improve gamepad support
« Last post by duffy on December 06, 2017, 05:03:22 pm »
You are right about haptic rumble (I'm not sure about added/removed event but why not).
I will post here when it's done before a PR if there are some stuff that you want me to change and because it's maybe better to PR  this on a "joystick" branch (of course I can't create a branch).
29
Bugs & Feature requests / Re: Improve gamepad support
« Last post by darknior on December 06, 2017, 04:54:22 pm »
I love the idea of GENERIC joystick mapping :)
And the RUMBLE with x360 gamepad on PC or PI is really excellent to use <3
30
Bugs & Feature requests / Re: Improve gamepad support
« Last post by Christopho on December 06, 2017, 04:51:10 pm »
Looks great. It is annoying that we can't guess correct buttons automatically with the current solarus.
A pull request will be welcome :)

I think joystick added/removed events and a haptic rumble API are other subjects (new features) and should be developed in separate works later.
Pages: 1 2 [3] 4 5 ... 10