Kccitystar

I'll work on MVP 2003 and 2004 rosters down the line if there's demand for it. I'm trying to keep the scope tight by focusing solely on MVP 2005 for now.

Ah I think this is for 2K12!

Could be missing faces

All, Just curious if you guys think the existing layout of the player view works? What could be changed from the current view in Classic MVPEdit?

I'm just curious on how this is possible given that the DRM required for the game to work has been removed since Windows 7 on the OS level. Actually, nevermind, I won't even ask. There's a tutorial on our site here for working with dgVoodoo2. Check the forums.

You said you were able to run the game on Windows 11 with no issues, I should be the one asking you how you got it to work without these workarounds for the DRM and GPU!

It's supposed to emulate a handful of cards, I think the Radeon 8500, GeForce 4 Ti 4800, Geforce FX 5700 Ultra and 9800 GT are in the list

No prob. This week is probably when I start working on trying to present the data in the editor. The best way I can explain where I’m at is like building a house. So far, I haven’t been “decorating” anything yet. I've been doing all the unsexy but critical work before you see anything on screen: The land and blueprint are locked: .mvpdb (SQLite) is the working format, DAT files are import/export only The foundation is poured: deterministic DAT > DB > DAT round-tripping works Utilities are in: legacy quirks are normalized safely, warnings are explicit, no silent corruption The framing is up: the editor supports multiple open rosters, proper app state gating (i.e. things are greyed out until you open a roster or import one via DAT), and safe close behavior (Save/Don’t Save/Cancel prompt before closing the editor) In other words: the house stands, the doors lock, and nothing catches fire, but there’s no drywall or furniture yet. The next big step is drywall: actually showing the data - the list of players, team lists, historical data and player detail views, even if it's read-only at first. Once that’s in place, everything else I and others want to see (import/export players, advanced searches, SQL mode, copy/paste from excel/sheets, etc.) becomes a lot more straightforward to build on top of a solid interior, instead of trying to wire things through exposed studs, if that makes sense. I mean there's still a lot to do, but the groundwork is where I want it to be so far!

There is a utility called SafeDiscShim that recreates the "handshake" the DRM makes between your PC and the discs so the game can work, along with dgVoodoo2 that spoofs earlier DX 8 graphics cards since the newer GPUs won't work

asked and answered on the first page brother :) The big one is MVP 2003 because they do not have a minor league system and the in-game economy is based on points, not money. I'll give it a swing once I can get the MVP 2005 editing sorted

Took me a couple of weeks but the ability to edit multiple rosters at the same time is IN. Now they load up like a chrome tab: Plenty of other stuff to go as time allows but this is pretty neat!

I believe your best bet is to play on a native system. VMs do not allow passthrough GPU support so it can use the host GPU for 3D

The goal with MVPEdit Pro is to do roster editing extremely well, with better visibility, safer workflows, and fewer crash-prone blind spots than MVPEdit ever had. Where the game has hard limits, the editor should detect and explain them instead of silently trying to work around them. That’s how people lose hours of work. I could look into doing these since they address clarity, safety and speed, which are like the holy trinity of a good editor: Editing All-Star teams without manual player duplication Team realignments Smart detection of unused slots for faces/portraits Guardrails + crash detection Clear warnings when you are making changes that might cause quirks in-game Some of the more advanced ideas here make sense as separate tools or pipelines down the road but keeping scope tight is the only way this editor can stay reliable and predictable at the moment

This section was created to give Spanish-speaking members a comfortable place to discuss MVP Baseball 2005 modding in Spanish. It is intended to improve communication and inclusion, not to fragment the community. Canonical resources (ID lists, tools, official releases) remain centralized in the English forums to preserve compatibility and clarity. Moderation guidelines are being developed to ensure fairness and consistency across languages. Hola! Nos tomó bastante tiempo, demasiado, probablemente, pero ha llegado el momento de construir un puente. Este espacio nace para la comunidad de habla hispana que comparte dos grandes pasiones: el béisbol y el modding de MVP Baseball 2005. Aquí pueden comunicarse en español con confianza, hacer preguntas, compartir ideas, coordinar proyectos y apoyarse como equipo. El béisbol siempre ha sido un lenguaje común en el Caribe y en toda Latinoamérica, y esta comunidad no es la excepción. Este foro no existe para dividir ni crear espacios separados, sino para acercarnos, mejorar la comunicación y evitar malentendidos que a veces surgen cuando el idioma o las costumbres son distintas. Algunas pautas importantes: El español es totalmente bienvenido aquí para discusión, soporte y colaboración. Los recursos canónicos que afectan la compatibilidad entre proyectos (listas de IDs, herramientas, guías técnicas y lanzamientos oficiales) se mantienen en los foros en inglés, que continúan siendo la referencia principal para todos. Si un proyecto está basado en un trabajo previamente publicado por otro usuario, pedimos que esto se aclare de forma transparente. Dar crédito es importante y, cuando sea posible, también lo es la coordinación y el respeto entre las partes. Las traducciones o hilos de referencia en español son bienvenidos, siempre que enlacen al hilo original en inglés cuando corresponda. Además, el equipo de moderación y el staff del sitio estarán trabajando en guías claras para manejar este espacio con respeto y buen criterio, de manera que nadie quede en una posición incómoda, ya sea por diferencias de idioma, costumbres o formas de comunicarse. La idea es que este foro sea un lugar cómodo tanto para quienes participan en español como para quienes ayudan a mantener la comunidad funcionando día a día. Este espacio existe para que más personas puedan participar, aportar y sentirse parte de MVPMods, manteniendo al mismo tiempo la claridad y la compatibilidad que han sostenido a esta comunidad durante tantos años. Si tienen dudas, ideas o sugerencias para mejorar este espacio, no duden en compartirlas. Como en el béisbol, esto se construye en equipo. Gracias por estar aquí y bienvenidos.

Maybe in the future. That would require me to reverse engineer the format for MVP 2004 and 2003 which are entirely different from each other even if they look similar in structure

Yep, autosave is in. MVPEdit Pro will edit a .mvpdb project file the entire time (it's an sqlite database), so I’m planning an auto-recovery system similar to Microsoft Office where the editor periodically creates a recovery snapshot in case of a crash every 10 minutes. It won’t automatically export or overwrite roster DAT files, so manual saves and exports are still going to be explicit actions. Just one of those "feels right" kind of things.

There will be an extensive guide to how the roster editor works and how ratings work in MVP when the tool is released, I can assure you

A 4, 9, or 12 in HR vs L/R is not a direct percentage and does not map 1:1 to the hit chart. They're basically 0-15 values that are just tuning "buckets" for tendencies. Weights basically vs outcome shares. EA does this for a lot of fields (as I mentioned previously) to put guys into clear tiers and keep AI behavior stable from game to game, and it avoids tiny changes swinging results dramatically. So it's not so much “this many percent of hits will be home runs" but more like "how strongly a hitter is nudged toward home-run outcomes when a home run is already possible”. People like to assume there *should* be a formula but there isn't. So when you see HR = 9 (0–15 scale) and Power = 80 (0–99 scale), your brain wants to try and translate what that 9 means on the 99 scale, but MVP never asks that question internally. Instead, it asks: What kind of hitter is this? (0–15) Within that kind, how often do good outcomes happen? (0–99) And those answers never really collapse into a single number. When you see HR vs L = 4, or HR vs R = 9, or power hitters with 12, think of it like a nudge, not a percentage. Actually, you can think of it like lottery tickets in a hat: A hitter with HR = 4 has some tickets for home runs A hitter with HR = 9 has more tickets A hitter with HR = 12 has a lot of tickets But if the situation doesn’t allow a home run (bad pitch, weak contact, wrong zone, etc.), those tickets never get used. The game doesn’t force a home run just because the number is high. The hit chart percentages (GB / FB / LD / HR) are outcomes over time, after everything is factored in (contact quality, pitch type, location, count, handedness, etc.). The HR rating influences that process, but it doesn’t define it. So two hitters might both show a 5 HR in the chart, but one gets there through raw power, and the other gets there through mistake pitches and favorable counts. Same result, different paths. MVP designed ratings this way so it keeps games believable, it avoids one bad pitch deciding everything, and it makes elite power show up naturally over time while not making things feel scripted. It's less flashy but more baseball-like, if this all makes sense. Hope this helps!

So an update: Doing Things the Boring (Correct) Way I’ve been working on the less flashy but very important side of the editor: making sure roster imports are safe, predictable, and transparent. MVPEdit Pro now has a proper DAT import pipeline that takes the original MVP Baseball 2005 roster files and converts them into a modern database format without silently changing things behind the scenes. The goal here is trust first, right? If the editor fixes something, it should tell you. So, one big example: the tool now detects and automatically corrects a known legacy issue in older rosters involving a missing attribute in lhattrib.dat, dating back to MVP 2004. Basically, there was no column for hitter tendencies when chasing late-breaking pitches (like sliders and slurves) against left-handed pitchers. The game has the pitch movement, but no hitter-side behavior to react to it, so everyone responded the same way with a 0 rating. This will be fixed when you import a roster by adding the column in and shifting every other column to the right. This will sadly break importing to MVPEdit since it will not recognize that change (the data shape is now different from what it expects), but to me that’s an acceptable tradeoff. The goal here is to move forward with a correct data model, not keep papering over legacy limitations. The fix will restores the missing attribute, but it won’t invent ratings...yet, but that’s intentional though. Assigning values is an editing decision, not a repair step :) When you import DAT files, the editor: detects the legacy format, applies the fix safely, explains exactly what changed, and continues the import. No mystery behavior, no broken rosters. I also added some quality-of-life polish: clear import success messages, readable warnings instead of cryptic errors, and status bar feedback so you always know what state the roster is in. Next up is dirty-state tracking (showing when a roster has unsaved changes), which opens the door to real editing and eventually undo/rollback support. The way I visualized it in my notes, basically the status bar (where in the image I linked says "Import completed with 1 warning(s)") will say something like "Pending Changes: (your most recent edit) + X others (if applicable)". The name of the roster on the titlebar will also have an asterisk to give you visual cues to save your roster. Classic MVPEdit did not have a way of telling you this, so a lot of the time if you fat-fingered a value or a name and then moved on to work on something else within the MBE, that was pretty much it. First draft, final draft. I'm all about modernizing the workflow with MVPEdit Pro. I'm going to probably add a "View Edit History" feature that will show your last 10 changes in a small window. This is what I got in my designer in Visual Studio (I'm coding in C#): Something that can inform you, like: Time | Player ID | Action ----------------------------------------------- 21:43:12 | 004512 | Changed Contact vs LHP 21:41:05 | 000983 | Updated Slider Control 21:39:22 | (Bulk) | Bulk Edit: Plate Discipline And maybe you can double click on one of these to revert the change (which would then move everything after it into a "redo" state until you make an unrelated change not in the history, which will sensibly clear the "redos" out) I haven't started with actually making use of the data yet to show anything but that's easy stuff. It's still the early days, but the foundation is taking a really good shape and it'll be future-proof. Still more features to go.

I will work on a config profile for you, what kind of TKL keyboard is it? If it's like 75% or 60% it'll be a challenge but a full TKL keyboard is doable

A note on how pitch families and hitter tendencies fit together Now that we’ve spent time understanding what each of the major blocks does: <cpubatter>, <batterai>, <batter>, and <pitcher>, it helps to zoom out a little and talk about how all of this works together. Especially when you look at the tendencies the game shows you in-game when you modify playere tendencies: Fastball, Curveball, Slider, with things like Take, Chase, and Miss split by left- and right-handed pitchers. The first thing to understand is that MVP doesn’t really think in terms of pitch names the way we do. It’s not sitting there saying, “That was a slider,” or “Here comes a curveball.” Instead, the game groups pitches into a few broad families based on how they behave. Some pitches challenge you with speed, some mess with your timing, and some fool you with sharp movement. The Fastball, Curveball, and Slider labels you see in the game's Edit Player screen are really just friendly ways of describing those families. That’s where <cpubatter> comes into play. Like we said before, this block is basically the CPU hitter’s eyes and instincts. When a pitch is on the way, <cpubatter> is asking a very human question: Does this pitch look like something I should swing at? The Take, Chase, and Miss tendencies in the Edit Player menu live right here. “Take vs RHP” isn’t about patience in general but about how comfortable a hitter feels laying off that kind of pitch from a right-handed pitcher. “Chase vs LHP” is about how often the hitter gets tempted by something that looks good at first but really isn’t. It’s all about perception and confidence, not results. If the hitter does decide to swing, the game hands things off to <batterai>. It asks, Okay, given the pitch, the timing, and the hitter’s strengths, how good was that swing? Fastball-type pitches tend to punish late reactions, slower breaking pitches tend to throw off timing, and harder breaking pitches are the ones that make hitters look really uncomfortable. <batterai> takes all of that and quietly sorts the swing into a quality tier. It still isn’t deciding where the ball goes, it’s just setting the stage. Once that’s done, <batter> takes over and does the visible work. This block doesn’t care what kind of pitch was thrown. It only cares about the swing quality it was given. From there, it shapes the ball’s exit speed, launch angle, spin, and trajectory within safe, believable limits. That’s why MVP’s hits have so much variety but still feel grounded. The chaos has already been filtered out earlier. On the other side of the matchup is <pitcher>. This block isn’t trying to be clever or strategic. Its job is to quietly control how sharp and reliable pitches are allowed to be, especially as fatigue sets in. Over time, pitches lose a little bite, miss their spots a bit more often, and become easier to read. That gradual pressure is what gives hitters more chances later in games without anything feeling sudden or artificial. When you put it all together, those Fastball, Curveball, and Slider tendencies in the Edit Player screen start to make a lot more sense. They’re not separate systems or hidden tricks. They’re just different ways of describing how a hitter reacts to different kinds of deception, from different pitchers, in different situations. Nothing here guarantees success or failure. It all just gently nudges probability. That’s the real heart of MVP’s design. Pitch sequencing works not because the CPU is smart, but because the game understands that different pitches test different weaknesses. Ratings don’t decide a single swing but rather shape how things unfold over time.

This is my controller.cfg settings for the 8BitDo SN30 Pro. There's two settings here, one in D-Input Mode and one in X-Input Mode: profile= Bluetooth_XINPUT_compatible_input_device device= Bluetooth_XINPUT_compatible_input_device player= 0 number_of_buttons= 16 number_of_povs= 1 number_of_axis= 5 VPAD_VIRTUAL_BUTTON_START= button 8 VPAD_VIRTUAL_BUTTON_SELECT= button 7 VPAD_VIRTUAL_BUTTON_CROSS= button 1 VPAD_VIRTUAL_BUTTON_CIRCLE= button 2 VPAD_VIRTUAL_BUTTON_SQUARE= button 3 VPAD_VIRTUAL_BUTTON_TRIANGLE= button 4 VPAD_VIRTUAL_BUTTON_L1= button 5 VPAD_VIRTUAL_BUTTON_R1= button 6 VPAD_VIRTUAL_BUTTON_L2= axis- 3 VPAD_VIRTUAL_BUTTON_R2= axis+ 3 VPAD_VIRTUAL_BUTTON_L3= button 9 VPAD_VIRTUAL_BUTTON_R3= button 10 VPAD_VIRTUAL_BUTTON_DPAD_UP= pov0 1 VPAD_VIRTUAL_BUTTON_DPAD_DOWN= pov180 1 VPAD_VIRTUAL_BUTTON_DPAD_LEFT= pov270 1 VPAD_VIRTUAL_BUTTON_DPAD_RIGHT= pov90 1 VPAD_VIRTUAL_BUTTON_L_STICK_RIGHT= axis- 1 VPAD_VIRTUAL_BUTTON_L_STICK_LEFT= axis+ 1 VPAD_VIRTUAL_BUTTON_L_STICK_UP= axis+ 2 VPAD_VIRTUAL_BUTTON_L_STICK_DOWN= axis- 2 VPAD_VIRTUAL_BUTTON_R_STICK_RIGHT= axis- 4 VPAD_VIRTUAL_BUTTON_R_STICK_LEFT= axis+ 4 VPAD_VIRTUAL_BUTTON_R_STICK_UP= axis+ 5 VPAD_VIRTUAL_BUTTON_R_STICK_DOWN= axis- 5 VPAD_PITCH_1= button 1 VPAD_PITCH_2= button 2 VPAD_PITCH_3= button 3 VPAD_PITCH_4= button 4 VPAD_PITCH_5= button 6 VPAD_FIELD_PICK_OFF_THROW_FIRST= button 2 VPAD_FIELD_PICK_OFF_THROW_SECOND= button 4 VPAD_FIELD_PICK_OFF_THROW_THIRD= button 3 VPAD_PITCH_OUT= button 1 VPAD_THROW_BALL= not_assigned -1 VPAD_INTENTIONAL_WALK= button 3 VPAD_INTENTIONAL_HITBATTER= button 9 VPAD_PITCH_HISTORY_OPEN= button 9 VPAD_SWING_NORMAL= button 1 VPAD_SWING_BUNT= button 10 VPAD_CHARGE_MOUND= button 4 VPAD_FIELD_THROW_FIRST= button 2 VPAD_FIELD_THROW_SECOND= button 4 VPAD_FIELD_THROW_THIRD= button 3 VPAD_FIELD_THROW_HOME= button 1 VPAD_FIELD_SWITCH= button 5 VPAD_FIELD_RELAY_THROW= axis+ 3 VPAD_FIELD_CUTOFF_THROW= axis+ 3 VPAD_FIELD_FAKE_RUNDOWN_THROW= button 6 VPAD_RUNNER_FIRST_SELECT= button 2 VPAD_RUNNER_SECOND_SELECT= button 4 VPAD_RUNNER_THIRD_SELECT= button 3 VPAD_RUNNER_RUNFIRST= pov90 1 VPAD_RUNNER_RUNSECOND= pov0 1 VPAD_RUNNER_RUNTHIRD= pov270 1 VPAD_RUNNER_RUNHOME2SCORE= pov180 1 VPAD_BASERUNNER_ADVANCEALL= axis- 3 VPAD_BASERUNNER_RETREATALL= axis+ 3 profile= 8BitDo_SN30_Pro device= 8BitDo_SN30_Pro player= 1 number_of_buttons= 16 number_of_povs= 1 number_of_axis= 4 VPAD_VIRTUAL_BUTTON_START= button 12 VPAD_VIRTUAL_BUTTON_SELECT= button 11 VPAD_VIRTUAL_BUTTON_CROSS= button 2 VPAD_VIRTUAL_BUTTON_CIRCLE= button 1 VPAD_VIRTUAL_BUTTON_SQUARE= button 5 VPAD_VIRTUAL_BUTTON_TRIANGLE= button 4 VPAD_VIRTUAL_BUTTON_L1= button 7 VPAD_VIRTUAL_BUTTON_R1= button 8 VPAD_VIRTUAL_BUTTON_L2= button 9 VPAD_VIRTUAL_BUTTON_R2= button 10 VPAD_VIRTUAL_BUTTON_L3= button 14 VPAD_VIRTUAL_BUTTON_R3= button 15 VPAD_VIRTUAL_BUTTON_DPAD_UP= pov0 1 VPAD_VIRTUAL_BUTTON_DPAD_DOWN= pov180 1 VPAD_VIRTUAL_BUTTON_DPAD_LEFT= pov270 1 VPAD_VIRTUAL_BUTTON_DPAD_RIGHT= pov90 1 VPAD_VIRTUAL_BUTTON_L_STICK_RIGHT= axis- 1 VPAD_VIRTUAL_BUTTON_L_STICK_LEFT= axis+ 1 VPAD_VIRTUAL_BUTTON_L_STICK_UP= axis+ 2 VPAD_VIRTUAL_BUTTON_L_STICK_DOWN= axis- 2 VPAD_VIRTUAL_BUTTON_R_STICK_RIGHT= axis- 3 VPAD_VIRTUAL_BUTTON_R_STICK_LEFT= axis+ 3 VPAD_VIRTUAL_BUTTON_R_STICK_UP= axis+ 4 VPAD_VIRTUAL_BUTTON_R_STICK_DOWN= axis- 4 VPAD_PITCH_1= button 2 VPAD_PITCH_2= button 1 VPAD_PITCH_3= button 5 VPAD_PITCH_4= button 4 VPAD_PITCH_5= button 8 VPAD_FIELD_PICK_OFF_THROW_FIRST= button 1 VPAD_FIELD_PICK_OFF_THROW_SECOND= button 4 VPAD_FIELD_PICK_OFF_THROW_THIRD= button 1 VPAD_PITCH_OUT= button 2 VPAD_THROW_BALL= not_assigned -1 VPAD_INTENTIONAL_WALK= button 5 VPAD_INTENTIONAL_HITBATTER= button 14 VPAD_PITCH_HISTORY_OPEN= button 14 VPAD_SWING_NORMAL= button 2 VPAD_SWING_BUNT= button 15 VPAD_CHARGE_MOUND= button 4 VPAD_FIELD_THROW_FIRST= button 1 VPAD_FIELD_THROW_SECOND= button 4 VPAD_FIELD_THROW_THIRD= button 5 VPAD_FIELD_THROW_HOME= button 2 VPAD_FIELD_SWITCH= button 7 VPAD_FIELD_RELAY_THROW= button 10 VPAD_FIELD_CUTOFF_THROW= button 10 VPAD_FIELD_FAKE_RUNDOWN_THROW= button 8 VPAD_RUNNER_FIRST_SELECT= button 1 VPAD_RUNNER_SECOND_SELECT= button 4 VPAD_RUNNER_THIRD_SELECT= button 5 VPAD_RUNNER_RUNFIRST= pov90 1 VPAD_RUNNER_RUNSECOND= pov0 1 VPAD_RUNNER_RUNTHIRD= pov270 1 VPAD_RUNNER_RUNHOME2SCORE= pov180 1 VPAD_BASERUNNER_ADVANCEALL= button 7 VPAD_BASERUNNER_RETREATALL= button 8

Some progress! So far I've got the menu strip items working and the editor can now create a valid database (with the structures), plus the keybinds are awesome. Global and Advanced search is going to be sick. You guys are in for a treat.

Jim, This is exactly the kind of real-world workflow stuff I was hoping to surface with this thread. A lot of what you’re describing lines up almost perfectly with where my head is already at especially around the idea of a Roster Audit feature: less “change values” and more “show me what doesn’t make sense before it becomes a problem.” For starters, Lahman integration is something on my roadmap. I want to make sure I do it right. One of those "measure twice, cut once" things because it has to be reliable and repeatable. Things like duplicate portrait/audio IDs, face/skin tone mismatches, and invalid pitch speeds are all great examples of stuff that technically works in the editor but quietly breaks immersion or balance if you don’t catch it. Baking those checks directly into the tool instead of relying on external scripts or spreadsheets feels like a no-brainer. This is the "well yeah, that makes sense" part of what I'm looking to build. Also, being able to import things from database to database is something I'm definitely looking at, because it could make TC projects or seasons of any kind a heck of a lot quicker to turn around comfortably. One neat little feature I want to add in honor of the work you guys do with TC is "Eras Profiles". I spoke about it in the shoutbox but basically the basic idea would be to have optional, era-aware profiles you could apply to a roster as a baseline. Things like global contact, power, stamina, pitch movement, etc., adjusted in a way that better reflects how the game was played in a given period: Deadball era, Live ball era, pre-expansion, steroid era, modern era, and so on. One important part though: this wouldn’t be about locking anything in or “auto-fixing” rosters. Think of it more like laying down the chalk lines before you start fine-tuning. You could apply a profile, see exactly what it changes, tweak from there, or ignore it entirely. From a design standpoint, I’m leaning toward keeping Eras Profiles intentionally lightweight, one solid baseline per era that reliably hits league averages for that period. TC history shows there are multiple “right” ways to balance something like pre-expansion baseball, and I don’t want to hardcode a bunch of competing recipes into the tool and pretend one is gospel. The goal, for me, is consistency and transparency: a known starting point you can trust, then adjust however you see fit. If the community eventually wants to build and share their own profiles on top of that, I think that’s a great direction. I just want the defaults to stay purposefully grounded and predictable. This is very much an idea in progress, but it feels like a natural extension of the same philosophy we’ve been talking about: making the intent clearer, reducing accidental imbalance, and letting modders spend more time on the fun parts instead of re-doing the same setup work over and over.

Like how the old editor used the Lahman Database?