<!--quoteo(post=1900822:date=Feb 7 2012, 07:26 PM:name=OnosFactory)--><div class='quotetop'>QUOTE (OnosFactory @ Feb 7 2012, 07:26 PM) <a href="index.php?act=findpost&pid=1900822"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->So those r_fog 0 commands given a few posts up can't be used in the set file like AA and atmosperics can to be made permanent?
PS. Because half the fun of Skyrim is playing with the .ini file, best 'mini game' ever!<!--QuoteEnd--></div><!--QuoteEEnd-->
<!--quoteo(post=1894133:date=Jan 13 2012, 04:09 PM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 13 2012, 04:09 PM) <a href="index.php?act=findpost&pid=1894133"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I am saying nothing of the sort. Don't presume to put words in my mouth.
Now, with regard to decent lifetime, I was referring to the more "modern" features - an engine that is full of outdated technology when it is released is not attractive to modders, developers, or, more importantly, prospective customers either. A scripting "layer" built on top of the engine was one design decision that creates accessibility for modders, and allows for instant changes in-game. The others you know: dynamic lighting, no pre-compiling, etc. More than being marketed towards modders and developers, the decisions were made so that UWE could import, edit and test lots of assets and features in a very quick period of time, <b>without also requiring a very large team</b>. It was UWE's belief that the benefits outweighed the costs, and they still believe they will get it to work. Honestly, this was all explained by UWE the day they announced the decision to switch from Source to the as-yet-unnamed engine that became Spark (and by Max in one of the recent NS2HD interviews), and I'm just regurgitating it for your benefit. Your frustration is misdirected.<!--QuoteEnd--></div><!--QuoteEEnd--> Scripting layer is an excuse. You can write game code in anything, even C++. C++ these days allows reloading code while running. (a bit tricky but it works)
Doom 3 had dynamic lighting yet the game wasn't as slow as NS2 is. They weren't anywhere near in being late with release as NS2. Face it, NS2 dynamic lighting is 0 bounce thing that looks BAD. It looks visibly worse than HL2 lightmaps. There are lots of specular maps that alias all the time too. You can also code all of that given HL2 engine (not that I'm suggesting use of that, it costs some money).
Precompiling can be solved by Crytek engine or buying 1 powerful machine and/or spreading work around office computers.
Testing lots of stuff quickly - last time I heard UE3 was good enough for so many games that something stinks here.
UWE's belief - great, but that doesn't change facts. I'm not even sure if they have a single fairly slow computer matching their stated HW requirements on which they'd test the game.
If instead of spending time on redundant videos about MT they spent it on actually coding it it'd be 10x more useful. Only reason for doing it that makes sense is to lower cognitive dissonance of people that constantly say that NS2 is greatest thing ever.
Just like that guy said, most people posting here are very polite but they stop being so on other forums where NS2 compared to DNF (which was actually released).
<!--quoteo(post=1902067:date=Feb 11 2012, 04:14 AM:name=MOOtant)--><div class='quotetop'>QUOTE (MOOtant @ Feb 11 2012, 04:14 AM) <a href="index.php?act=findpost&pid=1902067"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Just like that guy said, most people posting here are very polite but they stop being so on other forums where NS2 compared to DNF (which was actually released).<!--QuoteEnd--></div><!--QuoteEEnd-->
<!--quoteo(post=1902067:date=Feb 11 2012, 08:14 AM:name=MOOtant)--><div class='quotetop'>QUOTE (MOOtant @ Feb 11 2012, 08:14 AM) <a href="index.php?act=findpost&pid=1902067"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Scripting layer is an excuse. You can write game code in anything, even C++. C++ these days allows reloading code while running. (a bit tricky but it works)<!--QuoteEnd--></div><!--QuoteEEnd--> Very much agreed. Lua is incredibly easy to integrate into just about anything, and hasn't anything to do with using your own engine (they even took inspiration from Garry's Mod). Of course you might want to wonder whether in hindsight you really want to do that now.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Doom 3 had dynamic lighting yet the game wasn't as slow as NS2 is. They weren't anywhere near in being late with release as NS2. Face it, NS2 dynamic lighting is 0 bounce thing that looks BAD. It looks visibly worse than HL2 lightmaps. There are lots of specular maps that alias all the time too. You can also code all of that given HL2 engine (not that I'm suggesting use of that, it costs some money).<!--QuoteEnd--></div><!--QuoteEEnd--> This one perplexed me as well. Of course the reason why NS2 is as slow isn't related to the realtime-shadowing (or at least not now, with the Lua-bottleneck and all). I was more curious about why they decided to go with non-compilating method of mapping. Sure it saves them time when putting your map out there, but technically as a mapper (for Doom3 \ NS2 \ or similar WYSIWYG) you shouldn't even have to compile your map until performance becomes a factor (optimization \ when it's time for a public-release), so it's a only a one-time price you pay. It shouldn't take as long as Gldsource\Source as only visibility needs to be computed. The only reason I can come up with right now is that precomputed visibility may become an issue when your maps are incredibly interactive (think whole rooms moving around, Portal 2-ish). As it stands, NS2's maps are among the most static I have ever seen (Quake 1's maps were more interactive, with moving brush-entities). On top of that, you're expected to put in static visibility-hints as a mapper, so that negates even the dynamic advantage you otherwise would've had.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->If instead of spending time on redundant videos about MT they spent it on actually coding it it'd be 10x more useful. Only reason for doing it that makes sense is to lower cognitive dissonance of people that constantly say that NS2 is greatest thing ever.
Just like that guy said, most people posting here are very polite but they stop being so on other forums where NS2 compared to DNF (which was actually released).<!--QuoteEnd--></div><!--QuoteEEnd--> Yea multi-threaded Lua, I don't think it's very likely. The scripts aren't at all designed around the idea of independently-computing entities.
Comments
PS. Because half the fun of Skyrim is playing with the .ini file, best 'mini game' ever!
PS. Because half the fun of Skyrim is playing with the .ini file, best 'mini game' ever!<!--QuoteEnd--></div><!--QuoteEEnd-->
not yet
Now, with regard to decent lifetime, I was referring to the more "modern" features - an engine that is full of outdated technology when it is released is not attractive to modders, developers, or, more importantly, prospective customers either. A scripting "layer" built on top of the engine was one design decision that creates accessibility for modders, and allows for instant changes in-game. The others you know: dynamic lighting, no pre-compiling, etc. More than being marketed towards modders and developers, the decisions were made so that UWE could import, edit and test lots of assets and features in a very quick period of time, <b>without also requiring a very large team</b>. It was UWE's belief that the benefits outweighed the costs, and they still believe they will get it to work. Honestly, this was all explained by UWE the day they announced the decision to switch from Source to the as-yet-unnamed engine that became Spark (and by Max in one of the recent NS2HD interviews), and I'm just regurgitating it for your benefit. Your frustration is misdirected.<!--QuoteEnd--></div><!--QuoteEEnd-->
Scripting layer is an excuse. You can write game code in anything, even C++. C++ these days allows reloading code while running. (a bit tricky but it works)
Doom 3 had dynamic lighting yet the game wasn't as slow as NS2 is. They weren't anywhere near in being late with release as NS2. Face it, NS2 dynamic lighting is 0 bounce thing that looks BAD. It looks visibly worse than HL2 lightmaps. There are lots of specular maps that alias all the time too. You can also code all of that given HL2 engine (not that I'm suggesting use of that, it costs some money).
Precompiling can be solved by Crytek engine or buying 1 powerful machine and/or spreading work around office computers.
Testing lots of stuff quickly - last time I heard UE3 was good enough for so many games that something stinks here.
UWE's belief - great, but that doesn't change facts. I'm not even sure if they have a single fairly slow computer matching their stated HW requirements on which they'd test the game.
If instead of spending time on redundant videos about MT they spent it on actually coding it it'd be 10x more useful. Only reason for doing it that makes sense is to lower cognitive dissonance of people that constantly say that NS2 is greatest thing ever.
Just like that guy said, most people posting here are very polite but they stop being so on other forums where NS2 compared to DNF (which was actually released).
really? come on now.
Very much agreed. Lua is incredibly easy to integrate into just about anything, and hasn't anything to do with using your own engine (they even took inspiration from Garry's Mod). Of course you might want to wonder whether in hindsight you really want to do that now.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Doom 3 had dynamic lighting yet the game wasn't as slow as NS2 is. They weren't anywhere near in being late with release as NS2. Face it, NS2 dynamic lighting is 0 bounce thing that looks BAD. It looks visibly worse than HL2 lightmaps. There are lots of specular maps that alias all the time too. You can also code all of that given HL2 engine (not that I'm suggesting use of that, it costs some money).<!--QuoteEnd--></div><!--QuoteEEnd-->
This one perplexed me as well. Of course the reason why NS2 is as slow isn't related to the realtime-shadowing (or at least not now, with the Lua-bottleneck and all). I was more curious about why they decided to go with non-compilating method of mapping. Sure it saves them time when putting your map out there, but technically as a mapper (for Doom3 \ NS2 \ or similar WYSIWYG) you shouldn't even have to compile your map until performance becomes a factor (optimization \ when it's time for a public-release), so it's a only a one-time price you pay. It shouldn't take as long as Gldsource\Source as only visibility needs to be computed. The only reason I can come up with right now is that precomputed visibility may become an issue when your maps are incredibly interactive (think whole rooms moving around, Portal 2-ish). As it stands, NS2's maps are among the most static I have ever seen (Quake 1's maps were more interactive, with moving brush-entities). On top of that, you're expected to put in static visibility-hints as a mapper, so that negates even the dynamic advantage you otherwise would've had.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->If instead of spending time on redundant videos about MT they spent it on actually coding it it'd be 10x more useful. Only reason for doing it that makes sense is to lower cognitive dissonance of people that constantly say that NS2 is greatest thing ever.
Just like that guy said, most people posting here are very polite but they stop being so on other forums where NS2 compared to DNF (which was actually released).<!--QuoteEnd--></div><!--QuoteEEnd-->
Yea multi-threaded Lua, I don't think it's very likely. The scripts aren't at all designed around the idea of independently-computing entities.