Splash

The texture files are in C:\Program Files\eSim Games\SB Pro PE\textures\woodland. The files used include M1A1_HI1, M1A1_HI2, RadioCombined (and possibly radio), and M1A2_int (which also has a desert version in C:\Program Files\eSim Games\SB Pro PE\textures\desert. Don't edit the originals, of course; make copies to work on. Save your finished work in the appropriate mod folders.

I wouldn't call it "knee jerk" at all. It's a crucial issue to a mapmaker. And although I'm not a mapmaker, Glad to hear a fix is in the works.

Well, to be clear, the sound file in question existed for more than 2 1/2 years in my SB mods folder without incident and could be also be loaded, played and edited with other software on my PC -- both in Windows 7 and Window 10 -- with the same Realtek HD Audio. It only became an issue when SB tried to load in Windows 10. In any case, I'm just happy to have the glitch rectified.

From everything I've seen, Belgium's military vehicles are just basic green, like the DF30 and DF90. The sim comes with a green Piranha III C in the US 2000 folder (and US 2010). I would just copy that to the "be" folders in your mods directory. There aren't any decals or markings to worry about.

Oops, sorry. I didn't consider the possible value of the file for that purpose. I saved over it when fixing it. No, wait ... I actually do have a copy; I had -- duh -- backed up my mods folders to a separate drive before the upgrade. Email on the way.

So it turned out to be a sound file, after all. After installing a fresh copy, SB loaded without issue. (Yay.) So I went about adding in sound files from my previous mods folder, one by one, until I found the one that crashed the launch. It's called "leorumble." (I think it's for the Leo 1 ... not sure where or when I got it). Looking at its properties I saw that it had double the bitrate of other modded files of its type. So I changed that, returned it to the folder and ... no crash. The lesson learned is that SB will happily tolerate the file under Windows 7, but with Windows 10 -- not so much. Thanks, Retro, for cueing me in on where to look. Regarding the relative value of Win10 ... I wouldn't be making the switch if it weren't for the abandonment of support next month. I was plenty happy with Windows 7, but since M$ has quietly continued to offer the free upgrade, I figured I had better jump now or regret it later.

Quick status report: I have re-performed the installation of Windows 10 and now have a functioning, activated copy of Win10 with a digital license. All of my Windows 7 programs/apps ported over to Win10 and are functioning as before. For gaming purposes this includes CH Manager, Voice Activated Commands, Teamspeak, and Track IR 3, along with a copy of IL-2 1946, which loads and works fine (though I rarely play it anymore). I uninstalled Steel Beasts and the Codemeter runtime before the upgrade. Tonight when I return home from work I'll do a fresh re-install (no mods) and see what happens. Fingers crossed.

Regarding modded sounds. Yes, I do have a few ... all in the appropriate mods folders; none in the main Program Files installation. All working fine in Windows 7, I'm a little puzzled why a sound file would fail to load in Windows 10. Driver issue maybe? I have the latest one available (Realtek) for my motherboard (ASUS) ... but it's still quite old and for Windows 7. Anyway, ... as explained in the post above, I'm no longer in a position to troubleshoot the Windows 10 launch fails of SB by moving sound files. At this point I have a working install of Windows 7 on my solid state drive. If I am to proceed with my planned Win7 --> Win10 upgrade, it seems I have two options: 1) Perform the upgrade again as I did last time, and then troubleshoot the problem -- assuming it fails again to launch -- starting with the modded sound files. Or, 2) Wipe my system of everything SB, do the Windows upgrade, then re-install SB fresh and clean to Windows 10 and see if it works. Either route is a considerable investment of time, and I'm not sure which has the most chance of success. Probably option 2. So I'll let you know what happens.

So here's where I am right now: Foolishly tinkering with settings trying to find a solution on my own, I ended up with a BSOD on my new SSD with Win10 (upgraded from 7). Don't ask me how. I think I changed a boot setting. Fortunately, I still have the original HHD with my complete Windows 7 install (the one I had cloned to the new SSD). So I redid the OS clone from the HHD to the SSD. Now I have a fully functioning, authentic Windows 7 on the SSD. I've been here before. (SB loads much more quickly, by the way). What I'm thinking of doing now is completely uninstalling SB -- backing up my mods then wiping everything associated with 4.161, including the maps packages -- and reinstalling from scratch AFTER doing the Win7 --> Win10 upgrade. But I'm holding off on this for a bit until I hear from the team whether there's actually some other, more simple issue at play here based on the crashdump files I sent.

Re-installed (over existing), but got the same result on launch: Splash screen opens (in this case the four racing Leo 2's) then the same "stopped working" message as above. Zipped crashdump file on the way via email.

I'll try the re-install first chance I get. Over the existing without first uninstalling? The crash dump folder is completely empty, by the way, after multiple attempts to start the sim ... normally, in debug mode and in safe mode.

So I did a couple of things this weekend: Installed a new SSD in my aging rig, cloned my OS drive to it, and then upgraded to Windows 10 in advance of next month's end of support for 7. Ok. Maybe that's three things. So the install of the SSD went fine. The cloning of the OS went fine. Everything, INCLUDING SBProPe, worked fine -- just notably faster --when I booted to the new SSD, still with Windows 7. Then I did the upgrade to 10. Again, everything appeared to go fine; no conflicts or incompatible apps, to my surprise (and I've got some pretty old programs on my computer). But when I tried to launch SB, It stopped at the splash screen (artwork with logo) and informed me "Steel Beasts Pro has stopped working." I can't even get the debug or safe versions to launch. Same message. I know this is probably something simple I've overlooked and is clearly related to Windows 10 ... but since everything else on my computer appears to still work, I'm kind of at a loss. What do you need from me to find the answer? I'm leaning toward a complete uninstall and re-install of SB (including the map packages) but hope there's a simpler solution before I do that. (Oh, by the way, I tried the Map Download Manager, and it launched and connected without error.) And in case it's of any value, here's the content of the debug log from the latest attempt to open: [23:27:36,159] CGame WARN : ------------------------------- [23:27:36,159] CGame WARN : Steel Beasts Log File v4.161 [23:27:36,159] CGame WARN : Sat Dec 7 23:27:36 201 / 2912 [23:27:36,159] CGame WARN : ------------------------------- [23:27:36,159] CGame INFO : +--+ MEMORY USAGE INFO (SteelBeasts START): [23:27:36,159] CGame INFO : | | Process: 4.3 GB (0 % of 128.0 TB total, 128.0 TB free) 4.3 GB min/4.2 GB max [23:27:36,159] CGame INFO : | | Physical: 3.3 GB (21 % of 16.0 GB total, 12.6 GB free) 3.2 GB min/3.3 GB max [23:27:36,159] CGame INFO : +--+ Pagefile: 4.9 GB (15 % of 32.0 GB total, 27.1 GB free) 4.8 GB min/4.9 GB max [23:27:38,989] CStringTable ERROR: [LOCAL] *** MISSING STRING: 'STRINGX_RECENT_HOSTS'. And ... the service log from the same attempt: [22:33:19,414] TRACE: WinMain [22:33:19,414] TRACE: ctor [22:33:19,416] TRACE: onStart [22:33:19,416] INFO : Version 19.000 [22:33:19,416] TRACE: Starting up [22:33:19,416] TRACE: Loading configuration [22:33:19,416] INFO : Loading configuration from 'C:\Program Files\eSim Games\Steel Beasts Map Tools\Service\config\config.xml' [22:33:19,417] INFO : Map Package Directory is 'C:\ProgramData\eSim Games\Steel Beasts\maps\packages' [22:33:19,417] TRACE: Refreshing mappackage directory [22:33:19,417] TRACE: Refreshing folder 'C:\ProgramData\eSim Games\Steel Beasts\maps\packages' [22:33:19,531] TRACE: Done Refreshing mappackage directory [22:33:19,531] TRACE: Restoring jobs [22:33:19,531] TRACE: Starting up [22:33:19,531] TRACE: Interprocess emulation folder: 'C:\ProgramData\eSim Games\Steel Beasts Map Tools\IPC' [22:33:19,532] TRACE: Started up [22:33:19,532] TRACE: Started [22:33:19,535] TRACE: Listening on message queue [23:27:36,170] TRACE: QueryServerVersion

That's encouraging ... I'm making the presumption here that normal and specular modding is at least on the_List of things eSim wants to do. In its current form, the ability to assign modded textures to maps and embed them with distributable map packages is a neat tool, useful, I think, mostly to enterprising missionmakers and mapmakers like @Wax Savage who want to add immersion to their projects. I think the more casual player -- who's still picky about visuals -- will find it's just as easy (or easier) to move modded files into and out of the existing mod folders as needed. Also, mods like Falli's excellent structure retextures -- that do anything more than simply change the color of an existing building -- will have the drawback of missmatched textures. I think where the feature really shines -- as it stands now -- is in location-specific signage mods. Lots of currently-usable potential there. I'm always on the lookout for maps with lots of real-world "window dressing" ... though I know many avoid them because they can have pathing and framerate issues.

Yes, it's true Falli's instructions call for renaming/replacing original installation files. However, the mod is relatively old -- created almost 6 years ago -- and predates the new maps file structure of v4.161. Replacing original files, however, is not now and never has been recommended or supported by eSim. (I think Ssnake mentioned this in one of his posts above.) Can it be done? Yes. (Deep dark secret: I've done it myself in limited cases). But one does so at his own risk, and eSim rightly discourages it because, when it comes to technical support for an installation of their software, they need to know a problem is not self-inflicted by a user who altered installation files. This is the reason they provide a modding path in the Documents folder. Plus, as you note, modding these files in the main installation folders affects the models globally, which is far from ideal. My desire, since normals and speculars were introduced, has been that an approved modding path would be provided. I'm still hoping for that. But unless someone can point out my error, it appears the map packages path is not my answer.

Yes @Wax Savage normal and specular files can be important -- particularly from near viewing distances. In simple terms, normals govern the surface texture of the model; speculars govern its reflective properties. They give objects a more detailed, 3-D appearance from various viewing angles. Beyond that, they are important in the sense that if the normal/specular files don't match up with the skin file, you have issues. See the example below, where the wood-shingle roof on a modded barn retains the specular and normal textures of the stock corrugated tin. If a player (like me) cares about how an object looks when he gets close to it in-game, he'll definitely want the normals and speculars to match the graphical image. By following the instructions above and moving my "actors" file path to the Base package, I was able to get the modded building textures to show up in-game. Unfortunately, when I tried putting files in Normals and Speculars folders within the structure described, I couldn't get them to show up. I'm using the following path: C:\ProgramData\eSim Games\Steel Beasts\maps\packages\plain41 [autocreated base]\actors\textures\woodland ... and within that woodland folder are the individal .dds building skins (which appear in-game) plus the Normals and Speculars folders, which, in turn, contain their respective .dds normal and specular files. The structure pretty much mirrors that of the main installation path. Could it be I've placed those folders improperly? Or are Normals and Speculars simply not (officially) moddable -- even in this manner? DK-DDAM seemed to imply they work.

That's exactly what I was wondering about after reading DarkAngel's post, but haven't had the time to check it myself. If the mods are applied to every Delta using a given Base, the feature is slightly less attractive to me than first imagined. I do want to experiment with it though. I'm interested in the possibilities. I'm especially keen on the idea of modding normal and specular files -- something that otherwise is only possible globally (and unsupported at that). I'm guessing embedding the textures with the map makes them visible to all users in a network session? I'm also wondering whether mods in the Documents\eSim Games\Steel Beasts\mods folders would override those embedded with a map. (at least on the user's frontend).

Being interested in this particular feature of v4.1x, I decided to give it a go. Following Ssnake's instructions, I placed some modded building textures into the "woodland" folder in the following path: C:\ProgramData\eSim Games\Steel Beasts\maps\packages\plain41 [autocreated base]\deltas\CMTC Hornfelt\actors\textures\woodland ... ("CMTC Hornfelt" being a published package I created for use with my own modified "Camp Hornfelt" scenarios). The textures did not show up. So I tested them using the usual "mods" folder approach, where they appeared as expected. So, remembering that "published" packages can't be further edited, I tried creating an unpublished delta copy of my package, called "CMTC Hornfelt Test", and instead nesting the prescribed actors/textures/woodland path with my modded textures there: C:\ProgramData\eSim Games\Steel Beasts\maps\packages\plain41 [autocreated base]\deltas\CMTC Hornfelt Test\actors\textures\woodland. The modded building textures still didn't show up -- either in the map editor or when selecting the new delta map the mission editor. I tried re-saving, refreshing ... No bueno. So is this, indeed, a thing in v4.161? Can any beta testers confirm they've had this working?

If the problem is missing smoke and dust from artillery explosions, I think that was covered in another thread. Feature. Not bug. If that's not what this thread is about ... pardon my intrusion. 😐

It's my understanding that the "Is Dirt" checkbox in the theme determines the texture of emplacements. Could that be the issue here? Make sure only one terrain type has that checkmark ... preferably a sand or dirt one.