AboveTheChemist

Thanks for looking into the Photoshop options, PsiBug! And my sincere thanks in general for all your help in working the bugs out of the map creation process. I will purchase a copy of Photoshop (or maybe not, see edit below) and use that going forward with my map projects. With your permission, and with appropriate credit attribution, I would like to replace the problematic files I originally included in this post with the updated files you posted above. EDIT: I have since generated corrected maps of my own and made them available in the linked post above. Thanks again, I owe you a beverage of your choice should we ever meet in person! Edit: I wonder if the NVIDIA Texture Tools Exporter standalone would work? Current Photoshop seems to only be available via subscription only, and both it and older standalone Photoshop software (via eBay) have somewhat prohibitive pricetags.

I would also like to remind everyone of the excellent tool for easily importing Mid's builds onto the Beta servers, as detailed in this post by America's Angel. I was asked to look into incorporating that tool into the freebies menu. After considering how that tool works, and given that the tool utilizes data that is dynamically generated by the player, I didn't see a good way of incorporating the tool beyond the aspects of that tool (namely auto-leveling to 50 and granting patron pool access and accolade powers) that already exist as options in the freebies menu. EDIT: I've now added features which provide export directions and a command to open the Mids' Reborn beta build menu. These features should essentially provide the same functionality as the tool linked above. See the post below for more details.

I have completed a beta version of the freebies menu that includes all the updates detailed in the top post. I also added a 'Custom Level' granting option that utilizes the /beginchat command to allow the player to grant a single enhancement or set of enhancements (where applicable) at a level of the player's choosing. Here's how it works: Edit: Per Faultline's request, I added a /train 0 command which opens the training interface as if one were speaking to a trainer. I changed the 'Set Level' menu option to 'Train / Set Level' and added the new command as the 'Train' option at the top. Second Edit: Added the ability to open the Mids' Reborn beta export menu as detailed in the post below. Final Edit: This menu is now live as the default freebies menu on the Beta servers, so I have removed the download. Other than the chat button at the end of the chat bar, the menu can now be accessed in the following ways: from chat: /popmenu freebiesmenu via keybind: /bind <your_key> "popmenu freebiesmenu" via macro: /macro <macro_name> "popmenu freebiesmenu" Here are some screenshots of sections of the updated menu, spoilered to avoid a wall of images: I conducted two rounds of spot tests of all of the commands for each enhancement type, so I am reasonably confident that all the commands should work as intended. If anyone finds commands that don't work as intended, please let me know. Unless otherwise noted in the top post, I tried to retain all options from the previous version, even if they seemed redundant. For instance, I retained the ability to grant attuned versions of Very Rare and PvP enhancements, even though the un-attuned versions of both those enhancement types function as if they were attuned. I can remove these (and any other) redundancies if there is sufficient feedback to support doing so. Otherwise, feel free to provide positive or negative feedback. If there is enough support for these changes, then I will submit it for inclusion as the next built-in freebies menu, either in current form or modified to accommodate constructive feedback.

Regarding the numbers in the XML file, the ImageFileLength value seems to be the file size of the corresponding DDS file, in bytes (see screenshot). At least, for the handful of DDS/XML file pairs I have checked, which has included both VidiotMap and stock game maps, these numbers have always matched. I noticed that for the handful of my modified maps that I exported with mipmaps (except Warburg), the file size is 1 byte off from what I would expect. For example, both the stock and VidiotMap map for King's Row (the stock version is shown in the screenshot) have a file size (and ImageFileLength value) of 2097280 bytes. My exported DDS for King's Row has a file size of 2097281 bytes. I tried setting the ImageFileLength value in the XML for my modified file to both values, but the results were the same. The numbers for the various versions of the Warburg maps were all over the place, but the Warburg map is a bit of an odd duck so I am not going to worry too much about it at the moment. I also tried altering the UnknownInt value independently, but that did not seem to have any effect. HeaderLength varies by map as well, and it seems to be tied the length of the FileRelativePathAndName value, but I don't fully know how the HeaderLength is determined. I generally left that number alone. My process to date has included conversion from texture to DDS to BMP, then the BMP was modified and reconverted to DDS and texture. I have used several pieces of software to do this, including Paint3D for most of the image editing. I did a trial run using just the detexturizer to convert to DDS, and then editing/re-exporting the DDS using GIMP alone, but that seemed to make no difference at all in the file size or quality of the final product. So I feel reasonably comfortable that my overall process is sound, although I won't rule out that there may be some small tweak in the DDS export process (like using a different mipmap setting) that will solve the issue. I did tinker with the RGBA export and while I initially didn't have much luck, after testing some other stuff, and especially after it seemed apparent that mipmaps are probably not the answer, I think exporting some maps in RGBA may be the correct format. (this part was edited) I tested some other odds and ends but I think that covers the most relevant bits.

I agree. I feel better now that at least we are on the same page, even if the problem isn't fully solved. I'll probably take a few minutes to collate my notes/thoughts and post a brief summary of my observations shortly, if that would be of help. Edit: My first inclination is to try mipmap settings other than 'Default' but I'm still compiling my thoughts, then I'll start testing different mipmap settings. Further edit (1:30 PM eastern): I tried all the different mipmap filters (using Default wrap mode), as well as all the different wrap mode (using Default filter), with no luck. I tinkered with some other stuff, as well as reading up a little on what mipmaps are and do, and I started to think that maybe mipmaps was the wrong road to follow. Having just read your edit above it seems like you have also come to that conclusion, so I am going to keep tinkering with stuff other than mipmaps. Last edit for a bit (4:15 eastern): I tried exporting using all the formats (aside from RGB and RGBA) that seemed logical with no luck. I definitely think mipmaps are not the way to go, and I am beginning to think that maybe it's something with GIMP. I compared the header info between the stock game maps and VidiotMaps for 9 different maps (and I plan to check some more). Of the 9 I checked, 7 were identical. The two that were not were Siren's Call (which has been edited by the HC staff, the UnknownInt value was 0 instead of 65730) and Warburg (which makes sense because the VidiotMap for Warburg is 640x640 whereas the stock Warburg is 512x512). I think the image dimensions and file size matter more than I realized, and I think they are clues to the format used to export each image. I think that some maps need to be exported as RGBA, and others as RGB, and not just all RGB as I previously thought. For instance, the file size for Warburg (769k) corresponds to a 512x512 image with 3 channels (RGB), and the file size for King's Row (2049k) corresponds to a 512x1024 image with 4 channels (RGBA). That doesn't solve the issue of the problematic maps at lower world texture qualities, but I think it is an important part of the process. I think I have exhausted all the reasonable export options available in GIMP, and I am not sure what else to try at this point. I don't have immediate access to any other software (like Photoshop) that is capable of editing DDS files, but I'd be willing to make that investment if I knew another software product would work. I may see if I can track down the dev that worked on the Siren's Call update, to see if I can get any insight from them.

I wouldn't describe it as happy, but it was thorough. Unfortunately, despite all the iterations I tried, my best result wasn't quite a full success. I did a couple of control tests, one with the stock in-game map (i.e., no modified map in my data folder) and one with the original VidiotMap, and confirmed that both those maps display 100% clearly at all world texture quality options. I tested both Warburg and King's Row with the same result. The best results I was able to achieve with my modified Warburg and King's Row maps was after I followed your instructions as laid out above. This method produced maps that were visible (i.e., not blank or 'scrambled') at all world texture quality options, but the maps were low-resolution at lower world texture quality settings and would appear at increasing resolution as the world texture quality was increased. The maps were 100% clear at the highest world texture quality settings. I did learn that my re-texturizing script was not causing any of the issues, but it did not permit me to edit the header information so I ended up using the detexturizer for that purpose. I also gained some insight as to what some of the numbers in the header mean, not that that helped me achieve the goal of a 100% working map. PsiBug, if you are willing, I propose an exchange of our 'best' maps, to see if my maps appear any differently on a different system, and to see if I can gain any further insight from your map. If you are agreeable to that, I can PM you, or you can feel free to PM me as well. Thanks!

Thanks for all the investigative work, PsiBug! I had a couple of observations and a question. I checked on my system and as you can probably guess, my maps were blank and/or scrambled at any world texture setting other than 'High' or 'Very High'. You asked previously about my GIMP export settings, and they are identical to what you showed EXCEPT the mipmaps settings (I didn't use mipmaps on mine). My questions is: Did any of the '100% working' XML files you examined come from the original VidiotMap files that Blondeshell posted? I used the original VidiotMap textures as my 'donor' textures for the header data and I wonder if I would be better off using the original map textures that come with the game data. Or, if the VidiotMap header data is fine, it's possible my re-texturizing script (I wrote a simple one in Python) is somehow garbling the data, and I should switch to using PK's detexturizer. I'll run some test maps later on my end to see what I can get working. I may also try using the RGBA format. I had some issues with it previously (although I don't remember which maps gave me trouble) but those issues might have been more due to the lack of mipmaps and/or the faulty header values, rather than the RGBA format. Thanks again!

Thanks for the kind words, Pouncy. It's been a big learning process but these projects would not have come to fruition if I didn't at least try! Interesting. The header data that I use in my modified maps has been transplanted right from the original VidiotMap textures, so it should be good. Unless those two numerical values you found are actually in the dds part of the data and not the header data. If so, perhaps those values are tied to the mipmaps? Or, perhaps I should use header data from the original in-game maps?

My world texture quality is set to very high, but I have not tested any of my maps at any lower settings. I have not been including mipmaps during the export process (because they didn't previously seem necessary), but I am happy to export a test map using them to see if that is part of the issue.

Assuming that I am the individual to whom you refer, I didn't alter the resolution (in relation to the original in-game map) of any of the maps I updated. I also didn't compress any of the maps I updated, because I found that any time I used the available compression methods, the image quality was degraded compared to the original. I am not sure if the originals were compressed or not, but my best results were achieved when I used no compression. From what I can tell, at least some of the original maps use RGBA format, and I initially used that format as well, but I found that some of my modified maps appeared at least partially 'scrambled' when I used RGBA, so I switched to RGB and had consistently good results, so that is what I used. As noted previously in the thread, in attempting to solve the issue I sent Icecomet a number of test files saved in different formats (including RGBA), both compressed and uncompressed, and none worked. I'll also note that, for the Siren's Call map at least, I believe Icecomet also tried several other variations by other authors that were created since that zone was rotated in late Nov 2020, and none of them worked. So I don't think the problems were isolated to just maps that I created. As you noted, I am indeed new at this, so if there is some part of the process I can tweak to make the maps more universally usable, I am happy to do so. In addition to the modified maps I have included here, I have published another (much larger) set of modified maps, and have a couple of other projects using modified maps in the works, so I'd like to make sure those are error-free for anyone that wants to use them.

I do use GIMP to convert my image files to DDS before replacing the header info to turn them back into .texture files. I suspect that the VidiotMap folks may have used other software to either convert the image files to DDS, or to manipulate the DDS files directly, before turning them back into .texture files. I don't otherwise have much (if any) need for image manipulation software, so GIMP was the best option for me. But it is entirely possible that the issue is related to the software.

Last summer I put together some farming inf numbers in this post, in an attempt to quantify the impact of the then-recent farming nerf. My approach included some opportunistic marketing so I think those numbers might be relevant to this discussion. I didn't get into inf/time in that post, but I mentioned my times a few posts down.

It might not be the only explanation for what you are seeing, but I believe those dummies behave like any other spawn in that, if someone logs out and back in within a certain radius of them, they will despawn. EDIT: I tested logging in and out near the dummies, and they never despawned, so unless I missed something, that does not appear to be a potential cause of the disappearing dummies.

Just to be clear, are you using my updates to the Kallisti and Warburg maps from Feb (the ones I now available in this post)? If so, that shoots some holes in my working theory, but I suppose it brings us ever closer to a potential resolution. If not, do you mind trying them and reporting back? And make a backup of your existing textures should mine prove problematic!

My best working theory at this point is that there is some nuance to the process that I am missing that causes the maps I make to be 'blank' for a subset of users. I was not involved at all in the creation of any of the iterations of VidiotMaps, so I do not have access to the methods that were used. I essentially used trial-and-error to develop my own process, which creates maps which work fine for me and for most people (as far as I can tell), but there are a few folks for whom my maps are all blank. I worked fairly exhaustively with Icecomet, both in this thread and via PMs, to try to solve the problem, but to no avail. Unfortunately my best answer at this point is that if my maps don't work for you then you'll need to delete them and find another set of maps that does work. I am still on the lookout for a solution but I don't have any leads at this point, and would probably need to chat with someone that was involved with the original VidiotMaps project in order to gain more insight about the process that was used to create those maps.

Do the other two maps included in the vidiotmap_updates_feb_2021 (Kallisti Wharf and Warburg) exhibit the same black/blank map issue (or perhaps other issues), or do those maps appear normal?

Aside from the feedback I carried over from the previous thread (which I detailed in the top post) and the one comment I addressed above, I have not received any other feedback regarding the changes I mentioned. If anyone has any thoughts about the potential changes I mentioned, please let me know. Thanks!

I've made a few updates since my last post. In the CoH Zone Maps zip file (which contains the VidiotMaps), I updated the Siren's Call, Warburg, and Kallisti Wharf maps as detailed in this post. In the CoH TSP Maps zip file (which contain VidiotMaps with my optimal badge/plaque collection paths overlays), I updated some maps for the following reasons: Minor path adjustment to account for zone corners in: Dark Astoria, Port Oakes, Recluse's Victory Minor path adjustment to account for badge under tree canopy: The Hive Path changes to account for updated badge/plaque locations in: Brickstown, Founders' Falls, Nova Praetoria The data in the links in the top post have been updated, so please visit those links for the updated data.

I manually collected highly accurate coordinates for all exploration badges and history plaques. I also re-ran my optimal path scripts to check for any route changes due to the more accurate coordinate data, and the routes for Brickstown, Founders' Falls, and Nova Praetoria did change slightly. I also updated a few other maps to correct a few other issues I found. Here's the full update log: Minor path adjustment to account for zone corners in: Dark Astoria, Port Oakes, Recluse's Victory Minor path adjustment to account for badge under tree canopy: The Hive Path changes to account for more accurate badge/plaque locations in: Brickstown, Founders' Falls, Nova Praetoria I have updated the manual install zip file as well as the version that appears in the CoH modder tool. If anyone notices any other issues please let me know.

I manually collected highly accurate coordinates for all exploration badges and history plaques. I also re-ran my optimal path scripts to check for any route changes due to the more accurate coordinate data, and the routes for Brickstown, Founders' Falls, and Nova Praetoria did change slightly. I have updated the install files with the more accurate coordinates and the updated paths for those three routes that changed. Barring any other minor bugs/errors I think this popmenu is complete and ready for when i27p2 goes live.

I think this is a fantastic idea. I play casually and enjoy taking in the content along the way and being challenged as part of a team, rather than steamrolling/stealthing in pursuit of maximum XP or merits. The proposed playstyle/restrictions listed in the OP appeal to me in every way, except for the roleplaying aspect. Roleplaying just isn't my thing. If that is a deal breaker that precludes my ability to participate, then no worries and I wish you all lots of fun and good times. However, if there is a little room for players like me (perhaps an RP-free night once a week or something) then I would love to give this a shot.

I think this qualifies more as a quirk/oddity than it does a bug, but I was collecting badge coordinates last night and ran across this issue. It was on the Steel Canyon mayhem mission, and it looks like thumbtacks (or at least the nav marker) can be thrown off if there are objects in close proximity. I've attached two screenshots. The first is after I have positioned myself directly over the badge and used the /loc command to generate a thumbtack link in chat, and then I clicked that link to bring up the nav marker. The nav marker should be directly over the badge but as you can see, it shows up 14 feet away, and note that there is a 'Large Metal Crate' object directly to my left. The second screenshot is after I have destroyed that 'Large Metal Crate' but I have done nothing else. I did not re-click the /loc link, but as you can see the nav marker has moved into the correct position. My guess is that the 'Large Metal Crate' in this case is somehow interfering with the nav marker placement. I've collected hundreds of badge coordinates this way (including all the badges in the Safeguard and Mayhem missions), some with critters nearby but none that I recall with objects nearby. This is the first time I have run across this issue. If it rises to the level of 'bug' I am happy to post it in the bug reports thread.

Thanks for keeping me straight Aberrant, my lack of experience in editing missions is showing!

Also there is a template for mission briefing info which would probably make the process easier for you. https://hcwiki.cityofheroes.dev/wiki/Template:Mission_Briefing It includes documentation for what each of the parameters does. I checked out the page you are editing and it looks like you have utilized some templates there so I'll assume you are generally familiar with them. If not just let me know and I can walk you through them. It took me a while to discover templates but once I did it made certain tasks much easier.

This is definitely the right place for these questions! The 'Unnecessary Solicitation' is the dialog from the contact if you speak to them anytime in between accepting the mission and completing the mission, to the best of my knowledge. I think the idea is that, once you accept the mission, the next time the contact expects to hear from you is after you have completed (or failed, in some cases) the mission, so if you call them in the interim they'll generally say one of two things: They'll repeat the 'Mission Acceptance' message verbatim (or close to verbatim) They'll say something along the lines of 'Hurry up or you're gonna fail the mission' (but it'll be tailored to your particular objective for the mission) Check out Market Crash as an example. The 'Unnecessary Solicitation' for the first mission (Part One) is the same as the 'MIssion Acceptance', but in the second mission (Part Two) she basically tells you to hurry. There may be other examples out there that I haven't seen, because I've only edited a handful of missions myself, so there's a chance that the 'Unnecessary Solicitation' might not fit into one of the two categories I outlined.