Jump to content

stevenmu

Members
  • Posts

    138
  • Joined

  • Last visited

Everything posted by stevenmu

  1. You're going to get a whole variety of replies from people, but my 2c is that I really like it. I probably like it as much as I liked GR1 with a similar amount of time spent with it (one of the best things about GR1 was that the more I played it the more I liked it, only time will tell if GRAW2 has that same ability). As was said you can't remove the weapon from your view (with the exception that you don't see it when you run). Personally I don't find that to be a problem, I barely notice it's there if at all. You also can't "soul-switch" but as was said you can use the "cross-com" to see what your squad members see and you can use a context sensitive command menu to move them around, make them attack a particular target, lay down cover fire etc. You can also use this command menu from your own view, you don't have to switch to a squad members view. And you can certainly control each individual, or a squad as a whole. One example I really liked was a mission where you have to defend a building from attack by insurgents. I opened the command map and ordered each of my guys to positions in cover at different points around the front of it. As I got to the building I noticed a mounted machine gun at the front so I was able to point at it and command one of them to use it. Another big plus with GRAW 2 is the reintroduction of rules of engagement, albeit in a slightly limited way, it only allows for "recon" and "assault", but it's still a huge improvement and adds a lot more depth of control. Overall it's certainly not GR1 with updated graphics, and it's missing one or two things that I really liked from GR1, but's a very good game in it's own right and one that I think most people who loved GR1 will really enjoy it. (note: I'm just talking about single player and don't really play multi-player at all)
  2. In GRAW I generally used the SCAR-H + scope, and sometimes suppressed. In GRAW2 I find I start to run low on ammo with it real quick so I've been using the SCAR-L in it's place. It seems to have almost as much stopping power too. IIRC in GRAW1 you could pick up ammo as you went along but in GRAW2 you either take the whole weapon or nothing ?
  3. I haven't had time to finish the SP campaign yet, but I can think of at least two missions where there were multiple objectives presented and you had the choice of the order in which to complete them. Granted they were only small parts of the overall missions i.e. do x, then destroy all three outposts a + b + c in your own order, then do y etc. But it does make me hopefull that the editor when released will allow to easily create one large mission with multiple objectives that can be tackled in any order. I think, or at least I hope, that the technical ability to do it is there now and readily available, but in the interests of telling a story Grin's own missions did force certain parts to be done in order. The "out of mission area" stuff does annoy me too, I do get that there obviously has to be limits to the map, but it also seems to be used to force you to stay within a certain part of the map untill you complete some objective aswell. Hopefully that is something that map/mission designers have to manually add in and with custom maps/missions we can be left free to roam.
  4. That was probably me, I was going to do it because I'd tried getting the demo to run with files from the bundle extracted to the file system and failed, probably because I'd just extracted a few by hand and left the actual bundle file sitting there. I also thought it could act as a mod manager, modders would just distribute the files needed for their own particular mod and a list of changes to make to existing files, and the tool would unbundle, apply the changes needed and rebundle. Then if somebody wanted to deactivate mod x and install mod y, it would be a simple matter for it to unbundle the file, undo x's changes, apply y's and rebundle again. So far I've failed pathetically at figuring out the bundle file format ( ), but I'm sure it'll come to me soon.
  5. I don't think it's really fair to compare HL2 with GRAW. As has been said there are serious differences in the two engines. Possibly the most amazing thing in GRAW is the combination of draw distance, the number and detail of the buildings and the lack of loading times. Playing just the first mission, my jaw hit the floor when I had the drone up on full screen and it climbed up over a building and scanned around looking for bad guys. The view was incredible, I've never seen anything else in any game to compare. Then I could instantly switch back to my own view several blocks away or to the view of any one of my team. Not only that but your can also switch instantly to the command map and pan and zoom, and see everything (explosions, muzzle flash, smoke etc). Contrast this with the small more enclosed HL2 areas and the fact that the game pauses every few minutes to load up the next section. Also while the near-in parts (and water especially) of the bit-tech image above look incredible (better than GRAW), the distant buildings are much less impressive and not as good as GRAW (imo)
  6. I'm not sure about this, but from looking in the quick.bundle file I think weapons were defined in the various XML files it contains. Once someone has figured the bundle file format out and we can extract the XML files and change them we'll have a better idea of what's possible to mod or not. (in fact if it is the way I think it is, then there's little to no point in having an SDK at all)
  7. As per this thread I've been looking into the bundle too, just using a hex/text for now, and there seems to be lot's of goodies that'll help with modding (and also stuff like disabling deferred lighting to enable AA), the Diesel engine looks to be really flexible and easily configurable through the xml files. The structure of the file as you point out is basic enough, at the start of it is a table listing the files and their locations, mainly xml files, their corresponding compiled xml.bin files and some binary resources. Altough somone pointed out in the full version feedback thread that the structure in the retail file seems slightly different to the demo one. I'm hoping I can pick up the retail in the next day or two and then throw something together over the weekend to pull all the files out of the bundle, edit the XML files, recompile them and bundle it all back together. IIRC, it looked like a lot of textures could be pointed too in the XML files, so for modding things like that I think it'll be easier to keep simply change the XML files to point to the new ones instead of trying to put them back in the bundle.
  8. Not sure if it's technically possible, having accelerated 3D across two monitors (altough I think some people have it for flight sims ?). Even if it is it would totally kill whatever frame rates you have, I think the GPU would have to keep alternating between rendering the main screen and rendering the tactical map. It would look very cool though
  9. Not yet actually, good idea, I'll see if I can try it later. Btw, edimensional now have a driver that works with ATi cards, try https://edimensional.com/support_updates.php
  10. Cheers, if it's a different structure I might aswell wait till I get my hands on it to see about extracting it.
  11. Anybody with the retail notice if it's still using the big bundle files or does it look like all the xml files are out in the directories ?
  12. Thanks Ravenmouth. I'd seen that english link and from what I understand of it a Round Robin Archive is something totally different to our bundle file.
  13. Thanks for that Dimz. The only info I could find on .rra files is that it could be a 'round robin archive', not sure yet what can be used to extract it but I'm sure there'll be something somewhere. The crashing can be caused by editing XML files in the bundle, at the start of the bundle is a table listing the embedded files and their location within the bundle. If the length of a file changes then all the files after that will be out of place and the game will crash when looking for them.
  14. Ok, no luck with anything so far. Changing values doesn't seem to have any effect (other than crashing the game if the structure is thrown out). I have noticed though that for each XML text file, there's a compiled binary version, so I'm assuming the game uses that instead. I've tried creating 'real' xml files in the hope that they'd override the ones in the bundle but that didn't do any good, nor did messing with the context.xml to try and get it to recognise my xml file. I think the way forward will be to extract the whole bundle, edit the xml files, recompile them and bundle them all up again.
  15. Thanks, was too busy looking for a complicated solution and totally overlooked the blindingly obvious. I've managed to change the value now, but it doesn't seem to have had an effect, I'll have to keep looking elsewhere I think. As far as I know post processing refers to effects added to a scene after it the geometrey and textures and stuff have been rendered, the HDR/Deferred lighting being one of them. Never thought of that, I'll try it out now.
  16. Hi guys anyone managed to edit the quick.bundle file, or better yet unpack the files and repack them ? There's some interesting looking stuff in there, including this possibly jucy little section <world pre_clear_flags="depth|stencil"> <viewport name="default"> <post_processor name="shadow_processor" active="true"/> <post_processor name="exposure_processor" active="true"/> <post_processor name="post_processor" active="true"/> <post_processor name="deferred" active="true"/> <post_processor name="crosscom_processor" active="false"/> </viewport> <viewport name="crosscom"> <post_processor name="shadow_processor" active="false"/> <post_processor name="exposure_processor" active="false"/> <post_processor name="post_processor" active="false"/> <post_processor name="deferred" active="false"/> <post_processor name="crosscom_processor" active="true"/> </viewport> </world> Take note of the line <post_processor name="deferred" active="true"/>, I've tried just changing it to "false", but then can't load the game (or even get as far as the intro videos), I can set it to "fals" and get into the game (it has no effect like this) which leads me to believe the extra character is throwing the file structure out as opposed to some kind of crc or anti-cheat check. There's other interesting looking stuff in there too, I might do up a list later on.
  17. Good post jsonedecker, that explains it very well. Just to re-add what I posted earlier... The driver/api is SEPERATE to the tray icon. The driver/api is required, the tray icon is not and can be disabled without impacting the game. Ageia provides the installer for the driver/api, and as part of that the tray icon gets installed as a means of configuring/updating the driver/api and the game devs don't really have any control over it.
  18. From what I can make out, it's the Ageia runtime/drivers that are required. As part of Ageia's installer for these, the tray icon applet also gets installed, disabling the tray icon seems to have no adverse effect on the game and as far as I can tell, means that no extra resources are being used.
  19. Right-click on the icon, pick settings, in the settings tab uncheck 'Show System Tray Icon'. Problem solved (game still plays fine and the icon won't re-appear) Altough I do agree that the problem shouldn't have been there in the first place, too many applications these days think they should have pointless background processes running and systray icons. (not really GRINs fault in this case, GRAW needs the Ageia drivers which install it, it's all Ageia's fault)
  20. I've used XML with comments recently and iirc correctly the comment marker was something similar to html, e.g. <!-- Comment goes here --> I'm not sure what affect the '/' vs the '\' would have, I'm very probably wrong here but I think that in general C file/stream APIs can use either for valid file paths. Another possibility is that '\' is to be used for files which exist in the windows file system and '/' for ones which are embedded in larger resource files. I know that doesn't really add much to the discussion either way, sorry, but there's just too many variables, without having worked on the game code ourselves we have no chance of figuring out the effect of not having these files.
  21. Hehe, no offense meant but the contradiction in your post is pretty funny You seem to realise that that having 'such huge landscapes' is a technical challenge and yet seem to expect them to be able to 'optimise' it to great framerates. Let's compare GRAW to a game that people consider to be well optomised, such as HL2. In HL2, for me at least with only one measly gig of ram, the game would pause every minute or two to load up the next coridor or alleyway. It would also pause with a loading screen every 5-10 minutes, and on top of that it would stop to load each level. This was fine for HL2 but in the context of GRAW that would be completely unacceptable, imagine turning a corner and having to wait a few seconds for the geometre/textures etc to load, that would be a horrific handicap in a game like this. GRIN have said that not only can we move from street to street, and area to are with no loading, which is exactly how a game like this NEEDS to be, but there's also no loading between missions, we move seamlessly from one to the next. This in effect means that Mexico City is one giant sandbox for us to play in. The only other recent games I know of that attempted anything like this are Boiling Point (the less said about this the better) and and Oblivion, which despite having many loading points and alot of dynamically generated stuff (vegetation etc) is still a system hog. People keep talking about 'optimisation' as if GRIN (or any other developer) can just wave some magic optimising wand over a game and suddenly everything will run a lot better (some idiot even posted somewhere that any modern game could run on a Geforce 2 if devs just optomised their games). I've only done a small bit of Direct3D programming, but (and I'm 99%sure the sam holds true for any 3d programming) the only way to have the kind of large, open, multi-route landscapes that GRAW does is to either use a huge chunk of CPU time to work out what does and does not need to be rendered or throw a ######-load of geometry and textures at the GPU and let it work out what needs to be displayed. Considering all the other stuff the CPU has to handle, I personally think the latter of those options is the best. The bottom line is that GRIN could have, and most likely did optimise the ###### out of this game and it would still take a hell of a lot of power to run. (I'm going to put this next part all in caps because many people with super-high-end rigs are complaining about performance without listening to what others are saying. This is not aimed at the original post or poster) MY RIG= A64 3200+, 1GB CHEAP RAM, 128MB 6800NU AND THE DEMO RUNS PERFECTLY @ 1280*960 WITH EVERYTHING HIGH (except textures)
  22. The game only renders on each individuals machine the area that the individual is in. That is, it doesn't matter to rendering how many different areas people are in, each persons machine only needs to render what's around them. There's only 2 reasons I can think of for it, one is to keep people 'on mission' (or at least the games interpretation of it) the other is that nothing actually exists outside those areas (no building, no street to walk on etc). Of course I could be proven totally wrong if a whole team tried to go off some way and they were able to.
  23. Prefer it on myself, altough it doesn't seem as strong on my rig as it does on the screenies shown here, might be to do with my GPU. I definitly prefer the command map and especially the black and white cross-com feed with it on. I think the b&w cross-com is one of the best looking things in the game .
  24. The two gainward cards at overclockers (see http://www.overclockers.co.uk/acatalog/Onl...eries_363.html), the Bliss 7800GS and 7800GS+ are actually a 7800GT and 7900GT respectivly. These are the two best AGP cards available by a mile. They're not official nVidia models though, Gainward themselves bought in the PCIe GT chips instead of AGP GS's and bolted them on to AGP cards with bridge chips. Because of this there's a bit of a premium included in the price. The Techamok article is a bit confusing, I don't know are they referring to the Gainward cards, or if they mean that there will be official nVidia models released, which would drive down the price of the Gainward cards as they won't be the only ones with GTs on AGP any more.
  25. I agree with the sentiments of this thread completely. The thing that makes GR.Net great (and so much better than Ubi's own forums) is that things get discussed in a mature sensible manner. Unfotunatly, with the release of the demo many people (I won't name any names, it's fairly obvious who they all are) seem to have reverted to infancy and started throwing their toys out of the pram at every oppertunity. Fair enough some people are having geniune issues but there's ways to address them which don't involve dragging every second thread down with temper tantrums, threats, wild claims and crazy accusations. I really feel sorry the admins/mods having to try and sort this mess out while still trying to keep a good balance to the forum, not to mention finding time to have real lives and play the demo themselves (thanks for all the hard work guys and gals, we do appreciate it).
×
×
  • Create New...