Eternal X 1.2

Discuss and unveil current Marathon projects.
User avatar
Pfhorrest
Vidmaster
Posts: 1847
Joined: Oct 12th '07, 22:08
Location: California
Contact:

The ugly dark appearance only happens when saving with MIPmaps on (regardless of DXTC). I have no idea why the MIPmap setting would change the appearance of the full-size texture but it appears to do so.
User avatar
treellama
Vidmaster
Posts: 6110
Joined: Jun 2nd '06, 02:05
Location: Pittsburgh
Contact:

What--how could it possibly alter the full-size texture?

Unfortunately Aorta doesn't run on my Mac--while I work on a new version, can you try importing it as another format into Aorta? Maybe it's trying to gamma-correct your PNG?

Aorta can display DDS files, so you should be able to tell right away whether the image is wrong or not.
User avatar
Pfhorrest
Vidmaster
Posts: 1847
Joined: Oct 12th '07, 22:08
Location: California
Contact:

I’ll give that I try next time I’m at my computer.
User avatar
Pfhorrest
Vidmaster
Posts: 1847
Joined: Oct 12th '07, 22:08
Location: California
Contact:

Okay, I just freshly exported a JPEG (using Save For Web including Convert to sRGB) from the original PSDs, and converted it to DDS in four ways:

- no MIP, no DXTC
- no MIP, with DXTC
- MIP, no DXTC
- MIP, with DXTC

And then opened all four up in Aorta to check, and both MIP versions look awful and dark, while the no-MIP versions look just like the JPEG.

You can see the original files and all four DDS's here:

http://eternal.bungie.org/files/_misc/1 ... amples.zip
User avatar
treellama
Vidmaster
Posts: 6110
Joined: Jun 2nd '06, 02:05
Location: Pittsburgh
Contact:

And you have the sprite options (fast halo removal, reconstruct edge colors) off, for this wall texture, right? Still baffled, but I'll get it to build and figure out what's going on.
User avatar
treellama
Vidmaster
Posts: 6110
Joined: Jun 2nd '06, 02:05
Location: Pittsburgh
Contact:

I'm not able to reproduce the problem here; exporting with or without mipmaps it looks fine. Double check you have the latest (ancient) version of Aorta?

I will try to get a new build ready. Releasing Mac apps is much more difficult now than it was in 2008, unfortunately.
User avatar
Pfhorrest
Vidmaster
Posts: 1847
Joined: Oct 12th '07, 22:08
Location: California
Contact:

It was the sprite options that were responsible apparently. I didn't know those were only for sprites, and they were on by default (and these are partially transparent textures so they seem relevant), so I didn't mess with them. Saving with DXTC and MIPmaps but no halo removal (or edge color correction) seems to work fine, as far as I can tell just reopening them with Aorta again. I'll test everything in game in a day or three when I get a chance. Thanks!
User avatar
treellama
Vidmaster
Posts: 6110
Joined: Jun 2nd '06, 02:05
Location: Pittsburgh
Contact:

Ah, ok. Yes, the halo removal and edge reconstruction features are for sprites. Here's a great explanation:

http://vterrain.org/Plants/Alpha/

They're not on by default, but it does remember the setting, so if you used them once, they stay on until you turn them off.
User avatar
The Man
Vidmaster
Posts: 1203
Joined: Aug 6th '08, 05:23
Location: Sarasota, FL
Contact:

Is there an easily comprehensible guide somewhere to how all these DDS settings work? There are a lot of settings, and some of them are really confusing! I'd rather not mess anything up with preparing DDS textures for WMAiD when it comes time to package together the demo (and eventually the full game). Thanks for that link, though - it was helpful.
“People should not be afraid of their governments. Governments should be afraid of their people.” —V, V for Vendetta (Alan Moore)

“The trouble is that we have a bad habit, encouraged by pedants and sophisticates, of considering happiness as something rather stupid. Only pain is intellectual, only evil interesting. This is the treason of the artist: a refusal to admit the banality of evil and the terrible boredom of pain. If you can’t lick ’em, join ’em. If it hurts, repeat it. But to praise despair is to condemn delight, to embrace violence is to lose hold of everything else. We have almost lost hold; we can no longer describe happy man, nor make any celebration of joy.” —Ursula K. Le Guin, “The Ones Who Walk Away from Omelas”

“If others had not been foolish, we should be so.” —William Blake, The Marriage of Heaven and Hell

“The law cannot protect anyone unless it binds everyone; and it cannot bind anyone unless it protects everyone.” —Frank Wilhoit

Last.fm · Marathon Chronicles · Marathon Eternal 1.2 · Where Monsters Are in Dreams · YouTube Vidmaster’s Challenge
User avatar
treellama
Vidmaster
Posts: 6110
Joined: Jun 2nd '06, 02:05
Location: Pittsburgh
Contact:

Unfortunately there isn't. The opac_type buttons just do the same thing the engine does when you choose opac_type; it's an easier way to create transparent liquid textures. Un-premultiply alpha you probably won't ever need, it's for images that are stored with premultiplied alpha. Make normal map converts a grayscale height map into a normal map, you don't need it for texture conversion.

When you save:
  • Use DXTC if you can. Sometimes landscapes and Eternal grayscale textures look bad because of the lossy compression. It's OK to mix and match DXTC and uncompressed. Compressed textures use 1/4 as much RAM and VRAM as raw textures and usually look just as good.
  • Generate mipmaps for everything except small (< 1024 pixel) weapons in hand. Weapons in hand don't normally use mipmaps unless there is the need to reduce texture quality (and corresponding MML). Likewise, landscapes almost always use the highest resolution texture, but again the texture quality settings can use smaller images in the mipmaps to save VRAM.
  • Image repeats tiles textures before mipmap generation. Use this for wall textures
  • The kaiser filter is probably the best general-use mipmap filter. I think it's the default. The others are available in the rare case that you see artifacts in the mipmaps
  • Experiment with the halo removal options if you see effects like in that link with the palm trees (only necessary for sprites / weapons in hand / maybe grates?). Reconstruct edge colors is that first processed palm tree, fast halo removal fills in the entire texture like the next ones down. Choose the correct background color if you are trying to "reconstruct edge colors"
User avatar
The Man
Vidmaster
Posts: 1203
Joined: Aug 6th '08, 05:23
Location: Sarasota, FL
Contact:

Thanks, that’s quite helpful. I assume greyscale images should be saved as a different DXTC type – if you’re saving it as RGB you’re wasting two entire channels and tripling (or at least doubling, if there’s an alpha channel) the image size in memory! I assume that means using a different form of compression for those images?



On another note, I had the potentially dumb idea last night that I want to dynamically convert some of the dream levels from one texture set to another once the player reaches a certain point in the level, but this runs into the obvious problem that the Windows version of the game is already close to crashing with one OpenGL texture set loaded and can’t possibly handle two. However, those levels only use a very small subset of the overall textures – I’m going to guess about 30 or 40 of them. (There are a total of 134 OpenGL textures per set, of which 14 of them are 1024x1024 and the remaining 120 are 512x512.)

There is a possible workaround, however. I see that there is a <txtr_clear> command in the OpenGL commands for MML. Will this prevent the game from loading any OpenGL texture it’s used for into memory at all? If that’s the case, this should be able to work; it’ll just require a long MML script to disable a lot of the OpenGL textures from loading for two texture sets in each of these levels. (Obviously we’d have to test it to be sure that it functions as intended.)

(Also, the reason I want to disable specific textures from loading is that I don’t believe there’s any way to create level-specific MML that only loads if a particular plugin is enabled – if there’s some way I’m unaware of, then perhaps we have another route, though we’d still probably have to disable some stuff from loading.)
“People should not be afraid of their governments. Governments should be afraid of their people.” —V, V for Vendetta (Alan Moore)

“The trouble is that we have a bad habit, encouraged by pedants and sophisticates, of considering happiness as something rather stupid. Only pain is intellectual, only evil interesting. This is the treason of the artist: a refusal to admit the banality of evil and the terrible boredom of pain. If you can’t lick ’em, join ’em. If it hurts, repeat it. But to praise despair is to condemn delight, to embrace violence is to lose hold of everything else. We have almost lost hold; we can no longer describe happy man, nor make any celebration of joy.” —Ursula K. Le Guin, “The Ones Who Walk Away from Omelas”

“If others had not been foolish, we should be so.” —William Blake, The Marriage of Heaven and Hell

“The law cannot protect anyone unless it binds everyone; and it cannot bind anyone unless it protects everyone.” —Frank Wilhoit

Last.fm · Marathon Chronicles · Marathon Eternal 1.2 · Where Monsters Are in Dreams · YouTube Vidmaster’s Challenge
User avatar
treellama
Vidmaster
Posts: 6110
Joined: Jun 2nd '06, 02:05
Location: Pittsburgh
Contact:

No, Aleph One doesn't support any grayscale formats (and there are no compressed grayscale formats)

No, txtr_clear is not going to do what you want. Rather than trying to work around Aleph One bugs, it's probably better to help us test and fix them.
User avatar
The Man
Vidmaster
Posts: 1203
Joined: Aug 6th '08, 05:23
Location: Sarasota, FL
Contact:

Oh, weird. The NVIDIA DDS plugin I have for Photoshop lists a couple of formats (e.g., 8) that only seem to have one channel, and a few others that only seem to have two – what’s with those, then?
NVIDIA thing.png
And helping fix the bugs would be ideal! But I don’t know how to work around the memory problem in a manner that Aleph One 1.2.1 can accommodate on Windows. If a stable release of 1.3 comes out by the time we finish whichever version this script would end up in (and I have no idea how long it would take until one is ready), then of course it won’t be an issue (hopefully; we’ll just have to tell Windows players to use the new version). But otherwise, I don’t know what our options are unless we want to force players to use an unstable release (which I’d rather avoid if at all possible). We’re hoping to get Eternal 1.2.1 out in the next couple of months, so if there’s a new stable version by then that fixes the Windows memory issues, then obviously we don’t have to worry about it. Otherwise, there’s only three other ideas that come to mind, and the first is potentially even sillier (and certainly a lot more inelegant).

The silly, inelegant one involves reshuffling the landscape collections so that there are four landscapes in each of three collections; then treating one of the landscape collections (let’s say space for the sake of this example, though it might end up being one of the other three) as a walls collection for the first four success dreams and assigning the “walls” collection for those dream levels to the space collection. I seem to recall reading that the engine doesn’t see any actual difference between walls and landscapes collections, which is why you could use Texture Munger to assign two walls collections without modifying the physics, then reassign the landscapes to the second walls collection. So essentially, we’d be using the same idea here, but in reverse (i.e., reassigning the “walls” collection for the level to space).

This would require retexturing landscapes in every level, of course – so if we were going to use this idea, I’d want to be sure it would work. The main potential complication that immediately occurs to me is that the engine might get tripped up by the question of scenery – I don’t know if there’s a workaround for that.

The second idea involves seeing if Windows can add about 20-30 more textures per collection, and if so, adding those textures and writing a complicated reassignment script for each level to reassign textures as needed. This would also be inelegant, but probably a lot less silly.

The third idea is just reducing texture size even further. Given the choice, I’d rather avoid this, and I think we’d be a lot likelier to just hold off the texture reassignment script for Eternal 1.3 and just hope there’s a stable release of Aleph One 1.3 by then.

We might hold off on this until Eternal 1.3 anyway, since 1.2.1 is primarily intended to be a bug fix release. But if I think it’s a really cool effect, so if there’s a way to make it work, I’d like to be able to include it!
“People should not be afraid of their governments. Governments should be afraid of their people.” —V, V for Vendetta (Alan Moore)

“The trouble is that we have a bad habit, encouraged by pedants and sophisticates, of considering happiness as something rather stupid. Only pain is intellectual, only evil interesting. This is the treason of the artist: a refusal to admit the banality of evil and the terrible boredom of pain. If you can’t lick ’em, join ’em. If it hurts, repeat it. But to praise despair is to condemn delight, to embrace violence is to lose hold of everything else. We have almost lost hold; we can no longer describe happy man, nor make any celebration of joy.” —Ursula K. Le Guin, “The Ones Who Walk Away from Omelas”

“If others had not been foolish, we should be so.” —William Blake, The Marriage of Heaven and Hell

“The law cannot protect anyone unless it binds everyone; and it cannot bind anyone unless it protects everyone.” —Frank Wilhoit

Last.fm · Marathon Chronicles · Marathon Eternal 1.2 · Where Monsters Are in Dreams · YouTube Vidmaster’s Challenge
User avatar
treellama
Vidmaster
Posts: 6110
Joined: Jun 2nd '06, 02:05
Location: Pittsburgh
Contact:

As I said, Aleph One doesn't support the grayscale (L) formats, and there are none that are compressed.

My recommendation is to split the maps into smaller levels (remember, you're still using essentially the Marathon 2 engine), and use far fewer textures per set. Most of the textures in Eternal I've seen look intensely similar anyway. The last screenshot Forrest shared is just a featureless sea of gray and dull green: 130 textures per set is not helping. Choosing 40 high-utility, diverse textures and using better geometry and differential shading would go so far. Phoenix is a great example of what's possible.

I also think it's OK to recommend the beta builds of Aleph One, particularly since Eternal isn't exactly "stable" either--there's always a new version on the way! The next Aleph One beta should include LAA by default, or maybe even a 64-bit executable, which would help with memory issues provided the user has enough physical memory.
User avatar
The Man
Vidmaster
Posts: 1203
Joined: Aug 6th '08, 05:23
Location: Sarasota, FL
Contact:

Thanks, that’s helpful.

I do think there are probably too many textures per collection, but reshuffling the textures is something we’re going to hold off until at least version 1.3, since it’d require a complete retexturing of literally every map in the game. I can write a script to do this, now that I’ve got the logistics down, but 1.2.1 was supposed to be primarily a bug fix release. (It’s become quite a bit more, as pretty much every previous Eternal release has, but we’re going to hold off major graphical overhauls until later.)

I’ll admit many of levels maps are awfully large, but the only time I’ve had to pare back anything to prevent crashes was on “Killing the Giants as They Sleep”, which had 1,683 polygons in it in 1.2.0 (I pared it back to 1,645 for 1.2.1, and also sped up the doors so I could reshuffle some sound objects). The next largest levels both have 1,315 and we’ve never had any issues with them. …Unless you’re referring to physical space, I suppose. In which case, yes, it seems like nearly half the Eternal maps were made to take advantage of the larger view distances supported by Aleph One.

That’s good that the new version will have LAA support, though. I think we already reported this, but Windows 1.3b2 works fine even with Eternal 1.2.0’s oversized textures on most levels, but the standard build of Windows 1.3b3 crashes Eternal 1.2.0 with the oversized textures. The Windows 1.3b3 LAA build is fine, though. I don’t know if this is because the standard 1.3b2 build already had LAA support built in or not, but I wanted to be sure you were aware of it. This probably means it won’t be necessary to submit an issue on Github then, unless you thought it would be helpful.
“People should not be afraid of their governments. Governments should be afraid of their people.” —V, V for Vendetta (Alan Moore)

“The trouble is that we have a bad habit, encouraged by pedants and sophisticates, of considering happiness as something rather stupid. Only pain is intellectual, only evil interesting. This is the treason of the artist: a refusal to admit the banality of evil and the terrible boredom of pain. If you can’t lick ’em, join ’em. If it hurts, repeat it. But to praise despair is to condemn delight, to embrace violence is to lose hold of everything else. We have almost lost hold; we can no longer describe happy man, nor make any celebration of joy.” —Ursula K. Le Guin, “The Ones Who Walk Away from Omelas”

“If others had not been foolish, we should be so.” —William Blake, The Marriage of Heaven and Hell

“The law cannot protect anyone unless it binds everyone; and it cannot bind anyone unless it protects everyone.” —Frank Wilhoit

Last.fm · Marathon Chronicles · Marathon Eternal 1.2 · Where Monsters Are in Dreams · YouTube Vidmaster’s Challenge
User avatar
treellama
Vidmaster
Posts: 6110
Joined: Jun 2nd '06, 02:05
Location: Pittsburgh
Contact:

1.3b2 did not have LAA support, it's possible something is using more memory in 1.3b3.
User avatar
The Man
Vidmaster
Posts: 1203
Joined: Aug 6th '08, 05:23
Location: Sarasota, FL
Contact:

That’s odd. If there’s something I can do to help isolate why the memory usage got worse in b3, I’ll be glad to assist when time permits.
“People should not be afraid of their governments. Governments should be afraid of their people.” —V, V for Vendetta (Alan Moore)

“The trouble is that we have a bad habit, encouraged by pedants and sophisticates, of considering happiness as something rather stupid. Only pain is intellectual, only evil interesting. This is the treason of the artist: a refusal to admit the banality of evil and the terrible boredom of pain. If you can’t lick ’em, join ’em. If it hurts, repeat it. But to praise despair is to condemn delight, to embrace violence is to lose hold of everything else. We have almost lost hold; we can no longer describe happy man, nor make any celebration of joy.” —Ursula K. Le Guin, “The Ones Who Walk Away from Omelas”

“If others had not been foolish, we should be so.” —William Blake, The Marriage of Heaven and Hell

“The law cannot protect anyone unless it binds everyone; and it cannot bind anyone unless it protects everyone.” —Frank Wilhoit

Last.fm · Marathon Chronicles · Marathon Eternal 1.2 · Where Monsters Are in Dreams · YouTube Vidmaster’s Challenge
User avatar
Pfhorrest
Vidmaster
Posts: 1847
Joined: Oct 12th '07, 22:08
Location: California
Contact:

A few more beta files are up now.

Primarily, I think we finally have all the texture problems fixed. Downscaled to all 512x512 except the special textures at 1024x1024, like the last beta, but now also all media textures are re-implemented in every texture set so no level should need to use multiple texture sets just to use multiple media, and now that we figured out what the problem with exporting the windows and media to DDS was, the stripeyness/ugliness/weird pixelation is all gone too. Aaron confirms that this runs fine on Windows now, but other Windows users, please give this a try too and double-check:

Eternal Walls 1.2.1 beta 4:
http://eternal.bungie.org/files/_releas ... v121b4.zip

That also requires the modified shapes file that re-implements all media in each texture set, of course.

Eternal Shapes 1.2.1 beta 1:
http://eternal.bungie.org/files/_releas ... 1.shpA.zip

Also, Aaron has begun implementing some sounds from M1 and such to help differentiate the different time periods. I'd kind of like to hold off on new features until 1.3, but since it's already implemented...

Eternal Sounds 1.2.1 beta 2:
http://eternal.bungie.org/files/_releas ... 2.sndA.zip

As usual all this can be found well-organized on the Development page of eternal.bungie.org as well.

A new map file will probably be forthcoming next week some time too, and if that's all good then 1.2.1 is probably ready to go after that.
User avatar
Pfhorrest
Vidmaster
Posts: 1847
Joined: Oct 12th '07, 22:08
Location: California
Contact:

Jesus, this is really getting away from me with how limited my time is thanks to this whole coronavirus thing.

Aaron and I finally finished a play-through of the beta 1 map set, and then of his own private "beta 2" that included fixes to all of the bugs we found and also a whole bunch of other changes he made, that I wanted to confirm didn't break anything before I merged them in to my build.

One of those big changes is the merger of the precipitation Lua into the main map folder, controlled by a plugin that is not yet ready for release, so for now all of that Lua does nothing unless you get that plugin from him. But that required some changes to some global MML scripts; and also he made some other changes to those MML scripts. It probably also depends on his new shapes file I already linked above maybe? And also the maps now use some other sounds that were already included in his updated sounds file above, so you'll need those too or maybe something will break.

And also he had some last-minute map updates that I haven't had time to check, but rather than wait until I can find the time to play through the entire scenario again, I'll just trust that those work okay until I discover that they don't.

Rather than linking to just the new maps file, I'll just point out that everything has been available, neatly organized, on the Development page of the Eternal site all along:

http://eternal.bungie.org/development.php
User avatar
treellama
Vidmaster
Posts: 6110
Joined: Jun 2nd '06, 02:05
Location: Pittsburgh
Contact:

I don't think precipitation, as implemented, is a good idea in a plugin. It will make keeping films/net games in sync too hard for players. You need to decide: on or off for everyone. Or wait for an in-engine solution that doesn't affect the PRNG.
User avatar
Pfhorrest
Vidmaster
Posts: 1847
Joined: Oct 12th '07, 22:08
Location: California
Contact:

I believe the way it’s implemented now, it is automatically off in netgames, unless a specific net script is used that turns it on for everyone.

Good point about films though.
User avatar
The Man
Vidmaster
Posts: 1203
Joined: Aug 6th '08, 05:23
Location: Sarasota, FL
Contact:

It looks like levels where precipitation is the only thing that uses Game.random() stay in sync regardless of whether the plugin is on or off, judging from my tests with “Babylon X”. This makes sense, because the presence or absence of precipitation effects doesn’t actually change the gameplay of the level in any meaningful way; it’s purely cosmetic. It’s quite probable that levels that also have lightning, which also uses Game.random(), will desync, but this can be worked around by simply changing the lightning script to use Game.global_random(), since it’s not terribly important to have a good random number generator for a visual effect like lightning. I’ll test this later, but I think it should work. I don’t think we actually use Game.random() for anything besides lightning on any levels that currently use precipitation.

Wrkncacnter has a potential workaround for the frozen effects in saved games issue which I still need to try. I think I’ll look into that after my work shift tonight.
“People should not be afraid of their governments. Governments should be afraid of their people.” —V, V for Vendetta (Alan Moore)

“The trouble is that we have a bad habit, encouraged by pedants and sophisticates, of considering happiness as something rather stupid. Only pain is intellectual, only evil interesting. This is the treason of the artist: a refusal to admit the banality of evil and the terrible boredom of pain. If you can’t lick ’em, join ’em. If it hurts, repeat it. But to praise despair is to condemn delight, to embrace violence is to lose hold of everything else. We have almost lost hold; we can no longer describe happy man, nor make any celebration of joy.” —Ursula K. Le Guin, “The Ones Who Walk Away from Omelas”

“If others had not been foolish, we should be so.” —William Blake, The Marriage of Heaven and Hell

“The law cannot protect anyone unless it binds everyone; and it cannot bind anyone unless it protects everyone.” —Frank Wilhoit

Last.fm · Marathon Chronicles · Marathon Eternal 1.2 · Where Monsters Are in Dreams · YouTube Vidmaster’s Challenge
User avatar
treellama
Vidmaster
Posts: 6110
Joined: Jun 2nd '06, 02:05
Location: Pittsburgh
Contact:

Effects in the engine use the global random number generator. If one instance has them, and another doesn't, sync is affected.

If you really want to make precipitation optional (why?) you could ship two copies of the map, in which case the map identifier will keep things straight for you. But, please don't use a plugin.
User avatar
The Man
Vidmaster
Posts: 1203
Joined: Aug 6th '08, 05:23
Location: Sarasota, FL
Contact:

I might’ve not provided enough information in my previous post. I agree that the precipitation script shouldn’t use Game.global_random(), precisely because that affects other gameplay elements; that’s why my solution is to use Game.random() for everything relating specifically to precipitation, and not use Game.random() for anything else. Our lightning script, by contrast, appears regardless of whether or not the player has precipitation enabled, since it doesn’t cause lag on older computers, which is why I’m going to change it to use Game.global_random(). If I do this, I think films should stay in sync on levels that use lightning as well, since, as far as I know, only Lua scripts use Game.random() at all.

If precipitation is the only thing in a level that uses Game.random(), then enabling/disabling the precipitation script doesn’t appear to desync films. That’s what happened on my tests of “Babylon X”, at least: I recorded a film using the precipitation script, then turned it off and played back the film, and the entire film remained in sync. It’s possible my test didn’t cover some edge cases, of course, but I have no idea what those would be, so I have no idea how to test for them.

The reason to make precipitation optional is because it lags older computers to an unplayable extent, I guess because it’s moving so many effects around the level every tick. Pfhorrest and one of the Rampancy guys have both reported issues with it. But it looks really cool, so I’d rather have it possible to use for people whose computers can support it. Maintaining two separate map files is not a lot of fun, and people who get to level 13 and find it lags their computer to an unplayable extent will be unable to transfer their save files to the precipitation-less map, so I find that to be an unsatisfying solution. I suppose we could just add a script to level 1 so people would know immediately whether their machines could handle it, but it still seems like a cruder solution than a plugin, assuming that we can solve the film desync issue.

Of course, an even better solution would be if we could solve the lag it causes on older computers, but no one’s yet proposed a fix for that.
“People should not be afraid of their governments. Governments should be afraid of their people.” —V, V for Vendetta (Alan Moore)

“The trouble is that we have a bad habit, encouraged by pedants and sophisticates, of considering happiness as something rather stupid. Only pain is intellectual, only evil interesting. This is the treason of the artist: a refusal to admit the banality of evil and the terrible boredom of pain. If you can’t lick ’em, join ’em. If it hurts, repeat it. But to praise despair is to condemn delight, to embrace violence is to lose hold of everything else. We have almost lost hold; we can no longer describe happy man, nor make any celebration of joy.” —Ursula K. Le Guin, “The Ones Who Walk Away from Omelas”

“If others had not been foolish, we should be so.” —William Blake, The Marriage of Heaven and Hell

“The law cannot protect anyone unless it binds everyone; and it cannot bind anyone unless it protects everyone.” —Frank Wilhoit

Last.fm · Marathon Chronicles · Marathon Eternal 1.2 · Where Monsters Are in Dreams · YouTube Vidmaster’s Challenge
User avatar
Wrkncacnter
Vidmaster
Posts: 1953
Joined: Jan 29th '06, 03:51
Contact:

I think he's saying by merely creating an effect, the global random number generator gets used. Doesn't matter what's in your lua.
Post Reply