Judgement_Dave
-
Posts
1902 -
Joined
-
[ QUOTE ]
Are you saying that you can't put any line breaks into custom MA critter descriptions? How about mission text, etc? Hopefully that won't have to be a wall of text?
[/ QUOTE ]
Linebreaks and <br>* tags aren't allowed in critter info since sometime last week. Just before the breaks went from critter descriptions, MA seemed to have trouble with dodgy HTML processing for display in lots of places (lots of spaces becoming &nbsp; and other problems). IIRC The fix to this came at the cost of linebreaks in descriptions - however I've taken that to be a bug rather than WAI.
In mission text you can place breaks/newlines in most pieces of text (e.g. clues, mission intro/sendoff/return, souvenirs) - so it won't all just be a wall of text.
BTW - the MA editor on test does still seem a little flakey to me - it doesn't like deleting past lines of text and it's quite common that you can type away and nothing appears until you reposition the cursor mid sentence and type a letter, at which point all the text appears.
TBH I'm expecting this and the odd other bug to be sorted before the end of next week. It's a shame that Easter is a 4 day holiday for many and so it looks like the devs had an artificially imposed deadline for launch. One more week and 1 or 2 patches would probably have seen a much better, more stable product.
* and not <br/> - CoX seems to place <br> tags in.. still it saves us a byte here and there. -
[ QUOTE ]
Would think this was added to prevent anyone from creating multiple trial accounts and voting their own arcs to inflate their rating.
[/ QUOTE ]
Maybe, just maybe, preventing trial accounts from rating other content would have addressed that issue. -
[ QUOTE ]
btw: guess we all benefit from taking SB first and buffing each other?
[/ QUOTE ]
Yes - that's what I was planning.
-
[ QUOTE ]
Woohoo! Servers finally up! I got through!
[/ QUOTE ]
I try to forget that you are Illusion Master and take every post you make on its own merits, but sadly this so often results in me concluding that such a post could only have been made by someone with the 'peculiar talents' of IM.
At least you managed not to Rick roll us all again. Small mercies. -
[ QUOTE ]
Doo doo doo doo... doo doo doo doo doo!
[/ QUOTE ]
That's a load of doo doo.
Funny - The song it's referencing also makes me think of doo doo. -
[ QUOTE ]
More to the point tho, I was concerned about how lackluster and downbeat his response to the question was. As tho the Dev team are really excited by the product but not expecting it to drive new revenue. That's a borked business model if ever I've seen one.
[/ QUOTE ]
As I read it, the dev team are (rightly) excited about this, but publicly cautious as it's pretty much untested on MMOs - so they've no real idea what sort of response it will get.
If they publicly state any number they are just setting themselves up for criticism:
State too low a number for some people and they'll either question why the devs waste their time on doing something with low appeal (i.e. which wasn't on the critics list of dev-must-dos) or why didn't they do change X, Y & Z and aim for a better response.
State too high and there's a fair chance that they might not hit the stated numbers leading to criticism that MA was a failure, devs don't know what they're doing, why didn't they do X, Y & Z instead.
Leaving it open with no publicly stated forecasts makes it easier to later claim a public success, pretty much regardless of how it performs.
Given the response so far in beta, the fact that it's pretty much untested in MMOs and that the devs got a nice and simple internal tool out of this I'd say it's already a success. And the early previews seem to suggest that the press like it (or at least like the idea of it) - so I can't really see it failing to any great degree. -
[ QUOTE ]
We've always brought these free updates that a lot of other MMOs don't do -- you have to go out and buy a boxed expansion. We do a mini-expansion three times a year.
[/ QUOTE ]
Wasn't the official target* 4 issues a year?
Is my memory failing on this or does the interview mean that they've finally, officially stepped back to 3 per year?
* official target as in stated by rednames but 2 or 3 years ago now - and a lots changed since then and this may easily have changed. -
[ QUOTE ]
[ QUOTE ]
And I dont think I ever knew anyone who didn't cheat at those adventure books!
[/ QUOTE ]
It wasnt "cheating", it was "keeping my options open"
[/ QUOTE ]
If ever I did that it was just out of concern over the fate of 'parallel-me's who chose the different individual paths. I still cry over that poor pussycat that nice Mr Schroedinger might have lost. -
No matter how many or how few players change the lightbulb it'll only need changing again. It's all a plot to force us into accepting steam-powered lightbulbs.
-
Gratz on your cakeday, Stryke. Hope it's a good 'un.
-
[ QUOTE ]
I've got to also go against anyone saying Mids is good enough to tell you how your character will play with different slots. Mids is great and all but it really doesn't compare to trying something out ingame.
[/ QUOTE ]
Firstly: I agree with this entirely. Mids is great, but the numbers don't convey how a build plays.
But there's more than that: Mids is a 3rd party piece of software.
It should not come into consideration in the least bit when the issue of respecs is considered. Many players won't have Mids (or another build program) and many won't want a piece of 3rd party software.
It'd be very different if Mids or an equivalent was provided by NC (whether as an integrated part of the client or as a standalone program) - then there would be case to argue that the tools are provided to help minimise build 'errors'. -
[ QUOTE ]
you would really be better off just filling in any spare sections of your build with normal IOs for maximum benefit.
...Unless of course Its one slotted and you prefer the pretty picture on a +42% Invention-set enhancement.
[/ QUOTE ]
Or if you want to make the most of your slots through multi-aspect SIOs giving a total enhancement equivalent to more than just a single SIO of the same level - a big part of frankenslotting.
I've slotted a few partial sets before not because the bonuses were anything to shout about but the overall enhancement was better than CIOs and the recipes/IOs were cheap at the time, on occasions cheaper than buying CIOs. -
QR
[ QUOTE ]
one of per toon
[/ QUOTE ]
AFAIK Uniques can only appear once per build (the two builds can, IIRC, have their own copies of a unique enhancement)
[ QUOTE ]
you can can repeat that Identical Invention Set up to five times in your powers that accept that kind of IO.
[/ QUOTE ]
Pretty certain that you can slot the same set in as many powers as will take it, but the same type/magnitude of set bonus only applies 5 times.
e.g. Numinas Convalescence gives a +12% regen bonus for slotting 2 of it's enhancements in a power. So if you can slot Numinas Convalescence in 8 powers you could slot the 8 powers each with heal/end and heal/recharge from the set but you would only get 5 lots of +12% regen bonus (for a total of 60%).
Each specific set bonus (i.e. a specific type and magnitude) can only stack 5 times regardless of which set gave the bonus. e.g. you can only stack 5 lot's of +5% recharge in total - you can't get 10 lots to stack by trying to get 5 from Crushing Impact and 5 from Doctored Wounds.
If you go over the 5 stackable limit, it's only the set bonus that stops being re-applied, the actual enhancement still works at enhancing the powers attributes. SO in the example above with 8 powers slotted with heal/recharge and heal/end from Numinas, the player would only get a maximum of 5 +12% regen bonuses, but all 8 powers would benefit from the enhanced heal, end and recharge.
As said by previous posters, each specific enhancement from a set can only be slotted once in any one power. Common IOs (i.e. non-set IOs) have no limits on slotting the same type in one power - so just like TO/DO/SOs you can 6 slot CIO damage if you really want, though someone called Edward may get upset at you and impose some sort of weird debuff to the total.
BTW - the stealth IOs are unique and mutually exclusive - e.g. having a stealth IO from the flight set not only stops you slotting a second flight stealth IO but it also stops you slotting a jump/run/teleport stealth IO (in that build). -
[ QUOTE ]
Ultimately I think we've finally found a really good use for the useless in-game email system with the MA feedback system.
[/ QUOTE ]
Hmmm.. maybe a rewrite...
[ QUOTE ]
Ultimately I think we've finally found another use for global tells with the MA feedback system.
[/ QUOTE ]
IIRC it was the test server patch of 23rd March that changed from using email for MA feedback to using global tells. It's a bit hard to tell for sure as this change didn't make the patch notes - but then lots of minor changes don't, especially in beta.
I don't think that they've changed back. -
[ 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:
&nbsp;
As this is considerably longer, removing it would most likely save more space, however running a universal replacement of "&nbsp;" 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. &nbsp;) 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 &nbsp; in them - they were the title/description part:
<font class="small">Code:[/color]<hr /><pre>
Title To&nbsp;do&nbsp;what&nbsp;is&nbsp; needed
Description blah&nbsp;blah&nbsp;blah&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&nbsp;get&nbsp;outta&nbsp;here!
CustomVillainGroupIdx 1
}
</pre><hr />
I realised pretty much as soon as I did the find & replace (to alter &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 &nbsp; file against the modified quoted-space file. The modified file (without &nbsp is showing to be 0.04% smaller.
This seems about right for the spaces being preserved as spaces (and not replaced by &nbsp; when loaded into the MA editor), as there are 10 instances of &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 &nbsp; codes have been removed and replaced with spaces within a double-quoted field value that they then stay that way. -
[ QUOTE ]
Issue 14 is just around the corner, as with many powers changing Issues we will be granting (1) free respec per character, on the day that Issue 14: Architect is launched.
[/ QUOTE ]
Not respec'd since dual builds, but wouldn't any character affected by changes possibly need 2 respecs to sort out both their builds?
If so, isn't it about time that the freespec limit rises to 2 (in hand at any one time) and that they grant them in pairs?
[ QUOTE ]
Looks like a week or so to go
[/ QUOTE ]
Looks like not less than a week or so to go.
-
[ QUOTE ]
Slightly unusual that they're giving it on the same day as I14 comes out; they normally leave a few day's gap so people can't waste it before they get a feel for what actually needs changing.
[/ QUOTE ]
Pretty sure that the only thing that they usually do is give forewarning.
On at lest one occasion the devs gave a frespec without forewarning (and on the day of an issue release iirc) and then gave a second a few days as people had succesfully made a case that they should have had some notice as was past practice.
So I think that they're giving warning now so that they can again apply the freespec at launch, but this time no-one can object. -
Well after thinking I wouldn't be able to make tonight it looks like I'll be there.. so just the 1 question:
[ QUOTE ]
Game time: Sundays and mondays 6 pm (19.00 CET).
[/ QUOTE ]
The UK went to daylight savings time (or BST - British Summer Time) last night...
I believe that CET moved to summertime as well (so UK is on BST or GMT+1, and CET is BST+1 i.e. GMT+2)...
I reckon that that puts tonights start at about 1h45 from now (time of posting)...
Can someone please shout up if I got that wrong! -
People go through phases with any hobby - take a break for a few weeks now and come back to try the best of I14 MA player-created content when I15 is imminent.
[ QUOTE ]
The MA is not my thing, but as they said the MA wasnt the only thing in I14, I still held out, but its looking like they fibbed yet again.
[/ QUOTE ]
I don't think the devs ever said that.
IIRC they said something along the lines of 'Architect is the main part/bulk/thrust of I14' and when people shouted 'Oh noes - I14 is just MA' some others (myself included) countered that the devs had never said that it was just MA. And past issues have often had small improvements/developments that haven't been mentioned in pre-release press as the big developments get all the attention.
i.e. the devs never said it was just MA and they never promised anything other than MA.
As it happens, I14 isn't just MA. Granted the non-MA content (e.g. changes to PvP) is a lot smaller than the non-feature changes we often see, but I15 has always (even when it was to be I14) been billed as the big 'story' issue.
From MA becoming it's own issue I'd guess that I15 is ready to launch/test pretty hot on the heels of I14 - and it wouldn't surprise me if it does reach test quickly once enough bugs in MA/I14 are quashed. -
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. -
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. -
Hmmm...
Checked this with:
- a few groups/subgroups/standard group of DE
- seperately with Crey and a subgroup (of 1)
- with Enraged DE using the single mob Crey subgroup
But the editor does seem keen to kick up 'Level range invalid' errors when there is an overlap of group ranges and custom groups are used.
Bugged it.
Anyone not seen this, you can quickly check by creatng a mission with:
- a small map
- set all required mission/arc text
- set map group to the standard group Devouring Earth (25 - 54)
- set kill all (as quick-to-set objective)
- create a patrol using a custom group of just the Crey Researcher - minion (32 - 41)
No errors show in the MA editor error display, but try to 'Save and Test' and it kicks up a 'Level range invalid' error. -
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. -
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] -
Addenda
Mobs May Lie About their Age!
This may be a big beta bug... I hope so!
It appears that some of the mobs lie about their level ranges - and not just so that they can get served alcohol by claiming to be lvl 21!
I had a closer look knowing that an EU poster (Bovine_Avenger) was having difficulty with a custom DE group. The group was designed to lockdown the level range and should have had a maximum upper limit of 45, and was showing this in the group designer, but when the mission was run it was reporting an upper range limit of 54.
And I found that the DE have several mobs that seem to lie about their range:
e.g.
Devouring Earth - Razorvine - minion (31-36) - Actual Range: 25-47
Devouring Earth - Deathspore - minion (31-35) - Actual Range: 26-41
The claimed level range is the one shown in the level range coverage bar (and so is very possibly the range used to decide if a Pick'n'Mix group has valid range coverage) but when you save/reload the arc or go to test the arc then the actual level range used by the server to spawn mobs appears to be used.
Looking closer at the results, it's clear that:
if you pick a mob that belongs to a 'family' of similar mobs at various ranges then the server is currently able to use any of the family - it does not appear to be limited to the specific mobs that you select!
E.g. The DE has a family^ of 'Bladegrass' critters, these all seem to have a common model (re-coloured, or maybe it's re-textured) and common powers. The Bladegrass family is:
-- Bladegrass - minion (25-30)
-- Razorvine - minion (32-36)
-- Blackrose - minion (38-42)
-- Deathblossom - minion (44-47)
It looks like selecting any one of these individual mobs for a custom group actually allows any of the family to appear.
E.g. 2 The DE also have a 'Fungoid' family, comprising:
-- Fungoid - minion (26-30)
-- Deathspore - minion (32-35)
-- Deathcap - minion (37-41)
Again, selecting any one of these individual mobs for a custom group appears to allow any of the family to appear.
By the way - my testing was with a kill all mission with just a single mob at a time selected as a custom group. The mission contact always told me it was 25-47 range if I selected one of the Bladegrass family as my test mob.
^ Ok - it looks like the DE might have 2 families of Bladegrass, 1 with summoning skills (SummonFX power) and one without. I don't know if they are interchangeable, although testing might tell us I haven't done testing for this!
It's good to KISS
The old KISS (Keep it Simple Stupid) principle can help if you need to create a custom group for lockdown purposes.
Since the lockdown group/mobs only needs to be included as a minor part of the mission (e.g. a single battle/patrol, as guards or late spawning hostage mobs) then the lockdown groups should be kept as simple as possible to make them easier to debug if (and when) something unexpected happens.
E.g. If you want a mission with a standard enemy group in, but want to lockdown the level range, create your lockdown group with a few mobs as needed and then set your lockdown group as the group used for a patrol and leave the main mission group as the standard group.
If the lockdown doesn't seem to work it'll cut down the number of possible mobs that are causing the problem. And when it does work few people will notice that a single patrol has a slightly different group name...