Mids' Hero Designer v1.910

[Diellan]

[Diellan]

PvP set bonuses are still not applying.

For whoever imports all the new information, these values need to be corrected after every import of new data.  Which means after every import, you must physically go in and set each PvP set bonus that is used, as PvP mode, and assign each bonus that is used to the specified set and level (ie: 2 enh, 3 enh, and so on).

Have to manually do it each time? That's no good. That's no good at all. I'll look into making it an automatic part of the data import. I see a "Is PVPmap?" in the data files, so it should be "relatively" trivial to make it utilize that little piece of info. If I get it working, then this little problem should be resolved for good.

[Santorican]

My Mid's is giving me unlimited slotting lol...bug?

[Tog]

Do you mean that you can place more than 67 total slots on your build, or that you can 6 slot everything you have at level 3 without taking a level 4 power?

If its the second one, you have the builder set to Dynamic instead of Level-up mode.  There are 6 buttons at the top, right beside where you set your name and AT.  The top left of those will toggle this.

[Fixxer]

Any guesstimate on when Mids will be Incarnate compatible?

[Diellan]

Any guesstimate on when Mids will be Incarnate compatible?

Before I20. I should have my first working version of it ready within the next week, after which, it'll have to go through QA testing and there is a good chance of there being some bugs somewhere, so it'll take a week or two after that.

[Diellan]

Minor db update released today. Your Mids' should ask to update if you have it enabled. This update is a bugfix that addresses some issues with epic powers (as here http://www.cohtitan.com/forum/index.php/topic,3653.0.html ).

[Aggelakis]

My current Mids' is the most recent version (before this one). The updater runs, asks if I want to download, I click "Yes", it downloads something, then tells me it has to restart Mids' to apply the patch. I click "Yes", and Mids' restarts... and tells me that the same patch is available. Telling it not to download causes it to load the old, non-updated version.

I am running in Administrator mode. Any ideas what else might get it working properly?

Moving discussion to an already existing topic in Tech Support.

[Snow Globe]

Known Issues

• Windows Vista and Windows 7 have issues with the updater due to UAC interfering with writing to the Program Files folder. Many of these problems can be resolved by (a) installing as Administrator, (b) running Mids as Administrator, or (c) installing Mids to a different location than the Program Files folder.

Actually it isn't. It is putting the update file "mhd.mhz" into the "C:\Windows" directory.

Using the latest "autoupdate" I found where it is downloading to, and it really should NOT be putting the file there.

[Diellan]

Actually it isn't. It is putting the update file "mhd.mhz" into the "C:\Windows" directory.

Using the latest "autoupdate" I found where it is downloading to, and it really should NOT be putting the file there.

That's... incredibly weird. Maybe your registry entries for Mids have the wrong directory listed? It should be sticking it in your Mids directory.

[St0n3y]

Sorry, but no.  It is a problem within the updater.  My update was saved to \images\sets\   This has nothing to do with where the program is installed to, but a problem within the code that is telling hte program where to save the file. 

Not to sound snarky, but there were reasons the auto update feature was shelved in Mids'by Mids himself, and then left inactive when Steiner and myself were on the project.  It is too unstable to actually depend on.

[DeProgrammer]

Are you perhaps running it from a shortcut with \images\sets as your StartIn path or something? I just looked at the code, and it seems there may have been an oversight, where the filename given by the server ("mhz.mhd") is all that's used to reference where to save the file, which means (I believe) that the StartIn path would affect its save location. Tacking Application.StartupPath onto the beginning of the filename from the server would prevent this issue, if I'm right.

[Snow Globe]

That's... incredibly weird. Maybe your registry entries for Mids have the wrong directory listed? It should be sticking it in your Mids directory.

No. Nearly every single entry for MIDs is the same
C:\Games\Mids Hero Designer\Hero Designer.exe
C:\Games\Mids Hero Designer\MHDLoader.exe

The only time it is different is for:
C:\Users\Owner\AppData\Local\Temp\~nsu.tmp\Au_.exe

Which has a value data of:
Mids' Hero & Villain Designer Installer

My "start in" path is blank. Nothing, absolutely nothing, associated with Mids says "C:\windows\system32"

[Diellan]

Not to sound snarky, but there were reasons the auto update feature was shelved in Mids'by Mids himself, and then left inactive when Steiner and myself were on the project.  It is too unstable to actually depend on.

Just means I need to rebuild it. Yay, project!

EDIT: Also, I am immune to snark, for much the same reasons that a Fire Elemental is immune to Fire. Perhaps I absorb snark? Regardless, I prefer that people voice opinions and objections freely, so that I may respond in kind and that we can get past all the silliness and focus upon the important issue: providing a working, up-to-date product. I'm going to get that auto-updater working.

My "start in" path is blank.

And that might be the problem. We're going to try and duplicate the problem on our end and, if DeProgrammer is right, then it'll already be fixed come next version.

[DeProgrammer]

My "start in" path is blank.

On my computer (Windows 7), a blank "start in" path results in the current directory being set to wherever the shortcut or (assumed) calling program is. But I see here that Microsoft has an article about it: http://support.microsoft.com/kb/283065

Anyway, that information just makes my possible solution all the more likely to work.

[Steiner]

That NSIS and PowerShell script in the Install Script Generator Folder saved my @$$ more times than I care to mention.

What you fellas need to realize is that Mids never really intended to have the project touched by anyone else's hands. (No joint development).

One of the major fallacies in that logic is that all the paths are absolute to his environment.

You need to go through all the directory declarations in the shell script (CMD) and change them to the relative path.

For instance:

Code: [Select]

rd /S /Q ".\Finalized\App Folder\Data\" > Result.txtNotice, shell needs ".\" to use a folder within it's own directory and "..\" is a singular back-step to the parent.

Same thing applies for the NSIS part 1, 2 & 3; make sure they all have relative paths. Use absolute paths AS LITTLE as possible, or if you can completely avoid it that would be awesome.

Code: [Select]

!define MUI_FINISHPAGE_RUN "$INSTDIR\MHDLoader.exe"

Mids' Debug Configuration is also a little messy, it's designed to not change the working directory so it has constant access to the dependent files; if you can re-work the dependencies you might make it easier on yourselves for a development team.

Also keep in mind that the resources that Mids' usually depends on for an easier update are getting to the point where they're more likely to break the database housing all the numbers than aid it. A lot of the handlers were hard-coded; such as the columns and row count to cursor through the resources; A small look into that might set a lot of things right; I never had the time to tear it apart... I luckily just had St0n3y around to figure out work-a-rounds, lol.

ALSO keep in mind when making big time database edits that the config.mhd file MIGHT require to be included in the next update.

Commenting out the

Code: [Select]

del /Q  ".\Finalized\App Folder\Data\config.mhd" >> Result.txtline will do the trick. however the user's settings will be forfeited and overwritten on the next install. But including that will almost guarantee a successful update.

Hope some of this has given some light into the issues that seem to keep arising. Mids' source code is just one of those "Fix one thing; break 3 other things" sorta code. Mids' himself expressly apologized for it's "organic" structure. Looking back on the code he; he even stated that he wouldn't have done half of what's in there without twitching, lol.

ALSO: The auto-updater was disabled long before Mids handed over the source to Titan. It was mostly due to the UAC. It wouldn't work correctly, because if you aren't a full-blown admin (not just part of the administrator group) on Vista and Win7 than you need a full-trust certificate to make changes to files in the C:\Program Files\ directory. See... if people just installed it to their AppData folder(s) it wouldn't be an issue. In my opinion that's where it should be installed at all the time; just to avoid the UAC issues. However I'm sure while some users will be ecstatic at the new found stability of Mids, the power users will piss and moan about the convoluted/natively hidden location... lol.

[Snow Globe]

On my computer (Windows 7), a blank "start in" path results in the current directory being set to wherever the shortcut or (assumed) calling program is. But I see here that Microsoft has an article about it: http://support.microsoft.com/kb/283065

Anyway, that information just makes my possible solution all the more likely to work.

That makes no sense whatsoever. It is NOT saving to the current launch directory. I'm launching MIDS from my "Games Folder". Going from your hypothesis, the game is being launched from %SystemDrive%\Windows\System32\ <-Not what the article says.

On the outside looking in, I have to agree with Steiner that you should look into relative paths instead of fixed paths, because what it is doing will be a nightmare. Either that or use the install directory that is in the registry (it is in there multiple times) to figure out where to download the update file.

[Diellan]

The auto-update files and directories have nothing to do with the NSIS script. Mids regularly reads and writes to files in its folder, and there usually isn't any problem because these filenames are qualified with Application directory (location of the .exe) and thus are relative to it; the auto-update file, as DeProgrammer noticed, wasn't qualified at all (not qualified incorrectly, or absolutely, or anything), hence the problem.

[Steiner]

The auto-update files and directories have nothing to do with the NSIS script. Mids regularly reads and writes to files in its folder, and there usually isn't any problem because these filenames are qualified with Application directory (location of the .exe) and thus are relative to it; the auto-update file, as DeProgrammer noticed, wasn't qualified at all (not qualified incorrectly, or absolutely, or anything), hence the problem.

Unless you're running Windows XP
- or -
(For Windows 7 and Vista)
Turned off the UAC
Pressed WindowsKey + R
Typed CMD
Then typed: net user administrator /active:yes [enter]
...got a successful message
Switched User to the now unhidden Administrator account
and Ran Mids via the Auto-Updater

The auto updater will not work on the common user's PC. And asking users to compromise their security is never a good idea. How you are even saying it's working it beyond me, mainly due to the fact 90% of what makes the auto-updater function correctly was not included with the source Mids' sent me; which is now what you have.

But I'll idly sit by and wait for a hopefully snarkless message on how wrong I am.

[Diellan]

The auto updater will not work on the common user's PC.

The auto updater is working fine on most. There are still a few UAC issues,  admittedly.

And asking users to compromise their security is never a good idea.

Agreed. Mids should now always ask for Administrator access when it is doing its business. This isn't always the case, which frustrates me to no end, but I'm working on it.

How you are even saying it's working it beyond me, mainly due to the fact 90% of what makes the auto-updater function correctly was not included with the source Mids' sent me; which is now what you have.

Because the first thing I did when I took it over was build a tool for making auto update patches. The code for parsing auto-updates was all there, but there was no way to make them; luckily, all that the "parsing" did was take a zip file (zlib format) and extract it into the Mids directory... so I built a program that would use the same zlib dll to reverse the process and make the appropriate file. I did a bunch of other stuff to fill it in, but it wasn't much trouble since I'm really good at reading and understanding other people's code (sadly, a rare skill amongst developers, I find).