Menu

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.

Show posts Menu

Messages - llamazing

#151
Quote from: b0undarybreaker on August 05, 2017, 08:27:14 AM
I have two pickable items named card and gem and I want to be able to tell when they're picked up and make pointers over each item disappear. I'm using this script to do that:
Code (lua) Select
function map:on_update()
  if not map.card:exists() then
    cardpoint:remove()
    print("Card removed!")
  else if not map.gem:exists() then
    gempoint:remove()
    print("Gem removed!")
  end
  end
end

However, when I do that, it errors Error: In on_update: [string "maps/street_arspace.lua"]:79: attempt to index field 'card' (a nil value), line 79 being if not map.card:exists() then. Any suggestion for what I'm doing wrong?
It also for some reason doesn't work without that extra end there. I'm not sure what's up with that.

The reason for the two ends is because you did "else if" with a space on line 5. It should be "elseif" with no space.

Try this instead:
Code (lua) Select
function map:on_update()
  if map.card and not map.card:exists() then
    cardpoint:remove()
    print("Card removed!")
  elseif map.gem and not map.gem:exists() then
    gempoint:remove()
    print("Gem removed!")
  end
end
#152
Development / Re: Trouble porting a script
June 25, 2017, 10:05:02 PM
Do  you have a sample project available? It's a bit hard to troubleshoot from the forum.

Also double-check that I negated those if statements correctly.
#153
Development / Re: Trouble porting a script
June 25, 2017, 06:41:04 PM
There isn't an equivalent to next in lua, but you can accomplish the same thing using if statements. Take the two simplified examples (using lua syntax for illustration purposes)

Code ( lua) Select

for i = 1, #self.items do
    if index == i then
        next --not valid lua
    end
   
    print("not skipped")
end


Code ( lua) Select
--equivalent to the following
for i = 1, #self.items do
    if index ~= i then
        print("not skipped")
    end
end


So in your for block you could do the following in lua (note I have not tested it so there may be errors):
Code ( lua) Select
for i,item in ipairs(self.items) do
    local item_x = item.x
    local item_y = item.y
    local current_item_index = self:find_item(self:find_item_axis(self.cursor_position.x, self.cursor_position.y))
   
    --  Skip if it is the old item or is in the opposite direction
    if current_item_index ~= i and (command ~= "down" or item_y >= current_y) and (command ~= "left" or item_x <= current_x) and (command ~= "right" or item_x >= current_x) and (command ~= "up" or item_y <= current_y) then
        -- Get the distance of the current item and the new one
        local dist_h = math.abs(item_x - current_x)
        local dist_v = math.abs(item_y - current_y)
       
        if (wh ~= w1 or w2 * dist_h >= dist_v) and (wv ~= w1 or w2 * dist_v >= dist_h) then
            -- # Get the distance multiplied with their weightings
            local dist = (dist_h * wh + dist_v * wv)
       
            -- # Set at closest item if appropriate
            if (dist < closest_distance) then
                closest_distance = dist
                closest_index = i
            end
        else
            --equivalent to next, do nothing this iteration
        end
    else
        --equivalent to next, do nothing this iteration
    end
end


Also note that instead of doing
Code ( lua) Select
for i = 1, #self.items do
    local item = self.items[i]
    ...
end


it is better to use
Code ( lua) Select
for i,item in ipairs(self.items) do
    ...
end
#154
Quote from: wrightmat on June 04, 2017, 04:47:17 PM
Ok, I think I'm asking the wrong question. I can set the window size correctly with that call, but it basically scales the same viewport up or down to fit the window size. If I have a bigger window size, I want a bigger viewport as well- is this possible? For example, setting the window size at 320x240 works - but when I set the window to 640x480 instead, I want to see twice as many tiles not the same tiles at twice the size.

In the quest properties you'll want to specify a normal quest size and minimum quest size of 640x480 and at least 640x480 for maximum quest size. That will default to a window 2x the size you want (1280x960), but then you can set it to the correct size with sol.video.set_window_size(640, 480).
#155
Development / Re: Problem with timer
May 29, 2017, 10:41:33 PM
I think your problem is that you are using map:on_update(), which gets called every cycle. With the way you have things set up, a new timer is getting created every cycle as long as at least one torch is lit. Try adding a print statement at line 5, and you'll probably see a bunch of timers getting created. So what's happening is after 3.5 seconds the "first" timer expires and un-unlights all the torches, but then every cycle all the other timers continue to expire and also un-light all the torches. So then you have to wait another 3.5 seconds for the "last" timer to expire before you can light the torches again.

A better way to do it is to use sprite:on_animation_changed(animation) instead of map:on_update(). That way the function doesn't get called every cycle.

And if you are doing what I think you are doing, you'll probably want three separate timers. It can be done with one timer (that gets restarted each time a torch is lit perhaps?), but that would also mean that all the torches will become unlit simultaneously.
#156
In that case you simply make a function that takes a table for the first parameter:
Code (lua) Select
function test(info)
    if info.a == 5 then
        print("Letter A is",info.a)
    end
end

test{a=5, b="hey", c=true}


Keep in mind that the table passed to the function may not have values defined for every entry in the table. It also might not even be a table that gets passed to the function, so be sure your code handles all the possibilities.
#157
Development / Re: Script working part of the time
May 13, 2017, 03:03:56 AM
I'm not following the steps you are doing for the scenario where it does not work. You say that it works the first time, but it should only work once period. After one successful run, are you opening the console to set the value of open_walk back to false? And then you leave the map and come back?

It's not clear to me which lines of the script are working as expected and which are not. The script does everything correctly except for initiating the "girl.down_here" dialog? It may be helpful to add some debug print statements to see if any lines aren't executing (for example, does the movement finish and execute the callback function you defined?).
#158
Development / Re: On_interaction error?
May 09, 2017, 05:22:24 AM
how big is your custom entity if you do entity:get_size()?
#159
The equation you want to keep in mind is the following:
distance = rate * time -> rate = distance / time

So first calculate the distance to the hero from both cameras (find hypothenuse of right angle triangle made up of the delta x and delta y distances from camera to hero)

Code (lua) Select
local hero = {x=100, y=200}
local camera1 = {x=300, y=200}
local camera2 = {x=800, y=150}

local distance_1 = math.sqrt( (hero.x - camera1.x)^2 + (hero.y - camera1.y)^2 )
--> distance_1 = math.sqrt( (100 - 300)^2 + (200 - 200)^2 )
--> distance_1 = math.sqrt( -200^2 + 0^2)
--> distance_1 = 200 pixels

local distance_2 =  math.sqrt( (hero.x - camera2.x)^2 + (hero.y - camera2.y)^2 )
--> distance_2 = math.sqrt( (100 - 800)^2 + (200 - 150)^2 )
--> distance_2 = math.sqrt( -700^2 + 50^2 )
--> distance_2 = math.sqrt( 490000 + 2500)
--> distance_2 = 701.78 pixels


Then to find the speed of the camera (rate), simply divide the distance in pixels by time in seconds:

Code (lua) Select
local rate_1 = 200 / 2 --this is the camera_1 speed
--> rate_1 = 100 pixels per second

local rate_2 = 701.78 / 2 --this is the camera_2 speed
--> rate_2 = 350.89 pixels per second


Another way to think about it is that since the distance of the 2nd camera is 3.5x the distance of the first camera, the speed of the second camera should be 3.5 times the speed of the first camera.
#160
Development / Re: Bring hero back?
May 02, 2017, 12:02:58 AM
Could you cut off the tops of the bookshelves and draw the tops on a higher layer? That way the hero would naturally be behind them without having to change the layer of the hero.
#161
Development / Re: Trying to make an NPC disappear
April 30, 2017, 04:00:16 AM
To get the NPC to disappear when the map reloads, you should use the map:on_started() event.

I think you want something like this:
Code (lua) Select
function map:on_started(destination)
   if game:get_value("meeting_quest_1") then
      worker_npc:remove()
   end
end

function meeting_sensor:on_activated()
   if not game:get_value("meeting_quest_1") then
      game:start_dialog("meeting.1")
      hero:freeze()
      local path_movement = sol.movement.create("path")
      path_movement:set_path({ 2, 2, 2, 2, 2, 1, 1, 0, 0, 7, 7, 0, 0, 0, 0, 0, 0, 0, 7, 7, 0, 0, 0, 0, 0, 0, 0 })
      path_movement:set_ignore_obstacles(true)
      worker_npc:is_traversable()
      path_movement:set_speed(64)
      path_movement:start(worker_npc, function()
         worker_npc:remove()
         game:set_value("meeting_quest_1", true)
         hero:unfreeze() 
      end)
   end
end


you can probably delete line 1 as well because that doesn't look like it is doing anything.
#162
Development / Re: Trying to make an NPC dialog
April 27, 2017, 03:13:52 AM
If you have any other questions, just ask.

Have you seen Christopho's tutorials? They cover some very basic scripting.
https://www.youtube.com/playlist?list=PLzJ4jb-Y0ufxwkj7IlfURcvCxaDCSecJY
#163
Development / Re: Trying to make an NPC dialog
April 26, 2017, 04:48:20 AM
For line 21 on do this instead:
Code (lua) Select
-- Guy3
function Guy3:on_interaction()
  if has_sword and has_shield then
    game:start_dialog("Guy3.found")
  elseif has_sword and not has_shield then
    game:start_dialog("Guy3.has_sword")
  elseif has_shield and not has_sword then
    game:start_dialog("Guy3.has_shield")
  else
    game:start_dialog("Guy3.search")
  end
end
#164
Just curious, was anyone able to finish this quest (i.e. complete both objectives)?

I was intending to post some hints, but I don't see any way to do a spoiler tag on these forums (except perhaps making the font color the same color as the background). Any ideas?
Spoiler Test
#165
Development / Re: About color text dialogs
April 22, 2017, 04:58:49 AM
Quote from: MetalZelda on April 15, 2017, 02:06:03 PM
I also suggest adding a horizontal text alignment thing like $vertical{"center"}

An example more in-line with what I posted earlier would be something more like the following, using $a for horizontal alignment:
$a{center}centered text$a0

Although horizontal alignment is a tricky one because it doesn't really make sense to have more than one alignment style per line. Maybe alignment settings should be ignored unless specified at the beginning of a line/paragraph?

Also, horizontal alignment is very doable, but I'm not sure how vertical alignment would work, since isn't each line sized vertically to fit the text anyway? Maybe if you were using multiple font sizes on a single line? Or perhaps you mean to vertically align an entire paragraph of text relative to the text box?




Quote from: Diarandor on April 15, 2017, 05:22:30 PM
It would be very useful too to add a feature that manages the change of line of the dialog box if the max lenght of one line is given. I don't have time these days to work on this, though.

My Cythera dialog script does this.




Quote from: MetalZelda on April 16, 2017, 01:54:20 AM
There is still the spacing problem if you use a special characters such as é, è, ç, à and Asian type characters

My Cythera dialog script seemed to work just fine with the European accents. I didn't try Asian characters, but that would only be a problem if the characters exceeded the bounds specified by text_surface:get_size().




Quote from: MetalZelda on April 17, 2017, 02:08:28 PM
Also, another cool feature you could add to your dialogbox script is savegame value parsing.

In keeping with the other notation, I'd suggest $g for savegame variables, e.g.:
assignez l'arc grâce aux touches $c{red}$g{item_1}$c{white}
ou $c{red}$g{item_2}$c{white}.


Also, there's no reason the dialog has to be limited to only one instance of $v. I allowed multiple in my Cythera dialog script.




Quote from: Diarandor on April 17, 2017, 07:05:49 PM
What do you think would be better of these options for the dialog box script? (I mean, for a new script that I will make.)
Non-nested properties (as the ones you use)? Or nested ones (like the ones of the end of my last comment)?

I can't say I'm a fan of the nested notation. It would be burdensome with lots of different values in a single dialog and potentially confusing to translators.

Another advantage to using the non-nested notation is that it works better with dynamic text. For example, say the player is selling their items at an item shop. A dialog may be something like "You sold the Hero Shield for 15g", which could be coded like:
"You sold the $v for $c{yellow}$vg$c0"

Then you could have strings.dat entries defining item names like so:
text{ key="item_hero_shield", value="$c{green}Hero Shield$c0"}
text{ key="item_ice_rod", "value="$c{blue}Ice Rod$c0"}


In this example, different items have different colors, so the color to use is dynamic and depends on which item the player sells. Also note that the color gets defined by the strings.dat entry rather than the dialogs.dat text.

As for the functions calls idea, it could work with the shorthand notation, but the parsing full function names becomes much trickier and is error prone if the function name is typo'ed, for example.