When the number of rooms increase it is increasingly difficult to debug a room.
It would be nice to have an option to start the game at any point of the code, or at least at any room without having to go through the real start process.
1 Like
i'm not sure if this will help / or if this is what you are talking about BUT, one thing i started doing as my game got bigger and i didn't want to go through the whole game just to test a room, i would place a temporary sprite somewhere in the room i was testing. i would interact with it and it would set the variables to what they would be if i HAD played the game up to that point -- in other words, instead of having to cross an entire continent to bring back a key, i'd just put the key next to the door.
of course you have to remember to get rid of those when you release the game!
I agree, but regarding workarounds:
Depending on whether you programmed an elaborate start, you can just plop your player sprite down in any room and start there.
You can also add a devmode. At the start of my game script, I have
If devmode=1 then
{Special start conditions, e.g. goto "room", exp=9001}
done
end
I then built a konami code devmode unlock into my player script which results in
on konamicode do
if devmode =0 then
devmode=1
else
devmode=0
end
store devmode
fin "devmode toggled"//*
end
*fin is necessary to actually save the stored variable; I actually add goto "room" just to be sure, but documentation says fin should work.
I can post the konamicode code if that's helpful, or you can reference the code in my project, which is opensource.
Of course, you dont need an actual konamicode, you can also just use a rare function that's not used in your game, like undock crank or flipping the device over (I havent tried that latter one yet). Then you woyld just replace "on konamicode do" with
on undock do
(Also can someone tell me how to post code in that slick way everyone else is using on here lol)
A devmode may be a good idea.
I am just creating exits in the first room but I need to change them all the time, this is time consuming and cumbersome.
I have also long dialogs in a single room and I would like to test them from some point and not each time from the beginning.... not sure how to do that yet even with a devmode.
Are you using a single long "say" statement? You might want to break that up. Otherwise whatever the condition/event is for the dialogue part just add that to the gamescript devmode conditional.
Re: breaking it up -
Try changing your "say" to this:
say "{dialogue1}" then
call "thisroomdialogue2"
end
end//this needs to be the end of the event for this to work
on thisroomdialogue2 do
say "{dialogue2}" then
call "thisroomdialogue3"
end
end
That way you can just add this to your gamescript:
on load do
if devmode==1 then
goto "thisroom"
call "thisroomdialogue2"
end
end
(If "thisroom" has any "on enter" events, make sure to add this at the beginning to stop them:
on enter do
if devmode==1 then
done
end
//...rest of "on enter" script like normal
end
Even for not so long dialogues I get such cumbersome code (picture).
I use
say "" then
wait 2 then
say "" then
put endless series of "end"s here
Your method is nice but it makes the code longer by creating an event for each dialogue... I think I should make a dialogue routine, accepting the name of the speaker, the position on the screen, the number of lines of the window and a delay to wait before or after, everything as a parameter. A thing you would do in a traditional programming language but not sure how to to this with pulp.
That's why you use events (if you sue this method). You dont get an endless series of "end"s.
Each event is just
on dialoguex
say "{x}"
wait y then
call dialogue{x+1}
end
end
It also has the benefit of being able to navigate within the script to each event by name using the shortcut up and right of the scripting box.
But yeah, quadruples the total length of the script for whatever you're working on.
If raw length is an issue you can also put each dialogue (or sections of dialogue) in a different tile and use
call dialoguex
on dialoguex do
mimic "dialoguextile"
end
All of these are just options. Sounds like you know what you're doing but hopefully the above is helpful for other people coming across this question.
Thank you! I haven't thought of using tiles. I will try that as well.
I would like to be able to have one line of code by string of dialogue... but for sure your method is still better than encapsulated "say"s.
I think you can also use string values. Like:
dialogue1="Hi my name is blarg\n Nice to meet you!"
...
...
...
say "{dialogue1}"
1 Like
seems like a good way to avoid codish mess while trying to be creative about the content of the dialogue! Thanks!
I think I found a way to combine the text strings and your event-based system.
I could create all my dialogues like
a1="dialogue 1"
a2="dialogue2"
then automate the creation of the following code in some editor like Vim or SublimeText (I would only need to duplicate and increment the numbers).
Of course it would be perfect for linear dialogue, but it could also be easily tweaked when using ASKs, creating branches starting like B1,C1,D1 etc... I'll probably try this☆
1 Like
This just inspired a solution for my own debug problem:
When I'm tracking a variable that isn't calculating right (like an x coordinate that is not drawing where I expect), I currently have to write "log " x variable={x variable}" all over the script.
From now on I'll just have one event called Debug that says
on debug do
debugvar=xvariable
log "debugvar ={debugvar}"
end
Then add this to any spots I want to check:
tell Debug to
call "debug"
end
That will actually save me tons of time and clean up my code. Thanks!
1 Like
Following the same idea, I guess I could have a tile(or an even in the player script?) called "dialog" with an event called "display" which would use the variable txt and I could display a say message everytime with the same code I could just copy and paste 
(verbose but easy to maintain, and no need to have a ton of events or variables)
txt = "dialog to display"
tell dialog to
call display
end
I could make the event use the variables txt_x, txt_y, txt_w, txt_h , waitbefore, waitafter
when they are not empty to apply some customization when needed.
※just an idea, not sure it works... but if it works I think It may be the simplest way to do what I am looking for.
It doesn't work because pulp does not stops at the say statement and continue executing the code...
But putting the event in the game script and calling with
tell event.game to
call "dialog"
end
is a smart way to do a lot of things. I will try to find if I can make it work for dialogue though (managing to find a way to "wait for a keypress" before continuing anything else)
Oh! Sorry for the numerous posts with just partial answers!
I finally found a workaround for making long dialogs displaying with minimum code.
This is ugly but you only need to write it once in your room or in the game script.
Here is a working example of how it is written in the same room(change it to a tell event.game call if you write it in the game script)
on enter do
txt1="test1"
txt2="test2"
txt3="test3"
maxtext=3
call "dialogueloop"
endon dialogueloop do
if endoftext<maxtext then
endoftext+=1
displaytext="txt{endoftext}"
say "{displaytext}" then
call "dialoguesubloop"
end
else
done
endend
on dialoguesubloop do
if endoftext<maxtext then
endoftext+=1
displaytext="txt{endoftext}"
say "{displaytext}" then
call "dialogueloop"
end
else
done
end
end
To explain the idea, PULP only stops the execution at the end of events, so you need 2 events calling each other in a loop to get the "waiting for keypress" effect!
Yeah, that's the issue with wait. If you use "say...then" it will wait for confirmation...but only for whatever is between "then" and "end."
You can work around this by using event calls as discussed above, but things start getting complicated when you start mixing in functions.
Normally you would add "then call "dialogue2"" to the say event in the dislogue tile, but you don't want dialoguetile to call the event, you want the original tile to call the event. There is a super hacky way to do that: if the dialogue tile is not placed anywhere, it takes the last event.x, event.y that was available, in this case the original tile (this is undocumented, maybe a glitch, but I'm pretty sure this works based on testing).
So you could make the dialoguetile script:
Wait a then
say "txt" then
wait b then
tell event.x, event.y to call "{nexttext}"
end
end
end
and change your original script to
a=
b=
nexttext=[next event name]
tell dialogue to
call "display"
end//(must be end of event)
I think this works, but you can cut out a step and just have dialogueloop call itself.
I used a self-looping function with a wait timer like you described to make the "ding" sounds space out when your score gets updated point-by-point in Playcee's Mod.
1 Like
Wow, making the event call itself works!!! You saved my day (and a couple of others)
Excellent!
I think I could use this kind of self calling events a lot to simulate traditional functions!
And here is the final code
▼ To put in your room
on enter do
textindex = 0
t1 = "test1"
t2 = "test2"
t3 = "test3"
maxtext = 3
tell event.game to
call "dialogue"
end
end
▼ To put in your game script
on dialogue do
if textindex<maxtext then
textindex += 1
displaytext = t{textindex}
say "{displaytext}" then
call "dialogue"
end
else
done
end
end
Oh sorry it doesn't work...
the expression
displaytext = t{textindex}
won't get the value of the variable t1 into the variable displaytext 