Testing: A cheatsheet of handy tips and tricks

Test reports, test guides, etc.
Post Reply
User avatar
TheChimpken
Froob
Posts: 59
Joined: Tue Dec 27, 2022 7:59 pm
Has thanked: 30 times
Been thanked: 29 times

Testing: A cheatsheet of handy tips and tricks

Post by TheChimpken »

A handy guide on commands contributors can use:

Firstly, ::debug gives you Item IDs, Scenery IDs, NPC IDs. All incredibly useful information for both testing and reporting bugs!
This command can be used by anyone on the Live or Testing Server.

Any commands as below require at least Admin status. (Gold Crown)

Movement
CTRL-SHIFT-Click is your friend - Instant teleportation. Works on the world map and on the local map.
This command won't work travelling up or down elevation levels - Careful not to get your character stuck.

Otherwise, here are some commands you might find useful for quickly navigating the Test Server:
::to <city/placename> gets you standard teleports. More info is in the code in ServerConstants.TELEPORT_DESTINATIONS - Link: https://gitlab.com/2009scape/2009scape/ ... ts.kt#L164
::tostar gets you to the last fallen star
::teleto <playername> gets you to the location of another player
::tele <X> <Y> <Z> teleports to a given location.
You can make use of older, Jagex-style coords with ::tele, too, using the following extra vars, which I'll post below.
Obtaining Items
::item <ID> <Amount> To give yourself Items
::giveitem <player> <ID> <Amount> To give someone else items! Works on yourself, too.
::itemsearch <name> Search for an Item ID
::empty to nuke the contents of your inventory.
::bank to access the bank at any time, ::fillbank , and ::emptybank is useful to test banking related issues.
::rolldrops <NPC.ID> <Kills> Tests what rolls you'd get given you killed a given NPC.ID the given amount of times.

How do I quickly get Item IDs?
Use the Thanos Tool! https://gitlab.com/2009scape/tools/rs09-thanos-tool! Or use the ::itemsearch <name> command.
Loading the Item Configs gives you a VERY easy way to search for any ItemID you want. (Requires a fork + local dev envrionment: https://gitlab.com/2009scape/2009scape/ ... ng-started for more info)
Obtaining NPCs?
::npc <ID> Spawn a given NPC underneath your PC (On the same tile as you).
::npcsearch <name> Search for an NPC ID / Children NPCs
Combat
::god for invincibility
::1hit for one-hit kills
::spellbook <0,1,2> to quickly change spellbooks
::infinitespecial as it says on the tin.
::forcegravedeath forces a death that creates a grave
::killme Kills your PC instantly.
Levels
::max for max levels,
::noobme to reverse, starting you at lv1 for all.
::setlevel <skillname> <level> sets a particular skill level for a skill you choose
Random Events
::targeted-ame <player> for random events, targeted at whomever you'd like
::revent for a quick way to spawn a random event at yourself.
Diaries
::completediaries to finish diaries
::cleardiary to reset
Quests
::allquest completes all quests
::quest gives you a list of quests and their relevant IDs.
::setqueststage <ID> <Stage> allows you to set a quest to a specific point. (To find out what stage is what, you may need to review the code you're testing)
Other skill based commands:

Slayer-Related
::setslayerpoints <#> Gives you # number of slayer points.
::finishtask Finishes your current slayer task.

Farming-Related
::grow Adds another growth tick to all plants that you own
::farmkit gives you a full set of farming tools
::finishbins Instantly completes compost bins

Job Task Related (Pending successful merge of this Merge Request)
::clearjob - Clears your current job task.
Last edited by TheChimpken on Wed Mar 01, 2023 1:51 am, edited 7 times in total.
User avatar
TheChimpken
Froob
Posts: 59
Joined: Tue Dec 27, 2022 7:59 pm
Has thanked: 30 times
Been thanked: 29 times

Re: Testing: A cheatsheet of handy tips and tricks

Post by TheChimpken »

Getting around: Expanded

It's all well and good that I have four different options to get around, but what about the one that's historically accurate and very specific?

Well, you can use the Runescript co-ordinates instead!

The way to understand this (As far as I've discovered/been told so far) is that the Runescape map is divided up into regions. Each region is 63x63 tiles.
This explains the loading screen you get when you are moving between areas.

As an example, Lumbridge Castle is in Region 12850. You might ask - How do I know this?

Well, you multiply the X and Y values of the region's location. You can get these values using the handy Dev Tools Ciekry has provided here: Link to Forums: Dev Tools

When you look at the historic map here, you get the following co-ordinates:
Image

Still with me? Good.

Now we translate this to a command:
::tele 50_50

This takes us right to the middle of regionID 12850.

We can be more specific about this by using:
::tele 50_50_22_18

This command takes us right to the specific tile highlighted on the above map.

And that's all there is to Runescript Teleporting for Testing!
User avatar
TheChimpken
Froob
Posts: 59
Joined: Tue Dec 27, 2022 7:59 pm
Has thanked: 30 times
Been thanked: 29 times

Re: Testing: A cheatsheet of handy tips and tricks

Post by TheChimpken »

That's all well and good, but how do I test?

The keystone of what's done here is authenticity. Give me (ideally) precisely how RS was in 2009, warts and all.

With that in mind, I take the following approach:
  • Work out what the "Happy Path is. What actions do we expect the player should take?
  • Once you've done that, try to stray from the "happy path". As a player, if I forget details, destroy quest items, or generally try to do things badly, what things would we would want to catch, and error on, or ignore?
  • Pay attention to the finer details - Is the quest journal doing the right thing? What happens when you deliberately try to make something with invalid ingredients?
  • Write stuff down - Anything that doesn't seem right, jot it down when you give your test report.
Note: When testing plugin to Listener conversions: Check the code for Diary Achievement! If it's present, be sure to include this in your testing scope. If you're unsure, reach out to the person who created the MR to confirm.

Once you've got your list, chuck it in to a Gitlab Merge Request. Give a determination up front - Would the changes be ready for the main server if you wanted to use that functionality on a character you've worked hard on?

Either way, go through your list and describe in plain language what's going wrong, and why.

Make your comment, and go claim your Credits in the General section of the Forums.
More information on Credits and the shop here: 2009Scape - Credits

Thanks for testing and for reading!
Last edited by TheChimpken on Fri Feb 10, 2023 12:29 am, edited 2 times in total.
User avatar
TheChimpken
Froob
Posts: 59
Joined: Tue Dec 27, 2022 7:59 pm
Has thanked: 30 times
Been thanked: 29 times

Re: Testing: A cheatsheet of handy tips and tricks

Post by TheChimpken »

How do I take a video of my screen for testing?

OBS (https://obsproject.com/) is a great open-source product that can be used for this purpose. It takes a little setup, but makes recording easy.

Follow the Quick Start Guide on their website. Don't worry too much about setting up the Audio, unless what you're testing is audio-related.

When you're done recording, select File > Show Recordings. From there, upload to an unlisted video on your youtube channel, or alternatively upload direct to GitLab, given the video is small enough.
User avatar
TheChimpken
Froob
Posts: 59
Joined: Tue Dec 27, 2022 7:59 pm
Has thanked: 30 times
Been thanked: 29 times

Re: Testing: A cheatsheet of handy tips and tricks

Post by TheChimpken »

How do I check out someone else's stale branch to help move it forward?

Communication is key - To avoid hurt feelings, hit up the person who's Merge Request it is to ensure you're not stepping on toes, doubly so for large pieces of content (Quests, Minigames, etc).
Given that you've got the go-ahead to proceed, the follow guide should help:

Set up your Git Config to check out any commit, from any fork: A short guide (Thanks ryannathans for guiding me thorugh this!)

Edit your /.git/config file, and add the following under what ever you've named your upstream (in this case, I named mine upstream)

Code: Select all

[remote "upstream"]                                                                                                                                                                                                                                                                                                 
        url = https://gitlab.com/2009scape/2009scape        
        fetch = +refs/heads/*:refs/remotes/upstream/*                                                                                                                                                                                                                                                        
        fetch = +refs/merge-requests/*/head:refs/remotes/upstream/merge-requests/*
Once complete, run the following:

Code: Select all

git fetch -ap <upstream name>
You should have a ton of pull requests coming in.

Now to check out the merge request you need, and make your own branch based off of that (you can't commit to someone elses branch)

Code: Select all

git checkout upstream/merge-requests/<mr-number> -b <Your branch name>
Make changes and push as needed. With a couple of extra steps, you can take a Stale MR and get it going, while still giving appropriate credit.
Last edited by TheChimpken on Sun Feb 12, 2023 3:15 am, edited 1 time in total.
User avatar
TheChimpken
Froob
Posts: 59
Joined: Tue Dec 27, 2022 7:59 pm
Has thanked: 30 times
Been thanked: 29 times

Re: Testing: A cheatsheet of handy tips and tricks

Post by TheChimpken »

How does code go from a commit to get in to the Live Server?

A contributor will set up their Dev Environment following the steps in the Git Basics page: https://gitlab.com/2009scape/2009scape/ ... git-basics

From there, someone who writes code can get it in to production (the Live Server) with a process generally similar or the same as the below:
  • Code is created and committed on a local repo.
  • Commits are pushed to your fork and a merge request is opened to 2009scape/2009scape. It's important here to define your test scope:
    • What did you change?
    • What scope does a tester need to address to ensure your changes don't cause a regression? (i.e break/remove an intended feature previously available)
Great. You've got a new addition ready to go, and you've got a Merge Request in. What comes next? Testing.
  • A pipeline completes. Given that's successful and you've not made and merge commits as a part of your MR, it'll be merged in to the testing server.
  • A third party then completes testing for your MR, and provides a report on the MR for review.
  • A staff member checks the test report, outlines anything else needed to test if needed, then merges it in to the master branch.
  • Every two weeks or so, a new release is cut and the changes are put in to the Live Server, ready to go!
Then pat yourself on the back. Thanks for contributing!
User avatar
TheChimpken
Froob
Posts: 59
Joined: Tue Dec 27, 2022 7:59 pm
Has thanked: 30 times
Been thanked: 29 times

Re: Testing: A cheatsheet of handy tips and tricks

Post by TheChimpken »

Well, we've come this far. How do I dev?
How to Dev: From Chimken Note: This guide mainly covers how to use Git in your terminal. Can't give Kotlin lessons if I don't know the language ;)

This guide assumes you've followed all the instructions from the Git Basics page, which I've linked a few times above and also here Click the link if you want to dev (gitlab.com)

When making changes, remember - Authenticity is Key. Back up your changes with historic wiki entries or other similar sources to ensure you've got a compelling case for your changes.

Lastly, the more information you can give testers, the better - Write a summary of what you changed in human language for testers to scope their work from - This will mean your changes get landed that much faster.

Prepare your workstation for a new branch - Run this in your terminal:

Code: Select all

$ git checkout master
$ git fetch -ap upstream
$ git pull --ff-only upstream
$ git push --force origin master
Dev Cycle
1. Do dev things - Make changes to files, then save those files. (Making JSON changes, or changes to drop tables or item properties? Use the Thanos tool instead - This can be found here: Thanos Tool (Gitlab.com))
2. Test your dev things! Does the server build okay? If so, does your code do the things you expect?
3. If not, why not? Make further changes and repeat from Step 1. If it all works, go to step 4!

Capture a point-in-time snapshot in your work
4. If it all works, yay! Lets save your work, and create a snapshot of your change. git status make sure only the files you've edited are in the red text in this output.
5. Looking good? Great. Let's commit those changes. git add <filename>, unless you have no unexpected files in git status, in which case git add ., which adds all files in the git status output.
6. Happy with that? Let's revisit git status again. You'll see the files that are staged for changes now, and you'll see that your files are now in green, meaning that they're ready for the commit. Let's run git commit to create the point in time snapshot.
7. After doing so, you'll be hit with a text editor. See below for how to work with that, as it's not the most user friendly thing to work with.
8. If you're adding more changes from here, and you'd like to make further changes that relate to the same branch, revert back to step 1, and follow through again.

Time to merge?
9. You've made all your changes, and your commits are ready. Use git push --set-upstream origin <branch-name> to push this up to the master branch. Click on the generated link, fill out the appropriate forms and you'll be all set to go!
10. Wait for testers and staff to complete their review work, and make changes as requested using steps 1 through 8. If you've updated your branch, you need only run a git push to add more changes to your existing Merge Request.

When does my contribution go to the live server?
Just be patient. Generally, releases are cut every 2 weeks, giving plenty of time for bugs to be caught and tests to be run before the new code is let loose on the live server.

Pat yourself on the back -that's all there is to it!

Having trouble with any of this? Jump in to the Discord and chat about it in #development - There's plenty of talented people who can help if you're willing to go to the trouble of describing how things are going wrong.

Lastly, if Git seems all a bit complex, I'd be negligent if I didn't shout out Oh My Git https://ohmygit.org/ - This is a Free and Open Source game designed to help you train yourself on how to do things in the Git environment.
Post Reply