.STORYARCs show diff filesizes on different PCs..?

[ QUOTE ]
1. Backup your MA directories (which you seem to have already done) and then delete them from both computers. Then copy *only* the mission storyarc file to both computers, and see if they show the same discrepancy. The question is whether the problem is actually in the mission arc file or in something related to how the MA resolves references.

[/ QUOTE ]

I can do that, sure.

[ QUOTE ]
2. If you don't mind someone looking at your source code, I can try to analyze the storyarc file to see if there is something in it that might be behaving oddly by testing it on a variety of systems. Contact me directly if you want me to take a shot at that.

[/ QUOTE ]

I can do that too. Let me try suggestion 1 first tho. And, to Xenite: The two versions between the laptop and desktop are up to date and pointing to the live servers.

---

For more fun, I switched from editing an arc on my Mac to editing on my PC, and the file size dropped nearly 30%.

---

[ QUOTE ]
I would need more information to form a hypothesis there.

[/ QUOTE ]

I don't know if this ties into the same issue, but I have experienced a jump in files sizes on different systems. I've probably edited my arcs on a greater number of different computers than most (home computer, work computer, any of 3 different computers over at an SG-mate's home)

The memory required for my arcs was always higher on XP machines than on Vista machines, or on my old Windows 2000 machine at work. It got to the point that once I was over 90% on the Vista machines at friend's house, it was over 100% and unpublishable at home. I have to make a trip to said friend's house to edit my arcs at this point.

It was pretty consistent too. One memory reading on Win2000 or Vista. A higher number on my XP machine at home or XP machine at my friend's house.

---

I'm a published amateur comic book author: www.ericjohnsoncomics.com
******MA Arcs****
Arc 5909: "Amazon-Avatars"
Arc 6143: "Escalation" (Nominee: Architect Awards, Nominee: Player Awards, and Dev's Choice!)

Another shot in the dark: are you editing the files from the same account and the same character?

This suggests another test: try copying the entire City Of folder - not just the Mission Architect files, but everything - from one computer to the other. Maybe there's some character or account specific information that's getting attached to the mission; we know some of that is stored locally.

---

And for a while things were cold,
They were scared down in their holes
The forest that once was green
Was colored black by those killing machines

[ QUOTE ]
[ QUOTE ]
I would need more information to form a hypothesis there.

[/ QUOTE ]

I don't know if this ties into the same issue, but I have experienced a jump in files sizes on different systems. I've probably edited my arcs on a greater number of different computers than most (home computer, work computer, any of 3 different computers over at an SG-mate's home)

The memory required for my arcs was always higher on XP machines than on Vista machines, or on my old Windows 2000 machine at work. It got to the point that once I was over 90% on the Vista machines at friend's house, it was over 100% and unpublishable at home. I have to make a trip to said friend's house to edit my arcs at this point.

It was pretty consistent too. One memory reading on Win2000 or Vista. A higher number on my XP machine at home or XP machine at my friend's house.

[/ QUOTE ]

I'm wondering if someone experiencing the problem has specifically conducted this experiment:

1. Take a mission arc file, call it testArc, and copy it to another computer that is known to exhibit the issue.

2. Open testArc on the initial computer in the MA, note the size, and then save it to a different file name: call it ArcA.

3. Open testArc on the second computer in the MA, note the size, and then save that arc on that system to a different file name: call it ArcB.

4. Assuming that the memory footprint is different in those two cases, copy the ArcB file back to the original computer.

5. Without opening either ArcA or ArcB again, binary diff the two files. Are they identical even after this sequence?

---

[Guide to Defense] [Scrapper Secondaries Comparison] [Archetype Popularity Analysis]

In one little corner of the universe, there's nothing more irritating than a misfile...
(Please support the best webcomic about a cosmic universal realignment by impaired angelic interference resulting in identity crisis angst. Or I release the pigmy water thieves.)

[ QUOTE ]
Another shot in the dark: are you editing the files from the same account and the same character?

This suggests another test: try copying the entire City Of folder - not just the Mission Architect files, but everything - from one computer to the other. Maybe there's some character or account specific information that's getting attached to the mission; we know some of that is stored locally.

[/ QUOTE ]

1. Yeah, I'm consistently editing my arcs from my main, Dr. Turgenev. I dunno why, I just like the way he looks when editing on the MA tablet. XD

2. Hrm. When I first set up the app on my laptop, I copied over, but that was about a month ago? So it's not a perfect copy of all the game system files: Video preferences are different, screenshots folder is different, some of the playernotes files are out of sync, that sorta thing. I could try a raw copy though, I have time this weekend.

(Well, after I publish the blasted Act. )

---

[ QUOTE ]
I'm wondering if someone experiencing the problem has specifically conducted this experiment:

1. Take a mission arc file, call it testArc, and copy it to another computer that is known to exhibit the issue.

2. Open testArc on the initial computer in the MA, note the size, and then save it to a different file name: call it ArcA.

3. Open testArc on the second computer in the MA, note the size, and then save that arc on that system to a different file name: call it ArcB.

4. Assuming that the memory footprint is different in those two cases, copy the ArcB file back to the original computer.

5. Without opening either ArcA or ArcB again, binary diff the two files. Are they identical even after this sequence?

[/ QUOTE ]

I'm at work right now, but I'll email my friend with the house-of-many-computers. Since we've seen the behavior over there, he should be able to run the test.

---

I'm a published amateur comic book author: www.ericjohnsoncomics.com
******MA Arcs****
Arc 5909: "Amazon-Avatars"
Arc 6143: "Escalation" (Nominee: Architect Awards, Nominee: Player Awards, and Dev's Choice!)

[ QUOTE ]
[ QUOTE ]
The short answer?
File size measures the size of a computer file. Typically it is measured in bytes with a prefix. The actual amount of disk space consumed by the file depends on the file system. [/b]
i.e. depending on how the drive is formatted, and designed, will make a file be a different length on a different drive.

[/ QUOTE ]

There's a big difference in the logical size of a file and the "physical" size it requires on storage media, filesystem architecture, etc.. Data applications should never care about the physical size, and indeed are typically completely blind to it. If I load a plain text file containing nothing but 10,000 ASCII letter "X"s into a programming text editor, that file will be exactly 10,000 bytes long no matter what storage media I store it on or even what OS I store it on. Nothing that is not an OS or disk management tool should ever know that the file might actually be taking up 11,264 bytes of storage on my disk drive due to NTFS's block size.

In short, whatever is up, that is most assuredly not it, or some CoH dev doesn't have enough to do if he/she is determining how much filesystem overhead the mission files incur on our individual systems.

[/ QUOTE ]
Thank you.
I agree with all your data. (But you actually repeat my main point. Yes, the TextLength, and the FileSize, are only loosely similar.)

But you are disregarding that I covered that in my conclusion: [ QUOTE ]
So yes... IF you are working on an MA arc that is pushing the limit . . .
AND (IF) the MA system is accepting the file size your local machine is reporting, rather than the size the MA file will be when saved on the server, . . .
then the difference from machine to machine can be quite significant.

[/ QUOTE ]
You are trying to deny my argument, but to do so, you had to pretend that I had not included those "IF" clauses that I did clearly include in the conclusion.
It appeared that the physical filesize reported by the local machine was almost the only possible logical variant in this case. (The serverside reformatting, like the &nsbp and such, should happen from both local machines, and should not be a variant in this case.)



But, it seems from what Arcana said, that the local physical size reported does not matter, and that has been previously tested. So I am going to be interested to see what other things are affecting this problem.

.

---

I performed the tests on two different arcs. The arcs were created on a Windows Vista machine, then transferred to a Windows XP machine. The first arc had no custom characters or groups, the second had custom characters and a custom enemy group.

On the first arc:
testArc (16.17% = 13,981 bytes)
ArcA-vista (16.17% = 13,981 bytes)
ArcB-xp (16.17% = 13,981 bytes)

On the second arc:
testArc (*% = 118,655 bytes)
ArcA-vista (100.37% = 126,262 bytes)
ArcB-xp (92.48% = 118,627 bytes)

The percentage for testArc matched that of the arc saved on the particular machine.

Doing a diff on testArc and ArcB-xp showed the only difference to be a BossAnimation (ChickenTug) was removed in ArcB-xp. That's because testArc was created while ChickenTug was still a valid animation and it got automatically removed on loading testArc.

Doing a diff on ArcA-vista and ArcB-xp showed that ArcA-vista had a custom character that I had removed from the VillainGroup for the mission.

The critter and cvg files for the custom character and villain group on the vista machine still show the character I had removed from the group as still being in the group, but testArc and ArcB-xp did not have the character in them.

The problem seems to be that the critter and cvg files get reloaded if they exist on the machine, even if they no longer match those in the storyarc file.

----
@Mass Transit
(The friend with the house-of-many-computers)

---

[ QUOTE ]
[ QUOTE ]
AND (IF) the MA system is accepting the file size your local machine is reporting, rather than the size the MA file will be when saved on the server, . . .
then the difference from machine to machine can be quite significant.

[/ QUOTE ]
You are trying to deny my argument, but to do so, you had to pretend that I had not included those "IF" clauses that I did clearly include in the conclusion.
It appeared that the physical filesize reported by the local machine was almost the only possible logical variant in this case. (The serverside reformatting, like the &nsbp and such, should happen from both local machines, and should not be a variant in this case.)

[/ QUOTE ]

No mainstream modern operating system should report the file size of a file containing 10,000 ASCII representations of the letter "X" as anything other than exactly 10,000 bytes. Filtering for the subset of Windows operating systems on which you can play CoH absolutely and completely eliminates any possibility that this is in play, unless as I intimated, some MA programmer actually called some other completely different API. I know of no simple streams/file API on Windows which would report the underlying physical storage size of a file - to my knowledge you would have to interrogate the storage subsystems to learn this information.

In other words, my point was that while this may be technically possible, I consider this vanishingly likely as the explanation.

---

Blue
American Steele: 50 BS/Inv
Nightfall: 50 DDD
Sable Slayer: 50 DM/Rgn
Fortune's Shadow: 50 Dark/Psi
WinterStrike: 47 Ice/Dev
Quantum Well: 43 Inv/EM
Twilit Destiny: 43 MA/DA
Red
Shadowslip: 50 DDC
Final Rest: 50 MA/Rgn
Abyssal Frost: 50 Ice/Dark
Golden Ember: 50 SM/FA

[ QUOTE ]
The problem seems to be that the critter and cvg files get reloaded if they exist on the machine, even if they no longer match those in the storyarc file.

[/ QUOTE ]

This is correct. I have experienced this to my frustration several times. I have seen this result in a custom critter being loaded twice - once as defined in a misson, and once as defined in my critter folder.

---

Blue
American Steele: 50 BS/Inv
Nightfall: 50 DDD
Sable Slayer: 50 DM/Rgn
Fortune's Shadow: 50 Dark/Psi
WinterStrike: 47 Ice/Dev
Quantum Well: 43 Inv/EM
Twilit Destiny: 43 MA/DA
Red
Shadowslip: 50 DDC
Final Rest: 50 MA/Rgn
Abyssal Frost: 50 Ice/Dark
Golden Ember: 50 SM/FA

[ QUOTE ]
[ QUOTE ]
The problem seems to be that the critter and cvg files get reloaded if they exist on the machine, even if they no longer match those in the storyarc file.

[/ QUOTE ]

This is correct. I have experienced this to my frustration several times. I have seen this result in a custom critter being loaded twice - once as defined in a misson, and once as defined in my critter folder.

[/ QUOTE ]

The thing is, that's the behavior you want if you're sharing a custom critter among multiple story arcs. Otherwise you'd have to hand-edit the story arc file on one or more of the arcs sharing the custom critter. Likewise, if you edit a critter outside of any particular story arc, you want story arcs to show the changes you made.

It's a little weird, but I don't have a suggestion for alternate behavior that wouldn't be worse than what we have now.

---

And for a while things were cold,
They were scared down in their holes
The forest that once was green
Was colored black by those killing machines

[ QUOTE ]
The thing is, that's the behavior you want if you're sharing a custom critter among multiple story arcs. Otherwise you'd have to hand-edit the story arc file on one or more of the arcs sharing the custom critter. Likewise, if you edit a critter outside of any particular story arc, you want story arcs to show the changes you made.

[/ QUOTE ]

I'm confused. What you're describing is essentially what I want to happen. I want everything to resolve to the locally defined critter definition. However, if anything is out of synch, it actually shows you a duplicate entry for each version of the critter with no way to tell which is coming from what source.

IIRC, this is exacerbated if you actually save a custom group file that contains custom critters with that group name in their definition. So if I make a critter Bob hardcoded as a member of group A, and then also save a custom group named A, I end up with two definitions of Bob. One is the standalone definition of Bob and the other is now a snapshot of the standalone Bob at the time I saved the custom group.

Additionally, if Bob gets published in an arc, and then I modify his standalone defintion, if I open any arc he was published in I see yet another Bob in my list - the one that's in my arc and the standalone one. This persists until I republish the arc (or resave, for test arcs) , at which point the arc is updated with the standalone copy.

I actually found myself in the situation where I had 3 copies - one standalone, one in a custom group and one in an arc instance. If I recall, it kept updating my arc with the copy from the custom group, which was confusing the hell out of me because it didn't contain changes I was making to the stand-alone critter. I didn't actually know that the custom group contained a complete definition of the critter till I went digging around for the source of the issue. My solution was to delete the custom group, because it was redundant, since the custom critters declared the group membership directly.

---

Blue
American Steele: 50 BS/Inv
Nightfall: 50 DDD
Sable Slayer: 50 DM/Rgn
Fortune's Shadow: 50 Dark/Psi
WinterStrike: 47 Ice/Dev
Quantum Well: 43 Inv/EM
Twilit Destiny: 43 MA/DA
Red
Shadowslip: 50 DDC
Final Rest: 50 MA/Rgn
Abyssal Frost: 50 Ice/Dark
Golden Ember: 50 SM/FA

[ QUOTE ]
[ QUOTE ]
[ QUOTE ]
The problem seems to be that the critter and cvg files get reloaded if they exist on the machine, even if they no longer match those in the storyarc file.

[/ QUOTE ]

This is correct. I have experienced this to my frustration several times. I have seen this result in a custom critter being loaded twice - once as defined in a misson, and once as defined in my critter folder.

[/ QUOTE ]

The thing is, that's the behavior you want if you're sharing a custom critter among multiple story arcs. Otherwise you'd have to hand-edit the story arc file on one or more of the arcs sharing the custom critter. Likewise, if you edit a critter outside of any particular story arc, you want story arcs to show the changes you made.

It's a little weird, but I don't have a suggestion for alternate behavior that wouldn't be worse than what we have now.

[/ QUOTE ]

Yes, this is one of the ways that things can get messed up even on a single machine, much less transported between machines, which is the main reason I suggested testing the storyarc file itself in isolation.

This is one of those features that I'm not sure I'm all that thrilled with, because I don't like unannounced unconfirmed background changes in general, and also because the editor doesn't provide the logical alternative when that behavior is undesirable (which would be to use a "copy" of the referenced group or critter, rather than use it directly).

---

[Guide to Defense] [Scrapper Secondaries Comparison] [Archetype Popularity Analysis]

In one little corner of the universe, there's nothing more irritating than a misfile...
(Please support the best webcomic about a cosmic universal realignment by impaired angelic interference resulting in identity crisis angst. Or I release the pigmy water thieves.)

Update: I stripped out all the contents of my critters and group folders, and just have the raw arc in the mission folder. File size went from 104% on my home PC down to 97%. Do the same thing on my laptop, and I show 100.00%... I'm afraid to add a period to a sentence...

I've passed the arc file to another user for review, so let's see what she finds using the power of math. (Name that superhero!)

---