MVP '99

[patsen]

I've taken on other projects, but I'm glad to help if others are interested.

My method already handles minor league stats. The only players who need to be added (or adjusted) are those with little to no minor league experience. It's still a little rough, but it's more than usable.

What you're proposing could be done, but it's impractical. The only part the spreadsheet can't handle is converting stats to ratings. I'm already handling vsL/vsR splits, so we'd lose information in the conversion. I also assume there are more modern conversion algorithms.

I've done some research in generating ratings, but like I've said, I've taken on other projects. My last post has the details, and while it's given some interesting results, I haven't had time to finish it, so I should try to release it so someone else can continue the work. I don't think anyone else did anything similar (or if they have, they've been quiet about it.)

But the goal is to automate the stats so that it saves time for people to do more creative work. If we're writing tools, they should take stats from the most available source (to save on processing time), and generate the most convenient source files (which are probably MVPEdit files, or rather team files, which are ASCII.)

Hopefully there's something here you can use... I didn't put a lot of effort in making the projection spreadsheet user friendly, but if someone wants to pick up the work, feel free to contact me.

Now, if you'll excuse me, I have spin mechanics to figure out.

Happy Wieters Day

Pat

[DylanBradbury]

OK man, it was just an idea if you were still working on your mod. Good luck with your spin mechanics.

[patsen]

I'd still like to see it through, if only for efficiency in making roster mods. There's definitely demand, but until I can hook it to ratings, it's not very useful.

Like I said, if anyone wants to pick up on my work, contact me, and I'll hook you up. The spreadsheet is just big to post if no one's going to use it.

[yanksjames14]

has this mod come out yet

[Yankee4Life]

has this mod come out yet

No, and this one probably never will.

[patsen]

Which is a shame... since I was hoping to try something new in roster sets. Oh well.

[Yankee4Life]

Which is a shame... since I was hoping to try something new in roster sets. Oh well.

It sure is a shame. But if you have time one day, scroll back and look at the over 30+ pages in this thread. You'll see that these guys were all ready to work on it and then they stopped. It happens. :unknw:

[patsen]

I know... there's a lot of stuff that can be recycled with other mods (uniforms, parks, faces, announcer audio, portraits, etc), but the rosters are the part that have to be done year in and year out. That's why I was working on a way to automate rating players, but... other projects.

If someone can get another total conversion mod running, I can try to run the total minors rosters, but I can't spend a month trying to figure out how to turn stats into ratings. The '98 mod has potential...

[DylanBradbury]

I brought this up with Homer and tebjr a while back. I'm wondering if there would be a way to record a macro to copy values from a spreadsheet to my calculators, and then copy the ratings to a new spreadsheet.

There's a FREE Macro Recorder here, if anyone wants to see what they could make...

[patsen]

I saw that post, but I still think it's impractical. A total minors roster consists of over 3000 players. I'm running it in a spreadsheet now to help debug the algorithm, but that's also impractical. Ideally, I'd run it in a full app, so it can do all the hard work.

The optimal way would probably be to pipe the output of the stats program into the ratings program, or send the output of the stats to the input of the ratings program. That way, both scripts can run in sequence with no intervention.

[DylanBradbury]

I saw that post, but I still think it's impractical. A total minors roster consists of over 3000 players. I'm running it in a spreadsheet now to help debug the algorithm, but that's also impractical. Ideally, I'd run it in a full app, so it can do all the hard work.

The optimal way would probably be to pipe the output of the stats program into the ratings program, or send the output of the stats to the input of the ratings program. That way, both scripts can run in sequence with no intervention.

But a macro could be set to run 3000+ times, making it in my opinion practical. My calculators already have pretty sophisticated formulas that have taken me years to develop and correlate to stats.

Instead of someone else trying to create formulas, just recording a macro once and then running it x number of times might be more practical than going to all the work of creating new formulas.

[patsen]

Piping consists of accepting a file as input and then output as a file. You won't need to reveal your work, just make a change to the code. It was common practice before GUIs were so prevalent. Maybe I'm just showing my age.

If you think setting a macro is more convenient, feel free to do so.

[DylanBradbury]

oh.

[patsen]

Well, like I said, before GUIs were prevalent, the typical way of accepting inputs into programs was by the console. So, you have fields where someone can type in say, AB, R, H, 2B, 3B... and they click a button. 15 years ago, the program would tell you to type in the numbers separated by commas, or something else, and when you pressed enter, it would do the work and output it back to the screen. Then, you'd give a command to tell the program to end.

However, most old programs acted more like functions than they did applications (usually called commands, hence the .com extension in PC/DOS environments, and shell scripts in ?nix environments). So, the operating system allowed something called redirecting. The input, instead of coming from the console, would be redirected from a file, so the operating system would read the file, line by line, and put it in the program.

Of course, without user input, the output would go to the screen without pause, and you'd usually lose the top, especially if we run it in this case, with 3000 players. So, what you could do was redirect the output from the console to a file. That way, the program would run silently, taking input from a file, and saving it to another. Typically, stderr was used for errors, so if something went wrong, it would still go to the screen. C is written with this kind of thing in mind, but as long as your program runs in a console window, you can use the same techniques from the operating system.

You can do this in Windows by opening up the command line and typing dir. This will show the listing of the current directory to the screen. If you entered dir > dirlist.txt, then nothing will show up on the screen, but you'll find a new file with the output of the dir command.

Piping is similar to that, but instead of sending the output text to a file, the output is instead piped in as the input of another program. This way, you can chain together multiple commands without needing intermediate files. (Though for debugging purposes, it would still be useful to keep each step.)

You can try this by using dir | more. More is a command that echoes back input until the screen is full, then asks you to press a key to view the rest. Try that in a crowded directory (use cd to change directories) where the top of the screen would be lost before you got a chance to see it.

Hope you liked the history lesson. Implementing it in Visual Basic shouldn't be hard, as applications usually all start from the console. You just need to make a simple look that asks for input, then calculates the results and churns it out. I haven't written in Visual Basic, but I spent most of high school in Basic, so picking up enough to write a skeleton console app shouldn't be too hard.

[DylanBradbury]

Thanks for the info. :)

[patsen]

I wrote a quickie program... I had to look up a lot of VB, but it works.

Module Module1


	Sub Main()

		Dim input As Array


		Dim h, ab As Integer


		input = Console.ReadLine().Split(",")


		While input.Length >= 2


			h = CInt(input(0))

			ab = CInt(input(1))


			Console.WriteLine(h / ab)


			input = Console.ReadLine().Split(",")

		End While


	End Sub


End Module

It's been a while I wrote code that doesn't have braces or semicolons, but this is a fully working program. It takes input from the user, we're expecting hits and AB separated by commas, and it'll output the batting average. Thrilling, really. It'll keep doing that until you give it a line without commas, at which the input will end.

I like using csv for input and output files, because it's easy to import to Excel for further analysis, and as I showed, you can easily split the string into an array. I'll let you chew on that for a while... there's no rush, I doubt things are moving very fast, but just in case, I'm drawing the 1995 minor league stats.

[MissDCole]

this would be the 1 mod to get me to play MVP again lol

[DylanBradbury]

this would be the 1 mod to get me to play MVP again lol

Welcome back MissDCole! Sorry you've lost interest in the game :(

[Borgi]

Any interest left in this? It was like half way done when we all kinda of mutually stopped, maybe we can mutually resurrect it