Visualizing Matches Locally

Visualizing Matches Locally
0

#1

I have recently submitted a new PR to the starter kit; it is a local replay visualizer. With previous code that I contributed, @876584635678890 kindly took time to review it and provide some feedback. This was super helpful and I would greatly appreciate it if some people wouldn’t mind just running the code to make sure it works on other systems.

You can find the PR here.

Thanks! :slight_smile:

Edit:
Here is an example image of what it should look like:


Newbie has questions
#2

This looks extremely cool, i’ll spend a few hours reviewing this tommorow, can’t wait to get this into the starterkit. You’ve more than earned the Open Source Leader badge, so you can upgrade your title now


#3

I see @Isaac and @876584635678890 taking it to the next level, sweet.


#4

This looks really cool, but I’m not sure how to get/use it. Is there a place I should go to read how to do it?


#5

Depends on how familiar with Git you are :).

If familiar, then on the PR page (what I linked) find the latest commit (farthest down) and select it. This will let you see the code that I changed last and you can get to the file from there.
Or, clone my fork and get it from there.

If you have no idea about anything I just said, go here.

Note that this is not a long term solution, since your code will not update as I or others make changes (not part of git). This is just to run the code right this second. Once the PR is merged you can simply update the starter-kit and the script will magically appear!

The instructions regarding how to run the script including examples is all in the header of the file.

Let me know if anything is unclear, etc.


#6

We will be merging this soon!

The only major issue I found:
When debugging this on a mac computer I added the following line to __latest_replays, immediately before the return statement.

sys.stdout.write("We found {} replays out of {} requested in {}\n".format(len(files), num, replay_dir))

Which gave the following output:
We found 0 replays out of 1 requested in /Users/ryan/Documents/C1/C1GamesStarterKit/scripts/contributionsreplays\

It looks like something is wrong with the filepath on mac OS X.
To make it work I changed this line:
replay_dir = os.path.dirname(os.path.realpath(__file__)).replace('scripts\\contributions', '')+'replays\\'
To this:
....replace('scripts/contributions', '')+'replays/'

Though this fix will obviously break compatibility with other machines. If you want to fix this, it would be awesome. Otherwise, let me know and i’ll do the fix.

For now I will merge it! Any additional updates can be made in follow up PRs

Note: I have not robustly tested every feature, but there is enough working for enough people that i’m more than happy to add this in for now


#7

Ah, good catch. Currently I have only been developing and testing in windows. I just finished setting up a linux environment for terminal and will update all scripts to work for both. I don’t have a mac, but things like file-line things should be the same as linux since they both run on unix.


#9

Oh so my change will work on windows? I’ll test it in office today, I had assumed it wouldn’t


#11

Thanks, i’ll look over the PR


#12

I was going to change it just by finding every ‘\’ and replacing it with ‘/’, but your solution works well too. Once this PR has been reviewed and accepted by @C1Ryan I’ll go through and make the same changes for my other scripts as well, since they use the same code.

This actually makes think of something I’ve been wondering about for a little bit now: the structure of the contributions folder. Currently, two scripts I have submitted use the File Handler class and other similar methods. All of the scripts I have submitted work completely independent of one another (other than calling get_results.py at the end of the run_arena.py, but that is in a try block). A much cleaner and easier to maintain solution would of course be to have these long scripts broken into different common files.

However, one of the things I like about the current system is that scripts are independent of each other and work without a bunch of different files. The other issue I see with breaking up the files is if other people start submitting code. It’s obvious right now if I created a FileHandler script separate, but if everyone who submits code has a bunch of files it would get confusing seeing the relations. Or is this not an issue since not many people are contributing?

Essentially, I would appreciate a response from C1 about whether or not they want us to break our code up the way I normally would with duplicate code functions, or to keep each script completely independent and self-functioning the way they currently are.


#14

That’s a tough question.

One thing to also consider is you could make subfolders in the contributions folders that then have split files, but because they are all in the same folder people will understand they may depend on each other.

If other people make code dependent on your code it would be troublesome whether you have split or together files if you update them.

So I think just make subfolders and it should be okay.


#15

I like the subfolders solution. Maybe something along the lines of:

If it is called from main it is in the main contributions folder, but all the nitty gritty insides can be broken up into a subfolder. This way functionality is not changed (called from the same location) but the code is also broken up without cluttering the directory.

This would also make it possible to define a init (in the subfolders) to make it easier for others to edit existing code to match their needs.


#16

Sounds good to me! Go for it!


#17

My vision for the contributions folder is that it would be very hands off and community driven. As long as it is contained within that folder I don’t mine what solutions you, 8, or other contributors come up with with these sorts of concerns. (We will still be review everything to make sure nothing is dangerous and seems to be working well)


Terminal Community Contributions