Size Matters - making the most of 100k

Excellent Guide. Very helpful for carving down those arcs that are bordering on too big.

I also have a suggestion to push to the Devs( Unless 3 of the Arc's i have been messing with have been exactly 100%) - could we please see how much over 100% we are, so i know if i just need to cut a few words here are there, or start deleting Custom mobs.

[ QUOTE ]
I also have a suggestion to push to the Devs( Unless 3 of the Arc's i have been messing with have been exactly 100%) - could we please see how much over 100% we are, so i know if i just need to cut a few words here are there, or start deleting Custom mobs.

[/ QUOTE ]
Exactly what I was thinking - and I suggested as much yesterday in the feedback thread.

It would not only help us identify how much fat we need to trim, but could also identify any problems with the size calculation. i.e. it's possible that when it says 100% it's actually hit some bug and thinks it's an incorrect figure such as 20000%...

My guess would be that the numerical percentage used may be the exact same figure being used for the size-bar graphic, and that the size bar limits to 100.00% so they've also limited the numerical display. Should be easy to alter, even if it needs another variable and a max/ceiling function.

I could be wrong, but there is a space for a bio for your contact, certainly for custom ones. This seems a waste of space since "Follow" is the only option if you right click on the contact.

I have to admit, I've yet to reach the 100kb limit on my mission arcs, despite a large custom group, 5 missions and plenty of advanced mission goals.

100k seems actually very generous at the moment. Having multiple custom groups would easily push it over the edge though, since my single group adds at least 50% to the total file size. Probably wouldn't be so bad with two smaller groups though.

[ QUOTE ]
I have to admit, I've yet to reach the 100kb limit on my mission arcs, despite a large custom group, 5 missions and plenty of advanced mission goals.

100k seems actually very generous at the moment. Having multiple custom groups would easily push it over the edge though, since my single group adds at least 50% to the total file size. Probably wouldn't be so bad with two smaller groups though.

[/ QUOTE ]

I made a custom villain group with 3 types of minion, 3 types of lieutenants and 3 types of bosses - that pushed the size to 50%+ even before I had started on filling out any mission details.
But as others have pointed out - when looking in the text files created for custom critters, there seem to be a lot of waste in terms of tag overkill.

Whoops!

Ok - I notice that in the US it's been pointed out that black doesn't save anything other than disk space - the internal arc space used is the same regardless of colours used.

It sounds right, as it really would be poor if the colour affected size - but since the sizing bar seemed to often supply 'percentage used' figures that seemed variable even for a single arc with no editing it had been hard to ascertain just how much space was used when I wrote the original thread/guide.

As such using the file size as an indicator didn't seem too far a stretch...

With yesterdays patch the percentage used indicator seems a lot more stable, and I've verified the US posts and can confirm that the colour of costume pieces does not affect the internal size of your arc - so it doesn't matter what colour you set things to.

Of course, this doesn't mean that the costume format is efficient for arc purposes (regarding unused costume parts) - though since we don't appear to be able to load costumes without the apparently superfluous parts it may be hard to verify this either way. Darn shame as that (rather than the colour) was always the part that I suspect the largest savings could be made.



Hmmm.... maybe the heading at the top should be Whoops (part 1)! in anticipation of further corrections!

I was intending to revisit, edit & repost any info I did once beta was over anyway - I've always said that I'll make mistakes and beta gives a moving target that might not be the same as live.

[i]btw - really wish for beta we'd had common boards...[/b]

UPDATE:

Time for me to call it quits for the night, but I have gone on to reverify that:
* Trigger/objective names do count against the arc size reported by the MA editor
* ambush and patrol names (which aren't even seen by the player) also count to the arc size

So the tips about naming (i.e. use short names, especially on objectives used as triggers) still appear to hold true.

Also self-debunked:
* mission failure text creating an internal/reported arc size saving.

I'll try and get around to checking costume pieces and standard mob factions (and anything else I notice) against the reported arc size tomorrow.

Apologies for any confusion that inacuraccies/errors on my part may have caused.

Ok - so I made some errors, but being tenacious I've gone through the tips/tricks and verified or debunked them.

When MA goes live I plan on re-checking and updating/replacing the thread/guide - and then this will probably be the appendix that gives more facts and figures than many peopl ewould want, but helps peopl eto verify/debunk my tests. 'til then it can all change, so not much point spending too long re-checking.

Note that I've not yet revisited the JDAG sizings - I think that that can wait until we have the live build, else I could just end up rechecking every few days.

BTW - before reverifying that they work, the tips did help me trim about 1% off one of my arcs. OK - the arc was at about 107% so I also had to drop 1 mob... though I may revisit it sometime and see if I can't jiggle him back in.



Appendix - corrections and verifications

I admitted in the first version of my thread/guide that there was lots that I didn't know. And it didn't help that the MA editor arc size display (the bar and %) seems to be based loosely on fact with some sort of random number added at the end.

As such I took the filesize to be a fair indicator of arc size - not so much because I thought that the arcsize was the filesize but because filesizes are something that could be verified and if there's extra info going in a file then there's probably extra info taking up arc space. The two may not be equal, but in the absence of other reliable data assuming that there's a corelation allowed some guesstimates to be made.

It also seemed a fair assumption given that the MA editor arc size indicator is labelled 'FILE SIZE:' but even fair assumptions are just assumptions, and you know what they say...

Since I first posted this, the MA editor arc size indicator appears to have become a lot more reliable, and so further tests have been possible to work out what effect different elements have on the arc size.

I got some things wrong - Some of the things that affect filesize do not affect the 'internal' arc size.

I got some things right - Although, if I stated the size of effect I wasn't always right.

Some things are still essentially unverifiable. I'd guess that apparently unused costume pieces in custom mob data does have an effect, as c. 6k of internal arc size per custom mob seems a large amount. But investigating this is difficult as comparing data with and without these excess blocks is beyond the player.

So, until MA goes live and I revise the whole thing, heres a general update:




Things I got wrong, that have changed or been clarified

* 100k of what?
In the US, Arcanaville has established that the space limit is 100,000 bytes per arc.

Now that the MA editor arc size indicator seems reliable, you can easily verify this yourself by noting how the size indicator changes as you add characters to a large text field.

e.g. if you add characters to an empty arc mission 1 Introduction Dialog until the arc size just ticks over to 0.35% and then add 500 characters (which should take up 1 byte each) you'll see the arc size now reads 0.85%. If 500 bytes is 0.5% then the storage is 100,000 bytes.

Ok - slightly simplified, as there is what appears to be an odd rounding error. So a reported jump of 0.01% can take 9, 10 or 11 characters - but repeated testing indicates that the stated size of 100k is 100,000 bytes.



* Black saves space
Only in the files on disk... In the internal arc size it doesn't matter what the colour is - black takes up as much space as white.

Again, it was Arcanaville who debunked this in the thread linked above.

But checking for yourself is easy:
- Create 2 custom groups with exactly the same mobs but one is dressed all in white the other all in black. Just to be safe, make sure that the groups/mobs names are the same length (e.g. I used 'b1' and 'w1' for the black and white counterparts)
- Create 2 arcs identical except that one uses the white group, the other the black group.
- Examine the reported arc size usage of each arc - they should be the same.

E.g. For my check, I had custom groups with 5 custom mobs in them. The sizes reported (both on disk and the internal arc size) are:
Black - disk: 36,660 bytes - MA arcsize: 29.07%
White - disk: 39,930 bytes - MA arcsize: 29.07%

So the file size saves c.3.3k but 'so what?' - the arc is still the same internal size.

And as the MA editor arc size had previously shown variable sizes for arcs without editing (almost as if the sizing wasn't resetting or it was measuring something akin to a memory leak) I also restarted the client and checked the arcsizes again (checking in reverse order this time). The arc size reported appears to be unchanging.

I'm actually quite glad to be wrong about this - it suggests that a fixed length colour encoding (such as 3 byte RGB triplets) is being used, whereas it would have been very poor if my initial thoughts that black was more efficient were correct.

I haven't checked but I would also imagine that the same is true for character scales - that they are probably held internally as some form of floating point and the variable length seen in text files is used purely for external file storage.


* Having a 1-character Mission Fail dialog is slightly better than having no fail dialog
Again it saves a tiny amount in the files as a single letter is 1 byte shorter than a pair of double quotes (e.g. A is shorter than "").

But the MA editor shows that something in the fail dialogs takes up more space in the arc size than having nothing.

You can see this by:
-- create a test mission (any test mission)
-- make sure that the 'Mission Fail Popup' and 'Return Fail Dialog' (on page 1 of the mission under Additional Text) are both empty (a current bug sees them having default P strings).
-- Add letters to the mission introduction text until the arc size % indicator ticks over to the next value (e.g. 0.83% goes to 0.84%).
-- Delete a single letter from the text you added, so that the arc size % indicator drops back down (e.g. from 0.84% back to 0.83%).
-- You know know that adding even a single byte to the arc will cause a change in the arc size % indicated.
-- type a single letter in either 'Mission Fail Popup' or 'Return Fail Dialog', the arc size % indicator will alter showing that the internal size has increased.

Note that this is the sort of test that I'll be using to try getting internal sizing info. By modifying the long text strings (e.g. Mission Introduction Text) you can even get an idea of how many bytes were used. E.g. a single fail text/dialog can be countered by removing 2 characters from the mission text - so it seems that populating a mission fail text takes (1 + text length) bytes - I'd guess at the 'extra' byte probably being a string terminator.


Tests for things I seem to have got more-or-less right, and the odd new thing

* Using Custom Mobs

We can now get a more accurate reading on how much space each custom mob takes, and looking at several custom mobs that have info attached the arc size usage seems to vary but is usually 6k +/- 0.2k.

I repeat - that was looking at several custom mobs with info that I'd created for a real arc. So they have real names, real costumes and real info - they haven't been made to test sizing.

So what do we find if we do test sizing?

I created a test character to find out.

I made the following:
- A boss
- melee preference
- no travel power
- standard electrical blast/standard energy blast (as there are no weapons involved)
- all scales left at halfway for the male model
- used the 1st costume that came up by default, which was:
--- Standard Head/Face 1/Fury hair/Human Ears
--- Tight upperbody with Tights Muscular chest and Smooth Bare.Shiny Leather gloves
--- Tight lowerbody with Tights pants and Smooth.Shiny Leather boots
--- no details/belt/shoulder pads/back detail/aura added
--- no recolouring (though colour does not matter) or textures/patterns applied
- Entered nothing for the custom character description
- called the mob 'db1'
- put the mob in 'sizetests' group

I also created copies of this with the following names/variations:
- db2 : has hair set to 'none' instead of 'Fury'
- db3 : has hair set to 'exposed brain wired + hair'
- db4 : has shoulders set to 'layered pads'
- tx1 : has 'Dots' texture/pattern on the chest
- tx2 : has 'Emblem Diamond' texture/pattern on the chest
- da1 : is an Archvillain
- rb1 : set to ranged fighting preference
- fa1 : has the 'flight' travel power
- ab1 : has an aura - Electricity.Electric body
- ar1 : archery/electrical blast (using default bow)
- ar2 : archery/energy blast (using default bow)
- sd1 : spines/devices
- db5 : has a 1-char description of 'A'
- db6 : has a 11-char description of 'A0123456789'

I added a 'fight a boss' objective to an otherwise empty arc, and without selecting any boss gave the Boss Name as 'AAA' (so it contained 3 characters).

The arc size indicator showed 0.58%

Using the various mobs from 'sizetests' gave the following (note that these are approximate as I didn't alter text fields to try obtaining precise sizes, but just used the MA designer displayed arc size):
- db1 - arc size: 5.93% - mob used: 5.35% - vs base: n/a
- db2 - arc size: 5.91% - mob used: 5.33% - vs base: -0.02%
- db3 - arc size: 5.99% - mob used: 5.41% - vs base: +0.06%
- db4 - arc size: 6.01% - mob used: 5.43% - vs base: +0.08%
- tx1 - arc size: 5.94% - mob used: 5.36% - vs base: +0.01%
- tx2 - arc size: 5.96% - mob used: 5.38% - vs base: +0.03%
- da1 - arc size: 5.93% - mob used: 5.35% - vs base: no change
- rb1 - arc size: 5.93% - mob used: 5.35% - vs base: no change
- fa1 - arc size: 5.96% - mob used: 5.38% - vs base: +0.03%
- ab1 - arc size: 6.00% - mob used: 5.42% - vs base: +0.07%
- ar1 - arc size: 5.99% - mob used: 5.41% - vs base: +0.06%
- ar2 - arc size: 5.98% - mob used: 5.40% - vs base: +0.05%
- sd1 - arc size: 5.92% - mob used: 5.34% - vs base: -0.01%

So:
* using parts (including capes/weapons/auras) does take up more space than leaving parts empty (db1 vs db4, ab1, ar1, ar2 and db1 vs db2).
* different costume parts have varying size costs (db1 vs db2, db3).
* using textures/patterns takes up more space than not (db1 vs tx1, tx2).
* different costume parts have varying size costs (db1 vs db2, db3).
* different powersets have varying size costs (db1 vs sd1, ar1 vs ar2).
* mob rank seems to have negligible effect if any.
* fighting preference seems to have negligible effect if any.
* Taking a closer look at db1 vs db5 and db6, it appears that the character info takes (1+info text size) bytes.

Note that I didn't check different body types nor did I check if primary/secondary difficulty affected sizing.


Ok - all these individual changes may not do much by themselves, but cutting down the names/info and removing a couple of textures and extra costume bits (do I need shoulder pads and a cape on this mob?) on each mob in a group of several custom mobs can make a noticeable difference.


* Custom mob names

I also created a copy of 'db1' called 'mynameislong1' - they are still in the 'sizetests' group and differ only in having a different name to 'db1'. In fact they have a name that is 10 characters longer than 'db1'.

Using them I saw an odd jump in size, so I also tried with a max length name 'mynameislong11234567'.

For the name length tests, I saw the following:
- db1 - arc size: 5.93% - mob used: 5.35% - vs base: n/a
- mynameislong1 - arc size: 6.26% - mob used: 5.68% - vs base: +0.33%
- mynameislong11234567 - arc size: 6.49% - mob used: 5.91% - vs base: +0.56%

Note that these were still using a 3 character boss name for the 'fight a boss' objective, so I should have isolated the actual-mob name from objectives.


* Trigger/Objective Names and Mission Completion

As a base, objective names (e.g. boss names, patrol and ambush names) appear to be take up about 1 byte per character (although as mentioned earlier there appears to be a rounding error affecting MA size %).

So it can be seen that adding c.10 characters to an objective name adds 0.01% to the arc size.

But the name also seems to be repeated when used in triggers or for required mission completion objectives.

E.g. I tested using a 'fight a boss' and 'ambush' objectives. In one set of tests the boss was named 'tx111' (5 characters) in the other set of tests the boss was called 'tx11101234567890123456789012345678901234567890123 456789' (55 characters, or 50 characters longer than just 'tx111').

The following shows the results with the different names using different required mission objective and ambush settings. The first column shows an 'a' if the ambush was keyed on the boss (or the boss at partial health) and an 'm' if the boss was set as a required mission objective. So '__' is no ambush (achieved by setting the ambush trigger to none) and 'am' is both an ambush and set as a required objective.

__ - tx111 - 6.84%
_m - tx111 - 6.86%
a_ - tx111 - 6.84%
am - tx111 - 6.87%
am - tx111 xx_health - 6.88% (10/11 char extra)

__ - tx111012345678901234567890123456789012345678901234 56789 - 6.89%
_m - tx111012345678901234567890123456789012345678901234 56789 - 6.96%
a_ - tx111012345678901234567890123456789012345678901234 56789 - 6.94%
am - tx111012345678901234567890123456789012345678901234 56789 - 7.02%
am - tx111012345678901234567890123456789012345678901234 56789 xx_health - 7.03%

Hopefully, if you're following my shorthand, you'll see the following:

- Adding 50 characters to an objective name adds a base value of c.50 bytes, i.e. 1 byte per character.
- It adds another c.50 bytes if the objective is required for mission completion, i.e. another 1 byte per character.
- It adds another c.50 bytes (1 byte per character) if the objective name is used as a trigger for another objective.

Adding modifiers to boss triggers (to trigger at partial health) seems to add 10/11 bytes.



* Contacts

Using an unamed default contact in a test arc, I had a base size of 6.35%

Adding a standard contact/object/Enemy group mob and not renaming (i.e. leaving the Contact name blank) raised the size to c. 6.39%, but it could be seen that varying the actual contact chosen did affect the size meter. Like a lot of things in CoX the contact is probably stored as a variable length string rather than, say, as an index into a list.

Using a custom mob (db1 from earlier) that did not appear (singly or as part of a group) in the arc already pushed the size up to 11.69%. That's 5.34% above the default size, and as db1 seemed to take 5.35% in my earlier tests I'm reasonably happy that custom mobs take up the same space here as they would as mission objectives.

Unsurprisingly, renaming any type of contact including the default hologram adds about 1 byte per character (as in many of these tests, there may be a slight overhead but small enough that I'm not going to worry about it).


Also, Dr_Toerag pointed out the following:
[ QUOTE ]

I could be wrong, but there is a space for a bio for your contact, certainly for custom ones. This seems a waste of space since "Follow" is the only option if you right click on the contact.


[/ QUOTE ]
I tested using the db1 and db6 mobs from my 'sizetests' group.

The db6 mob did indeed take more space than the db1 mob, and the only difference between these is that the db6 mob has an 11-character description whereas db1 has an empty description.

So if you use a custom contact that won't appear as a mob in any missions in the arc then using a version without any info will save some space.

Wow, suspicion confirmed by Judgement_Dave, I feel genuinely honoured!

I would also say something about extended charsets: non-ASCII characters are encoded in UTF-8. That can take up to 4 bytes for only one character, depending on the language.
For example, a new mission with a title of 75 'a' gives me a size of 0.25%.
A new mission with a title of 75 'é' gives me a size of 0.28% (2 bytes for each characters).

Ha! And using colors, font size, and the like is also space consuming, since texts are HTML formatted.

Welcome to the boards!

[ QUOTE ]
I would also say something about extended charsets: non-ASCII characters are encoded in UTF-8. That can take up to 4 bytes for only one character, depending on the language.
For example, a new mission with a title of 75 'a' gives me a size of 0.25%.
A new mission with a title of 75 'é' gives me a size of 0.28% (2 bytes for each characters).


[/ QUOTE ]
Not quite with you on that - but maybe I misunderstand what you're saying.

The difference between 75 characters each stored as single bytes and 75 characters stored as two bytes each is 75 bytes - which would be 0.075% of the total storage (100,000 bytes). If I'm reading your post right, the difference that you're reporting is 0.28% - 0.25% = 0.03% which isn't enough even allowing +/-0.01% for rounding errors.

[ QUOTE ]

Ha! And using colors, font size, and the like is also space consuming, since texts are HTML formatted.

[/ QUOTE ]
But tags are stored as text - e.g. <color #ff0000></color> takes up 23 characters of the field that it's placed in. It's treated as text for space purposes.

It'd be different if formatting/markup wasn't counted as characters using up the field count, but added to the size (i.e. if <i>Hi</i> and plain Hi both counted as 2 characters of the field used but the former used up additional space to store markup information).

As the markup is treated as text, I really don't see a 'Ha!' factor.

The last update changes my numbers. I now have 0.32% for the 75 two bytes characters version. That fits better.

My second remark was just an addon to your tips and tricks to preserve some space: Using markups costs a lot of space, so use them wisely.

being someone who likes things simple, i find this more confusing then helpful....

Question for you JD; I've opened up the mission file with Notepad looking for hidden HTML codes, and I notice that in a lot of places there's the following instead of a plain space:

 

As this is considerably longer, removing it would most likely save more space, however running a universal replacement of " " with " " seems to break the arc entirely. Any thoughts?

However opening it up under Notepad does make it easier to spot double spacing problems etc, so I'm working through it in game now, with a back up file itself open

You don't really need to read all the numbers, sorudo. That's if you really want to get your hands dirty about the space.

Basically, it's making the use out of 100kb, which may be big at first for your arc, but when you start putting custom groups in, your space is really eaten up. For example, a custom group with 3 minions, 1 lt, 1 boss and 1 AV would be almost 45% (my own research). And if you're using more than one custom group space can be a real pain. Overall, this is about how you can make the most of the space.

Simple enough?

[ QUOTE ]
Question for you JD; I've opened up the mission file with Notepad looking for hidden HTML codes, and I notice that in a lot of places there's the following instead of a plain space:

 

As this is considerably longer, removing it would most likely save more space, however running a universal replacement of " " with " " seems to break the arc entirely. Any thoughts?

[/ QUOTE ]
OK - I've had a quick look at one of my arc files that had HTML non-breaking space codes (i.e.  ) scattered in it.

Taking a copy and just doing a bulk find & replace operation does indeed break it - so I looked a little closer.

In my test (which is a small work in progress where most of the text is yet to be written) there were only 3 entries with   in them - they were the title/description part:
<font class="small">Code:[/color]<hr /><pre>
Title To&amp;nbsp;do&amp;nbsp;what&amp;nbsp;is&amp;nbsp; needed
Description blah&amp;nbsp;blah&amp;nbsp;blah&amp;nbsp;blah
</pre><hr />
And in the dialogue of a single patrol:
<font class="small">Code:[/color]<hr /><pre>
Detail
{
Name p2
DetailType Patrol
EnemyGroupType Custom
VillainGroup "Custom Group 1"
Quantity 1
Difficulty Hard
Patroller1Speech Let's&amp;nbsp;get&amp;nbsp;outta&amp;nbsp;here!
CustomVillainGroupIdx 1
}
</pre><hr />

I realised pretty much as soon as I did the find &amp; replace (to alter &amp;nbsp; to a space) that most, maybe all, other fields that have spaces in them have the field value surrounded by double quotes... Maybe that's what was needed.

I replaced the above lines with the following:
<font class="small">Code:[/color]<hr /><pre>
Title "To do what is needed"
Description "blah blah blah blah"

Detail
{
Name p2
DetailType Patrol
EnemyGroupType Custom
VillainGroup "Custom Group 1"
Quantity 1
Difficulty Hard
Patroller1Speech "Let's get outta here!"
CustomVillainGroupIdx 1
}
</pre><hr />
This now showed up ok in the 'My Local Stories' list. And it loaded fine for editing.

I checked the reported arc sizes of the original &amp;nbsp; file against the modified quoted-space file. The modified file (without &amp;nbsp is showing to be 0.04% smaller.

This seems about right for the spaces being preserved as spaces (and not replaced by &amp;nbsp; when loaded into the MA editor), as there are 10 instances of &amp;nbsp; appearing over 3 lines in the above example. So the saving should be ((10*5)-(3*2))= 44 characters/bytes.

Also editing the file in MA editor and then resaving preserved the spaces/double quotes. Though I haven't tested publishing an arc I'd hope that once &amp;nbsp; codes have been removed and replaced with spaces within a double-quoted field value that they then stay that way.

[ QUOTE ]
You don't really need to read all the numbers, sorudo. That's if you really want to get your hands dirty about the space.

Basically, it's making the use out of 100kb, which may be big at first for your arc, but when you start putting custom groups in, your space is really eaten up. For example, a custom group with 3 minions, 1 lt, 1 boss and 1 AV would be almost 45% (my own research). And if you're using more than one custom group space can be a real pain. Overall, this is about how you can make the most of the space.

Simple enough?

[/ QUOTE ]
that's what i'm talking about, simple and to the point.
thnx.

Ok, I can confirm what JD is saying;

Namely that one of the reasons mission arcs keep slightly expanding is because it's replacing a space with &amp;nbsp; which is stealing some of your file size.

You can replace this with a space again, (open Notepad, click Edit &gt; Replace &gt; Replace All, then save) and put "" around the text parts to keep the size (so far) down.

EXCEPT! Be aware that the text also uses a second set of tags, &lt;&amp;.....&amp;.&gt; around any text of your own that used "..." inside it. And inside these, &amp;nbsp; can turn back up again. DON'T change these to "..." in turn though, as this permanently breaks your mission too.

You can get around this by swapping double to single quotation marks around your speech; I gather double is the norm in the US, but in Europe it can be either...

Addendum; I've been experimenting today, and you can manually edit all the supporting files (CustomCritter etc) to remove &amp;nbsp; and then you can right click them, select Read Only, and the mission editor can still take the associated creature bios in successfully, but it CANT write &amp;nbsp; back into them. Thus keeping your arc size down considerably when published/edited; I've just seen a .20% arc saving because of one custom mob that kept inserting &amp;nbsp; back in every time it was used...

As of Issue 16, the nbsp bug is back in the game; my arc gained 0.22% from before the publish, pushing it back into uneditable territory again. To fix it, do the following;

1.) Open the published arc
2.) Save it Locally
3.) Open the file in notepad from your CoH\Missions directory.
4.) Do a search through the document for "nbsp"
5.) Using the published version, delete the spaces in the lines where nbsp appears in your local copy, and then put them back. You'll see your file size slowly decrease again...

Cutting and pasting sections of text across applications will cause character entities like the non-breaking space and non-printable characters (ASCII 0-31) to appear in your code. The best way to avoid this is to script the text or code directly into the source file -whether it be thru MA or in the underlying .txt file. (Notepad is good about stripping these characters out, but strange things can still occur). Watch out for pasting text blocks directly from MS Word -or especially, MS Excel, into MA or into HTML editors. If you use an IDE designer, use the split view to check the HTML code being generated. It may seem tedious to retype lengthy descriptions, but doing so allows proofing of the text and removes the need to run the additional Find and Replace on the source code.
I'm new to MA and haven't looked carefully at what's generated. Has anyone attempted span or div tags to format their text? If the text falls within a JavaScript function, special characters like double quotes might be allowed if preceded with a backslash -like \"Hello World.\"