VoodooPokey

It may simply be a vista-related security issue. Editing things under Program Files is typically an admin-only action. If notepad isn't given elevated privileges then it can't SAVE to those folders.

Try right-clicking on your shortcut to notepad and either editing the compatibility settings under "Properties" to run as admin, or just right-click when running it and selecting "Run as Administrator" to run notepad... then load, edit, and save the file in question.

Busy week! Sorry it took so long to get back to you guys.

Toril - think you could enlighten us/me on what you additionally did to reduce the size to make your storyarc work? I'd love any extra info on what can be automagically reduced for future versions.

Tigra - I think that was my bad, and have posted beta 7 to rectify what I believe to be the issue with those colours. There are actually 4 colors and while two of them are rarely used, they do get used from time to time (as with wings and possibly shields). They were being eaten by the program.

Wuigly - that's a known issue with the in-game editor opening files that have been IGOR'd. All the information needed to publish is still in the file, but the information that the in-game editor uses to cross-reference (badly) the storyarc's critters with your critter files, despite not actually updating the former when you change the latter, is removed from the file by IGOR.

Ok, the old regex was eating costume parts that contained an fx field but no geometry - thats where the wings and aura went, since those costume pieces fall into that category. Beta 6 should handle the color and costume loss - thanks for the critter file info, Ledain!

As for arcanaville... you're too cool for school there, bud.. I'm happy that you have a list of things that affect it, but I don't, so its trial and error. At present I try to remove everything from the storyarc file that can be removed without altering the resulting story arc in the game. Does that mean some things are removed without an effect on whether it can be published? yes, that happens... however, if you remove everything that can be removed, then you'll cover the things that can be removed and have an effect since the latter is a subset of the former.

With luck they'll up the size limit in i15 and the entire point will be moot. The utility is just something I popped together while writing a set of classes for working with storyarc files with the intention of eventually making an editor/manager... so even if IGOR fails to have a profound difference, it also didn't require lots of effort to do.

In the end, my philosophy is "its better to try and fail than to sit around yacking about why there's no point in trying". This includes playing I-know-something-you-don't-know. But hey, we each spend our days doing the things we enjoy, right?

Arcanville - the point was they might as well ONLY tell us that... etc etc.. rather than mentioning the 100k size limit. As people have said, at times a lower than 100% value on the meter still won't publish, making it just as abstract a determination as 100k of filesize.

As for colors not changing the ultimate size - again, there appears to be a difference between the editors measuring and the measurement used to determine whether or not it will allow you to publish. This is evidenced in a few facts... first, that files run through IGOR will publish, but will give errors in the editor. Second, that a file run through IGOR that will publish can still read as > 100% on the memory meter, even if the aspects that cause stated errors in the editor are removed.

And once again, can we remember that "100k" was not something users made up, and again, not something that would be worth telling players if it wasn't meant to correspond to something they can measure.

My guess is that it checks for which parameters are present in each object, and validates the ones that are present, and makes sure key parameters are present, but does not create default value parameters for all those that are missing - that happens later (when the story is being executed). It explains why removing some costume fields reduces the file in an effective way while changing values does not (while the ascii version of red and black are different sizes, the binary representation is not).

As for wasting my time... well, we know for a fact that some changes are effectively influencing whether or not a storyarc can be published in that some that go slightly over the limit do become arcs that can be published. I'm sorry if that runs contrary to a thread you posted and are obviously very proud of and all, but since all we have to go on as far as the validation routines is guesswork and trial and error, I'm going to stick with attempting things that may not work, rather than just writing about why I don't think anything will work.

We've seen that at least some things do work, afterall.

Spell checking requires a dictionary to run comparisons with - dictionaries are several megs in size. Since the entire MA system is LOCAL (as in, everything you do when creating a mission is local-side and does not involve trading data with the remote servers) this requires that spellchecking be done locally.

So, while a few extra megabytes on a > 1GB game probably won't kill anyone, its a big addition. I know a lot of companies shy away from integrated spellchecking in their software for that reason.

Awesome, Ledain - I mean, not awesome in that it changed your critter, but awesome in that its something concrete to work with. Can I have a copy of the arc file to work with? Either that or just the .costume file for that critter works.

As for the meter being "memory footprint" - I'm willing to buy that, but likewise, that's the "memory footprint" as given by the editor, which is not the same as the routine used to decide if the arc can be published or not as evidenced by the fact that you can run IGOR on an arc and it'll publish, but if you were to load it in the editor it would give errors... and that some arcs which do not hit or go over 100% on the "memory meter" still have the publish button greyed out.

100k was the stated maximum size of arcs - unless the devs are total idiots (which we'll assume they are not) telling us that 100k is the maximum as measured by a system we do not have access to would be silly. Neither basic filesize nor the "memory meter" are foolproof ways to predict the acceptability of the size of a storyarc, so I'm going to continue to call both of them abstract estimates.

Maybe the Backwards Byshop can offer some insight - barring that, I'm going to keep plugging away things the old fashioned way.

That's a nonsensical statement, Arcanaville - what is the point of TELLING us that the maximum size is 100k if that doesn't correspond to anything we can measure ourselves? Given that approach they might as well say the maximum size is "100%" on the little meter, which it theoretically is but practically isn't... no more than the maximum filesize is 100,000 bytes. I have a non-reduced mission that is 92% in the editor, and 105k on disk.

The only rational explanation is that 100k was an estimate they gave based on some level of trial and error with the system, since it corresponds directly to nothing we can measure.

Shrinking the file does have a positive effect - it will take most storyarcs that go slightly over the maximum limit and allow them to be published successfully - this has been tested and requires no confirmation by you. What WOULD be helpful is thoughts on what changes DO affect the result and which do not.

Toril - what's the pre-reduced filesize on your arc, and how many custom critters? You can ignore the errors you see in the editor when you open an IGOR file in the in-game editor, though. If you're worried that its actually removing things, put one of the missions from your arc into its own 1-mission arc, make sure the publish button is lit for it, then IGOR it and test it to see that everything is still in place even though the editor will say things are missing. Something IS missing - bloat.

To go for broke on the reduction, it pulls out the referencefile lines (which do nothing but make a link between each of your custom critters and their original files... which we DONT want in this case). The bosses are not removed at all, but as was stated previously, you'll see a slew of errors if you open it in the editor after IGORing it. Most notably statements that custom enemy name or custom group names are missing. They're not missing until the editor loads the storyarc and finds the critter file links missing.

Yes, one of the things IGOR does is remove hard spaces which each use up 6 bytes. HTML, as you see from your posting, only does one actual space in a row... after that each space becomes   -- which is a giant waste of space if you're already over the filesize (?) limit.

This is only the beta. Once everything is settled I can but in configuration options that let you choose which reduction actions you want taken, or not taken, if you're finding you have an absolute need for hard spaces.

Its important that, when you report errors, you mention whether they're errors during publishing or errors when you open the resulting IGOR file in the editor. The latter is going to happen, the former is where we need to be concerned.

As to the question about "does this mean we can never edit the file?" -- yes, that's what it means currently, though IGOR does not alter your original storyarc! It creates a new copy of it that is reduced. So, if you need to edit your story arc... edit the original then re-IGOR it. Its possible to do a lot of reduction while still leaving the IGOR file in a format that will not give errors... but if you edit it and re-save it... it'll be back to full size, so... best to publish the IGOR versions, but work on your original versions.

The publish button is unrelated to how things are stored on the server side - its very likely (though obviously not recommended) that forcing publish to be enabled would let you post stories of any size. The checks that we're dealing with are entirely client-size.

The issue is that the devs have stated there is a 100k limit, but this is really an abstract estimate - sometimes your filesize will be larger than 100k and it won't mind, sometimes it'll be much smaller and still mind. There are even things that the client-side filters trip on that isn't mentioned (filename length, for example) in the errors list... all that happens is publish and test grey out.

While NCSoft can simply declare things to be against the rules on merit of owning the system, the EULA thing is, from a legal standpoint, garbage. There is no such thing as a proprietary file format. There are such things as patented algorithms, and copyrighted materials. Neither of these apply to this. They don't, in fact, apply to the pigg files either beyond the fact that unless you change ALL the contents of a pigg file, you can't redistribute the results without violating their copyright on the things you DID NOT change. That's neither here nor there for this case, but I figured I'd point it out since that stickied thread on every forum grates on my nerves for giving illegitimate reasoning for what is just an arbitrary decision.

I will continue to investigate the *real* storyarc limits based on the info folks have generously provided in this thread. So far I'm hearing that 17 critters works in an IGOR'd file, so I'll see what shakes out of that.

Thanks again folks!

Its not looking hopeful on that, I'm afraid - it seems to have some sort of maximum custom critter limit. I tried making a single custom group with every custom critter I'd ever made and then stuffing that into a one mission story with none of the optionals filled in.

The result is a 151k storyarc file that shrinks down to a 38k IGOR file. The publish button remains dark for that puppy.

Can you give me a count on the number of custom critters you have in your arc? I'm going to see what I can find as far as that goes.

Well, the problem is that a lot of the sets that are thematically appropriate for minions... are rough in the hands of minions. The real solution lies in them working on how critter powersets work. Ie, the tanker attack sets need to be SCALED DOWN damage wise, and the special abilities inherent to the sets need to be removed.

Minions.. even Lts... don't need to make critical strikes, nor be able to attack through holds.

The more I get to know the MA system, the more hastily thrown together it seems on an internal level. I think they need to just hunker down and do the work to make things run as people would assume they'd run as far as custom mobs go.

For the time being, if you want content that is accessible to low level players... use standard villain groups that don't get all these strange and unexpected boosts from their inherent powersets.

Ok, those two issues should be fixed - sorry for the delay. Family gets my evenings

Haha, something I didn't think about when I told it to remove spaces after commas in the color fields. Capitalization will be something similar - I shall fix.

It is, however, interesting that the arc that didn't work with previous versions works with the current version. I assume nothing but the IGOR version changed since then?

I'm starting to think there may be a maximum custom critter or maximum group limit on files, regardless of how small they are. The 100k thing is actually misleading in that even without reduction, some files over 100k still show as less than 100% while some that are under (as we've seen) show as over.

There is also a difference between what the COx client will accept and what the servers will accept - portions of the file you can remove and still have it work fine, but those same portions removed will crash the client or cause an error if you were to try loading, say, a .costume file with those same parts removed.

Looks like there's some unpleasant trial-and-error to be had as far as this goes. At the moment even with super-stripping turned on (gets almost every arc file down to just slightly over half its original size) the publish button is staying greyed at around 130% sized arcs.

Since two people mentioned arcs that worked reduced to 71k and arcs that did not work reduced to 70k, there's obviously a variable in here that is being overlooked. The above are my guesses for the moment, but if anyone else has ideas I'm all ears.

For the time being I'll go back and put in all the stripping (the slower version) including the stuff that will work on the server side but give ou a slew of orange errors if you go back and edit the IGOR arcfile. That'll give a better starting point for looking into things.

The minion choices are a bit rough, especially when you consider that an Empathy or Pain Domination lt will, as its first action, drop Clear Mind (or equivalent) on one of the minions, making it controller-proof.

You typically don't want to give minions (that you plan to be... minion-easy) tanker sets of any sort. Improved defense or resistant makes the minions harder-than-expected to kill, and tanker secondaries do a ton of damage when given to mobs - the numbers on tanker attack powers are built around the scaling down of damage that tankers have - something mobs do NOT have.

Consider giving the minions standard level scrapper regen as the secondary (which has no visible signs and doesn't make them harder to kill) so as not to make them scary.

Giving control powers to mobs is a great way to exclude low-level characters. Most have no way of dealing with them, and if control is the mob's only attack then it'll be stacking those holds and immobilizes on people. Its not atypical to have a lt in every single group, which makes using inspirations to deal with holds less feasible (especially at lower levels where you can't hold that many).

Also, as stated, consider the Assault powersets from dominators rather than blaster primaries. Anything with a blaster primary can still shoot through holds which is rough on controllers or groups that rely on control for damage mitigation.

And yeah, end drain stinks nomatter how thematically appropriate electricity is

Did you, by any chance, use the "Reduce a Story Arc" method from the file menu for the ones that aren't working? It looks like I forgot to have that one do the numbered filenames like the Reduce All option does. If the filename is too long (which is what numbering was made to fix) then the publish button is greyed out.

Why it cares about the length of the filename when that isn't part of what is submitted to the server... I don't know... but it would explain the publish issue.

I've fixed the program to use the proper numbering stuff for both All and individual reduction, also sped up the reduction a tiny bit, and made it skip everything but the costume aspects for the time being. There's additional shaving added so the resulting IGOR file should be smaller than before. Let me know if that fixes the problem! Thanks!

That won't actually help with the final filesize - the full critter file for each custom mob you use is going to end up in the storyarc file regardless of how you organize them in the groups.

In fact, putting them all in different groups increases the amount of space they use, since each group gets its own group header.

So, while its good practice to separate custom mobs into different groups if you want to control which will spawn in normal groups and which will spawn in special groups, it doesn't help people whose ultimate filesize is too large.

The vast majority of the space used by custom critters is the costume data, and the costume data (which is just a .costume file, essentially) is very wasteful. You can cut a custom critter's size by about 50% by yanking out fields in the costume definition that are not required by the program.

I made a program that does this (IGOR) - its important to do the editing on the final storyarc file, not previous critter or cvg files, though, as when COH saves things it saves them bloated.

http://boards.cityofheroes.com/showf...umber=13380801

Hope that helps.

Fixed

Figures! For some reason its leaving you with red files when it creates its IGOR files. If you open the file in notepad or wordpad and just hit SAVE, it fixes it. I'll see if I can find this new glitch and update the ZIP file once I do.

I'm now running a public beta test of IGOR (Internal Game-Object Reducer) which is a small program I whipped up that strips out unneccessary portions of .storyarc files (primarily useless portions of the costume file additions) and leaves you with a storyarc file that is usually drastically smaller than you began with without a loss of content.

The program creates IGOR copies of your storyarcs which can be published (even if your storyarc is too big normally) without any changes. Its important to note that if you do open the IGOR copy of your story arc, it'll still claim its too large to publish, and if you subsequently SAVE it, it will once again be too large.

I'm hoping some folks who have oversized mission arcs can give this a whirl and see if it does the trick for them, and then post to this thread with the results.

So here's the ZIP of the beta of IGOR:

IGOR v1.0 (beta) Storyarc Reducer

Thanks for the help!

Why not just build off what is already there? I assume you've actually played through the Vanguard arcs, so you know some of the existing rikti story.

It doesn't seem at all unlikely that Nemesis would continue his attempts at virtual godhood despite having been thwarted by heroes this time. Even if the conflict between the rikti and earth were settled once the war was found to have been orchestrated for a separate, sinister purpose, the fact remains that a very real threat to the entire rikti race exists in the form of one or more beings originating from our dimension's earth.

If Nemesis made further attempts, failed, but remained at large on present earth, it would give compelling reason, eventually, for the rikti to destroy this dimension's earth for no reason other than to permanently stop the danger it represents to them.

It also gives room for decent storytelling, as the attempted genocide can be seen not as a simple act of evil, but as an act of desparation by a race that can find no other solution to the greatest danger it has ever encountered.

Heh, I'm with you on the dialogue, Crazy. When I think Voodoo Priestess I think Minerva from Midnight in the Garden of Good and Evil who has a heavy accent and periodically breaks conversation to scold nearby skulls for giving her the evil eye.

There are few things LESS fun than overly accurate representations of things in a pulp setting. Since you're trying to make a horror story, you might consider stepping FAR away from real voodoo and working the pulp angle.

What does the average person think about when they think "Voodoo"? Dolls with pins in them, zombies, skull masks, and haiti. Run with that, because that's what pulp is about.

So my advice is to have her simply say she's a voodoo priestess (full stop). People can relate to that without any specialized knowledge, and adding words they typically don't know (houngan, mombo, bocor, etc) doesn't really enhance the experience, nor will they retain any of it past the end of the mission.

While I don't necessarily feel that there should be an automagical flagging of missions, I do think designers should at the very least warn potential players of their use of EBs and AVs.

I played a Kobold arc that had an EB in the very first mission, then multiple in mission two... Kobolds! I don't think kobolds should be capable of elite bosses, much less AVs... and it just got worse from there.

All MA designers think theirs is the EPIC storyline, and thus has cause for EBs and AVs... but really, the average mission set has ZERO EBs and AVs in them. Please - stop the insanity!