Should Magma make more updates?
I have been playing Myth since TFL's release. I have greatly appreciated all of the updates that Magma has presented and I have no doubt that the community would be extremely grateful for a continuation of that effort.
The Mazz maps are consistently the showcases for new features, and all of them have been amazing, exciting, and challenging expansions of the Myth universe. I'd cheer for weeks if a Myth 2.5 (the "what Myth 3 should have been" game) were released and had a bright, shiny new Mazz 6 to try it out.
That having been said, I understand that appreciation only goes so far when working for years without pay. I can say that I would certainly be willing to pay for the quality improvements and mapmaking support Magma has shown itself capable of offering. I don't know if that would help stimulate growth in the website, but I'm certain that with the skill that the coders have exhibited thus far and the enthusiasm mapmakers bring to the forums that there is a plethora of amazing new possibilities for Myth.
With regard to altered gameplay, I don't think that adjustments like improved graphics (color spectrum, unit detail) and increased object retention (# of projectiles especially, as mentioned earlier in the thread) would be cause for any Myth gamers to baulk. I doubt there is anyone here who would object to every map's units looking like those in RotD. Changes like double-click to slower/faster movement or advanced unit AI (my archers perhaps NOT targeting the Stygian instead of the myrk giant, just once?) are deeper questions, but certainly worth discussion.
Okay, wrap-up: I'd love to see Magma continue doing fantastic work, I'll pay for it if that would help, and ChrisP... they beat Mazz 5 on legendary, are you gonna let them do that? Myth update = Mazz 6. Think about it.
The Mazz maps are consistently the showcases for new features, and all of them have been amazing, exciting, and challenging expansions of the Myth universe. I'd cheer for weeks if a Myth 2.5 (the "what Myth 3 should have been" game) were released and had a bright, shiny new Mazz 6 to try it out.
That having been said, I understand that appreciation only goes so far when working for years without pay. I can say that I would certainly be willing to pay for the quality improvements and mapmaking support Magma has shown itself capable of offering. I don't know if that would help stimulate growth in the website, but I'm certain that with the skill that the coders have exhibited thus far and the enthusiasm mapmakers bring to the forums that there is a plethora of amazing new possibilities for Myth.
With regard to altered gameplay, I don't think that adjustments like improved graphics (color spectrum, unit detail) and increased object retention (# of projectiles especially, as mentioned earlier in the thread) would be cause for any Myth gamers to baulk. I doubt there is anyone here who would object to every map's units looking like those in RotD. Changes like double-click to slower/faster movement or advanced unit AI (my archers perhaps NOT targeting the Stygian instead of the myrk giant, just once?) are deeper questions, but certainly worth discussion.
Okay, wrap-up: I'd love to see Magma continue doing fantastic work, I'll pay for it if that would help, and ChrisP... they beat Mazz 5 on legendary, are you gonna let them do that? Myth update = Mazz 6. Think about it.
-
William Wallet
- Posts: 1494
- Joined: Tue Mar 30, 2004 9:40 am
- Location: Perth Australia
- Contact:
You know what would rock? Giving a flying unit the ability to 'not-stand-still' - basically, a plane wouldn't hover. So if someone made a plane unit, it should sort of fly in circles without ever having to set *foot* on the ground!
(I refuse to edit that other post where I sort of, slipped up).
(I refuse to edit that other post where I sort of, slipped up).
Okay I got the models but now I'm too dumb to do anything with 'em
Thanks for those really kind words, pompey. In my opinion, the Myth community still has lots of things to look forward to for many years. No one is exactly sure what though. 
Gleep, to address some of your mapmaking problems:
If I'm not mistaken, it's not Fear that only allows you to view 1024 tags in a given folder, but operating systems in general. If you were to make a folder on your desktop and drag more than 1024 files into it, basically, the same thing would happen. Obviously, it's outside of Magma's purview to change how file structures work, but there is a way to set up Fear so it doesn't read any of Bungie's foundation tags, and only what's in your local folder instead - hence reducing the number of tags in a folder to below 1024 and making them all viewable.
Two problems with this. The first is that if any of your local folder tags rely on or are connected to stock Bungie tags, you can easily make a big mess. The second problem is I don't remember how to do it.
ozone knows, however, and I'll try to remember to ask him.
In the meantime, the simpler solution, as taught to me by Silicon Dream, is to make a seperate folder called "extra projectiles" or something and temporarily dump any projectiles you absolutely know you won't be editing during a Fear session. Take care not to temporarily dump any projectiles that are connected to other tags that you'll be editing. For instance, if you open a projectile group tag and hit "okay" (as opposed to "cancel") and that projectile group tag connects to a projectile that's missing from your local, you could screw things up. Anyway, it's really not too hard to work using this method. I certainly got used to it with Mazz V.
No, weirdly rendered projectiles or lpgr particles I've not seen, so I don't know what that could be. But as far as unit colors not getting assigned right, that usually stems from too many units sharing the same collection. For instance, in UTB Lichen Sluglords, you have regular dwarves, striders, and pathfinders, all sharing the same exact collection. Don't ask me exactly how it works, but the collection references for those three units get multiplied by the number of players in the game, and once it goes over a certain number, the colors get all whacked.
The solution is not to have more than one or two units share the same collection. Easier said than done if you're on a PC and don't know the following little trick. I forget who posted this tip here once (Baak? haravikk?) but I used it for Mazz V just before I release, and I'm so glad I did.
Follow these steps:
1. Hold down Shift while opening Fear. You'll now have access to uneditable tags.
2. Duplicate the collection that you want more than one unit to reference. Close Fear.
3. Your duplicated tag will appear in your local folder. Open it with Tahoe.
4. In the menu, under Collection, hit "Info...".
5. Carefully note what User Flags are checked, uncheck them, and save the file.
6. Open it up again, go back to Info, and recheck the flags the way you initially found them. Save again.
7. Now you can use this collection for a new monster. Make sure the monster, unit, collection reference, and projectile tags for your new monster ALL reference the duplicate collection you just made, and not the old one.
No more weird team color problems. Enjoy.
Gleep, to address some of your mapmaking problems:
If I'm not mistaken, it's not Fear that only allows you to view 1024 tags in a given folder, but operating systems in general. If you were to make a folder on your desktop and drag more than 1024 files into it, basically, the same thing would happen. Obviously, it's outside of Magma's purview to change how file structures work, but there is a way to set up Fear so it doesn't read any of Bungie's foundation tags, and only what's in your local folder instead - hence reducing the number of tags in a folder to below 1024 and making them all viewable.
Two problems with this. The first is that if any of your local folder tags rely on or are connected to stock Bungie tags, you can easily make a big mess. The second problem is I don't remember how to do it.
ozone knows, however, and I'll try to remember to ask him.In the meantime, the simpler solution, as taught to me by Silicon Dream, is to make a seperate folder called "extra projectiles" or something and temporarily dump any projectiles you absolutely know you won't be editing during a Fear session. Take care not to temporarily dump any projectiles that are connected to other tags that you'll be editing. For instance, if you open a projectile group tag and hit "okay" (as opposed to "cancel") and that projectile group tag connects to a projectile that's missing from your local, you could screw things up. Anyway, it's really not too hard to work using this method. I certainly got used to it with Mazz V.
On a side note, has anyone run into a problem where projectiles start going weird like turning black or not rendering right? I've had it happen recently and its usually in lpgrs, which are at the limit. It may tie into my bug that apparently is related to player count and color indexing. Is there a plan to raise the memory storage for indexing colors? I know on big plugs like UTB, and my map Dream of Death colors get wild and arent assigned right, and I think that its causing the crash on my map.
No, weirdly rendered projectiles or lpgr particles I've not seen, so I don't know what that could be. But as far as unit colors not getting assigned right, that usually stems from too many units sharing the same collection. For instance, in UTB Lichen Sluglords, you have regular dwarves, striders, and pathfinders, all sharing the same exact collection. Don't ask me exactly how it works, but the collection references for those three units get multiplied by the number of players in the game, and once it goes over a certain number, the colors get all whacked.
The solution is not to have more than one or two units share the same collection. Easier said than done if you're on a PC and don't know the following little trick. I forget who posted this tip here once (Baak? haravikk?) but I used it for Mazz V just before I release, and I'm so glad I did.
Follow these steps:
1. Hold down Shift while opening Fear. You'll now have access to uneditable tags.
2. Duplicate the collection that you want more than one unit to reference. Close Fear.
3. Your duplicated tag will appear in your local folder. Open it with Tahoe.
4. In the menu, under Collection, hit "Info...".
5. Carefully note what User Flags are checked, uncheck them, and save the file.
6. Open it up again, go back to Info, and recheck the flags the way you initially found them. Save again.
7. Now you can use this collection for a new monster. Make sure the monster, unit, collection reference, and projectile tags for your new monster ALL reference the duplicate collection you just made, and not the old one.
No more weird team color problems. Enjoy.
-
The Elfoid
- Posts: 1014
- Joined: Mon May 03, 2004 5:30 am
- Location: Devon, England
- Contact:
1.5.2's not even out yet Gleep,
How much of the Magma members in map-making AND coding's focus is on the coding side?
How much of the Magma members in map-making AND coding's focus is on the coding side?
http://theramblingelf.tumblr.com/ - my blog
Only Iron Duke has contributed heavily in both areas. Programmer; unit modeller; scripter; tag editor; color map artist, I don't think there's ever been anyone else in the Myth community so multi-talented or accomplished. Or as humble about it all.The Elfoid wrote:How much of the Magma members in map-making AND coding's focus is on the coding side?
-
- Posts: 58
- Joined: Wed Apr 21, 2004 11:47 am
- Location: Los Alamos, NM
- Contact:
I got that to psuedo work once by making the unit skittish...but then it would turn in circles...and fly backwards occasionally...it was weird...I was goofing around and trying to make fetching fly like birds and fart lightning. Of course, this was all in 1.3William Wallet wrote:You know what would rock? Giving a flying unit the ability to 'not-stand-still' - basically, a plane wouldn't hover. So if someone made a plane unit, it should sort of fly in circles without ever having to set *foot* on the ground!
(I refuse to edit that other post where I sort of, slipped up).
Vidmaster's Oath:
I pledge to punch all switches, to never shoot where I could use grenades, to admit the existence of no level except Total Carnage, to never use Caps Lock as my ‘run’ key, and to never, ever, leave a single Bob alive.
I pledge to punch all switches, to never shoot where I could use grenades, to admit the existence of no level except Total Carnage, to never use Caps Lock as my ‘run’ key, and to never, ever, leave a single Bob alive.
Yes, by all means all this tossing around of ideas has beneath it a big "Thanks, Magma!" for all the excellent work they've done with the Patches...
Yeah, that was me. I was just hoping there'd be an easy way to do this internal to the engine, as it appears to still get whacked now and then even when using this trick. (It appears cumulative - i.e. you won't see the player-unit-colors-whacked bug the first time you host a game, but after many games the probability seems to go up). It just seems like some kind of buffer overrun / out of bounds error that causes the player color indexing to "spill over" if so many units use the same collection - odd that it can be fixed by detaching/re-attaching units - and tedious that you have to duplicate collections to work around it.
Gleep-- I think you're right on the player floyning having to do with some odd attribute of the way color hues are handled. I still think the best (and possibly simplest) solution however is a simple checkbox for the host that says: "Don't Floyn Player Colors"
Easier said than done if you're on a PC and don't know the following little trick.
Yeah, that was me. I was just hoping there'd be an easy way to do this internal to the engine, as it appears to still get whacked now and then even when using this trick. (It appears cumulative - i.e. you won't see the player-unit-colors-whacked bug the first time you host a game, but after many games the probability seems to go up). It just seems like some kind of buffer overrun / out of bounds error that causes the player color indexing to "spill over" if so many units use the same collection - odd that it can be fixed by detaching/re-attaching units - and tedious that you have to duplicate collections to work around it.
Gleep-- I think you're right on the player floyning having to do with some odd attribute of the way color hues are handled. I still think the best (and possibly simplest) solution however is a simple checkbox for the host that says: "Don't Floyn Player Colors"
Hmmmmm... Don't you have to have the units use player colors or they'd all be the same color for every team, right? (They'd all be set to the default core color with no team settings)
Here's the two floyn problems we encounter explained a bit better - sorry if I'm repeating, but want to be sure we're talking about the same thing:
Problem #1 - DON'T AUTO-ADJUST PLAYER COLORS
The checkbox "Don't Floyn Player Colors" (probably "Don't Auto-adjust Player Colors" would be the proper language) would be to avoid the following:
* Player 1 uses Dark Brown as their Primary Color
* Player 2 uses Medium Purple as their Primary Color
* Player 3 uses Dark Blue as their Primary Color
Somehow Player 1 and 2 are seen as "conflicting" even though visually there is no problem whatsoever. The engine converts Player 2 to a Blue almost identical to Player 3! This is annoying and extremely confusing, especially since no one had a problem with any of the player colors to start with!
Even worse when the TEAM colors are floyned to "Dark Blue" and "Medium Dark Blue"! This can change the outcome of a game/match because players easily confuse their units! Am I on Dark Blue or Medium Dark Blue?!? Very, very bad - and unnecessary...
This gets even worse still when you play with the same players over the years who have used the same player colors in thousands (yep) of games - you don't want or need the player colors to change!
Checking the box means the host can control with the flick of a switch whether to avoid this nonsense or not. If you're playing with random players perhaps auto-adjusting (floyning) is just fine, although the team floyn where the resulting colors are almost identical seems like a bug to me regardless.
Problem #2 - UNIT TEAM COLORS INTERMIX DURING GAME PLAY
Picture starting on Venice in the Southwest corner using a plugin that converts most of the units to Dwarves. You see:
* 10 Dwarves of your own team color as normal
* 2 with the team colors of the Nortwest team
* 2 with the team colors of the Norteast team
* 1 set to the default core color with no team settings whatsoever
And each team has correspondingly whacked colors! That's the weird floyn(2) bug I mentioned before.
This is 95% fixed in RDF 5.1 by me creating mutliple copies of the Dwarf Collection, but still happens on occasion (especially in cumulative games and on maps that use lots of LPGRs). Vinylrake has encountered this bug with his unit conversions as well.
Here's the two floyn problems we encounter explained a bit better - sorry if I'm repeating, but want to be sure we're talking about the same thing:
Problem #1 - DON'T AUTO-ADJUST PLAYER COLORS
The checkbox "Don't Floyn Player Colors" (probably "Don't Auto-adjust Player Colors" would be the proper language) would be to avoid the following:
* Player 1 uses Dark Brown as their Primary Color
* Player 2 uses Medium Purple as their Primary Color
* Player 3 uses Dark Blue as their Primary Color
Somehow Player 1 and 2 are seen as "conflicting" even though visually there is no problem whatsoever. The engine converts Player 2 to a Blue almost identical to Player 3! This is annoying and extremely confusing, especially since no one had a problem with any of the player colors to start with!
Even worse when the TEAM colors are floyned to "Dark Blue" and "Medium Dark Blue"! This can change the outcome of a game/match because players easily confuse their units! Am I on Dark Blue or Medium Dark Blue?!? Very, very bad - and unnecessary...
This gets even worse still when you play with the same players over the years who have used the same player colors in thousands (yep) of games - you don't want or need the player colors to change!
Checking the box means the host can control with the flick of a switch whether to avoid this nonsense or not. If you're playing with random players perhaps auto-adjusting (floyning) is just fine, although the team floyn where the resulting colors are almost identical seems like a bug to me regardless.
Problem #2 - UNIT TEAM COLORS INTERMIX DURING GAME PLAY
Picture starting on Venice in the Southwest corner using a plugin that converts most of the units to Dwarves. You see:
* 10 Dwarves of your own team color as normal
* 2 with the team colors of the Nortwest team
* 2 with the team colors of the Norteast team
* 1 set to the default core color with no team settings whatsoever
And each team has correspondingly whacked colors! That's the weird floyn(2) bug I mentioned before.
This is 95% fixed in RDF 5.1 by me creating mutliple copies of the Dwarf Collection, but still happens on occasion (especially in cumulative games and on maps that use lots of LPGRs). Vinylrake has encountered this bug with his unit conversions as well.
That can be done already in Amber by setting a hue change as normal opposed to primary/secondary (which uses player colours).
If you need to you can set a normal hue change and primary/secondary hue change to affect exactly the same colours, but simply select whichever one(s) you don't want to use as "Is unused" in the unit's collection reference, giving you plenty of choice =)
e.g:
In the warlock collection I want the robe lining (cyan) to use player colours.
However I also want to make a warlock unit whose robe lining is always the same.
So I create two hue changes, both of these replace the colour cyan, but one is set to primary, and the other is set to normal.
In the collection reference for unit A I set the second hue change as "Is unused" so that it has no effect, and the primary colour is used without fuss.
In the collection reference for unit B I set the first hue change to "Is unused", disabling the primary colour's effect on the unit, and allowing me to choose the colour that cyan is replaced with and have it stay like that.
Edited By haravikk on 1136248605
If you need to you can set a normal hue change and primary/secondary hue change to affect exactly the same colours, but simply select whichever one(s) you don't want to use as "Is unused" in the unit's collection reference, giving you plenty of choice =)
e.g:
In the warlock collection I want the robe lining (cyan) to use player colours.
However I also want to make a warlock unit whose robe lining is always the same.
So I create two hue changes, both of these replace the colour cyan, but one is set to primary, and the other is set to normal.
In the collection reference for unit A I set the second hue change as "Is unused" so that it has no effect, and the primary colour is used without fuss.
In the collection reference for unit B I set the first hue change to "Is unused", disabling the primary colour's effect on the unit, and allowing me to choose the colour that cyan is replaced with and have it stay like that.
Edited By haravikk on 1136248605
Being Haravikk gets you girls like these:
If F10 worked without losing units once they have been selected alot of the team color problems would be solved. I mean imagine always being able to see your teams selection boxes and health. WHile units without boxes woudl be the enemy. Its only because you lose the units you have selected that F10 isnt that great.
opinions?
Edited By ozone on 1136250548
opinions?
Edited By ozone on 1136250548
do it.