Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by CrazyMahone

  1. Thanks ... that's a great idea. There are 878 NPC's scattered in 300+ spawn points locations. What causes the lag is all the paths the NPC's are following ... I code about 40% of the spawn points have paths and 70% are ping-pong recon. This is not a "1 death/player" map ... though in testing (because I know where the NPC's are, I can usually take out 80-120 before I make a mistake and get popped. The last half of the map contains 2/3rds of the NPC's.
  2. Allison Point - Part 2 has finally reached an Alpha stage. Editing is a very slow process because my machine clunks along at 5 frames/second while editing the NPC's. (8800 GTX) This is the introductory text to wet your appetite: "Destroying that fuel dump (Part 1) sure #&@!(@ them off. In this mission you need to destroy their battle plans at the top of the point before reaching the extraction point. We got a garbled recon report that said 'Holy crap, there's over 8 down there'. However, we're pretty sure there is a few more. So to air on the side of caution, bring extra everything. And maybe a special goodbye to love ones ... just in case." As soon as I can figure out how to script helicopters, it will be in BETA and I'll be able to release it to the killing public out there. In early tests show that it's a tough slog with 5 hardcore fighters. You'll see us testing it on "K R E B". And yes, there is plans for Part 3.
  3. I don't know if this is a mod setting or something else, but how do you set up a server so that others connecting to it can download the map you currently have loaded? Thanks in advance. - Crazy
  4. Allison Point - Part 2 - Preview FileFront Image Link
  5. Blowing up the fuel dump at the end ... that's assuming you're interested in blowing stuff up ...
  6. Goodie ... That's pretty much the scope of the objectives.
  7. Allison Point Allison Point is a new map built using part of the Mission #8 map. This map consists of two parts, where the second part will be released in the future. In this part your objective is to investigate parts of the map and ultimately destroy the fuel dump. It's a tough slog even for the hardiest of soldiers. There are plenty of bad guys to keep you busy and annoy you; over 360. Good Luck ... Link to Filefront to download Allison Point (7z) map and concept by Crazy Mahone This map is in BETA. Please report any errors to this forum post.
  8. I doubt we'll even bother installing this on our server - clearly you have a different target audience for your map. We only play single death and a map with enough sniper cones to obstruct the landscape clearly can't be played in any semi-realistic way. Sometimes less is more... This map is officially dead. It died because of the mixed textures issue that I honestly didn't want to solve because it meant deleting 40-60% of the map in order to fix it. This was my first map, and I was looking for feedback from my playing buddies as to what worked didn't work. I am working on two others ... Allison Point (and Allison Point Part 2). Part 2 is just started and I am working on different tactics of the enemy. Both are designed to be "playable" by groups, but a significant challenge (perhaps impossible) by an individual. If you're into "one death" type of play, this map is probably too difficult without a team of at least 8, because you need a variety of weapons to defeat the foe presented, but it might be worth the challenge. I play with 3 others in hardcore and it's a tough job making it to the end in two hours. Once I figure out how to program objectives, I can release it into the wild. - CM
  9. Actually a 32-bit application can address 4Gb of memory 2^32-1 bytes. Windows implements virtual memory, so the maximum addressable space is 4Gb even if you have only 1Gb of actual memory. Creating your own virtual memory greater than 4Gb is a waste of time. Things like your video card eat away at the total space. I run a 8800 GTX which has 768 Mb. So my total addressable windows memory space is 3.2 Gb. On Vista 64, the video card doesn't eat up the memory. Virtual memory works using a table and a hard-drive disk cache (called Windows Swap). Suppose the virtual memory total size is 3.5 Gb and you have 512 Mb of RAM, then the operating system uses the table to identify what is in physical memory and what is on virtual memory disk. To do any processing, the operating system reports to applications that there is 2Gb of memory and the programs work as if 2Gb is present. The OS keeps a count of the number of accesses to a block of memory. When an application requests some memory that is currently in virtual memory, it looks for the block least used and writes it to virtual memory, then loads the requested memory onto that physical space, then returns control to the application. Where the virtual memory is loaded into physical memory has nothing to do with it's address. The virtual memory table takes care of it. So memory block A,B,C,D might be in physical memory slot 4,1,2,3. Cheers, - CM
  10. I cannot seem to find any description as to when you can and cannot render lightmaps. For example, I am currently modifying Mission 08 which has a substantial number of lightmaps. When can I not render lightmaps for a map, and when must I do it? Essentially I want to render the maps once (in medium quality; overnight), and then know when I have to re-render them ... assuming I have a choice. Can somebody point me to the right answers. Tx, - CM
  11. Does anybody know how to change the auto-save frequency in the editor? Right now it auto-saves every 5 min, I'd like to reduce it to 15 min or shut it off completely. Is that possible? -CM
  12. (I'll hijack and say ...) The three things that bug me about GRAW2. #1 a sniper rifle to the chest isn't enough to take somebody down, but more so than this, if you hit the bot in the chest, they shouldn't be able to get up a second later, aim and shoot me in the head. Though I have never fired a real gun or been to war, it just doesn't seem all that realistic. You either kill them the first time or your dead; it gets to be tiring after a while -- not much fun. #2; it's possible to get killed on a hill, where you cannot see the enemy, but they are able to see you and kill you by shooting through the top of the hill. #3 no [GR] mode. I was hoping they'd fix it ... sounds like they won't be. - CM
  13. Texture Scope: <scope> <xi:include href="/data/settings/set_texture_scope_editor.xml#xpointer(/include/common/*)"/> <xi:include href="/data/settings/set_texture_scope_editor.xml#xpointer(/include/historical/*)"/> <xi:include href="/data/settings/set_texture_scope_editor.xml#xpointer(/include/city/*)"/> <xi:include href="/data/settings/set_texture_scope_editor.xml#xpointer(/include/industrial/*)"/> <xi:include href="/data/settings/set_texture_scope_editor.xml#xpointer(/include/ghetto/*)"/> <texture_set name="atlas_mission_specific/mission02_specific/cube" /> <texture_set name="atlas_mission_spec_editor/backdrop_cube_d" /> <texture_set name="atlas_graffiti/atlas_graffiti_01" /> <texture_set name="custom_levels/the elephant's head/lightmaps" /> <texture_set name="atlas_props" /> </scope> You can grab the full bundle here ... The Elephant's Head ... the map is perhaps 50-55% done.
  14. I have a new rendering error. Previously I had the ground and walls not render properly but a mod to the Texture xml document resolved the issue. The new problem is that my guns, ghosts, bots and trees are all shades of green. I was getting rid of the problem by rebooting the computer, but these days this work-a-round isn't fixing the issue. I could post a pick but all you'd see is green of a lot the things I've described. The ground, walls, buildings and other propers are all rendering properly. Anybody seen this behaviour and got a fix? thanks, - CM
  15. Thank you sir, this is an excellent tutorial.
  16. Well, the nice thing is, I'll just keep modifying the utility for my own benefit. It's now modified for guns, vehicles, tanks, helicopters, and other special conditions.
  17. Okay, it's working but not working. I have a guy mounted on an MK19 which I assume should be firing bullets. He's not. He's firing rocket propelled grenades. I don't think he's supposed to do that because the prop graphic for the gun clearly shows .50 calibre bullets. Of course, I'm hoping I've discovered something fiendishly evil. PROP: <unit name="mk19" unit_id="15475" name_id="gun_0" cover_off="false"> <position pos_x="-4396" pos_y="63629" pos_z="-1.5258789e-005"/> <rotation yaw="0" pitch="0" roll="-179.99583"/> </unit> HUMAN: <unit name="group_unit" group="mex_guerilla_recon1" group_id="gun_0" vehicle_id="none" crew="false"> <order order="Guard" source_pos="-4389.9897 63770.59 0" order_pos="-4389.9897 64270.59 -3.0517578e-005" patrol_type="moveguard_recon"> </order> <position pos_x="-4389.9897" pos_y="63770.59" pos_z="199.99997"/> <rotation yaw="0" pitch="0" roll="0"/> </unit> AREA DEFINITION: <area name="gun_0_spawn"> <shape type="box" length="-2187.5742" width="-259.72266" height="0"> <position pos_x="-5036.3877" pos_y="58013.023" pos_z="0"/> </shape> </area> MISSION SCRIPT ELEMENTS: There are other elements in the start_game that I excluded. <area_group name="gun_0_spawn" area_name="gun_0_spawn" group="mp_players" interval="0.3" condition="1"/> <user name="user" type="once"> <trigger type="UnitInArea" area="gun_0_spawn"/> <event name="activate_gun_0_spawn"/> </user> <event name="activate_gun_0_spawn"> <element type="ActivateGroup" group_id="gun_0" start_time="2"/> <element type="UnitInArea" area="gun_0_spawn" state="deactivate" start_time="3"/> </event> <event name="start_game"> <element type="UnitInArea" area="gun_0_spawn" state="activate" start_time="3"/> </event>
  18. Certainly heard the term bot, but this is my first map and I am learning a ton of stuff ... but bot could mean anything when you are just learning.
  19. It didn't work ... which meant I'm not sure what you meant by a bot. Is that a type of human, or just your term for human. Anyway ... Here's what I did ... I added a gun ... specifically a "mk19" and called it "gun_4". Next I took one of my human units and attributes where: name=gun_4 order=none transport=none crew=unchecked GroupID=human_1 GroupType=mex_ranger_support The group is spawned at the start of the game, but it didn't work ... in fact, when saving, it erased the name of "gun_4" and replaced it with "none". Clearly I didn't get it. Okay figured it out ... well, I didn't but the recent FishMonger tutorial talks about it.
  20. It didn't work ... which meant I'm not sure what you meant by a bot. Is that a type of human, or just your term for human. Anyway ... Here's what I did ... I added a gun ... specifically a "mk19" and called it "gun_4". Next I took one of my human units and attributes where: name=gun_4 order=none transport=none crew=unchecked GroupID=human_1 GroupType=mex_ranger_support The group is spawned at the start of the game, but it didn't work ... in fact, when saving, it erased the name of "gun_4" and replaced it with "none". Clearly I didn't get it.
  21. I cannot figure out how to create a human who can operate a 50-calibre machine gun. I've tried various human types and placed them physically on/next to the 50-calibre machine gun turret, but they're not smart enough to use it. Is it a particular type of human, or do I script it to attach the human to the gun. If so how?
  22. FRAPS reminded me that I have GameCam. Does the same sort of thing.
  23. Well, the best way to reply is to say this is my first map. Got to learn to walk before you can run. Generating the grass and walls seemed like the best way to go to begin with ... in hindsight, probably not a good plan. But the map I have produced 1/3 done is pretty brutal ... a tough haul - 177 kills. Even in "easy" (usually play Hard or Hardcore) and knowing the locations of all the "bad guys" I still got myself killed 30-40 times in my tests -- there is a couple of snipers in the mission (see below). But that's the intent ... to make it really difficult, however, I've added a sense of tactics to the map, so that a brute-force method will get you killed, but a tactical approach will get you killed less. Anyway, to set up the standard "enemies", I'm also writing some world.xml management utilities. The first is called GRAW Spawn Buddy. You first identify the locations of all your "enemies" on the map, but you don't give them a "group id". Next you draw out a series of areas. One area is called "human_area_#" (where # is a number 1 to whatever). Another area is called "human_spawn_#" (same # as the area). You go into your world file and copy-and-paste the "area" definitions and the "human" definitions into the software. What the program does is update the XML for the human's identifying which area the human falls within. It then ties the spawn location to the humans that fall within the area and modifies the XML for the humans to identify the GroupID (groups are named "human_#"), and you paste this XML back into the world.xml file. It also generates elements for your mission.xml script to create "area group", "user triggers" and "event" definitions for the groups. The software also identifies humans that fall outside of the "human_area_#" boundaries. It's also kind of smart in that once an enemy has a group assigned it's not assigned again. This allows you to have overlapping areas and not be concerned about where a human is mapped first. For example a smaller area inside of a larger area only needs to have a smaller # and all the humans in that smaller area get the group assigned first. I did it this way because I figure it would be a pain in the butt to first set up spawn locations and tie them to a map with a hundreds of "enemies" on it (my goal). It might be okay when you set up the enemies, but then it becomes painful when you want reorganize when or where you spawn the enemies as you test and validate your map on the ground. In the example below, I've reorganized the groups about 2-3 times to come up with some that is cleaner. I also found it became far easier to add a lot of "enemies" to the map, because I didn't need to worry about group assignments. I'm not sure if any of you have a similar issue. As I learn to make maps, I'll write more utilities to further simplify the process. I'm also hoping this work can be applied to GRAW 2 ... though I'm not as fond of that version because it's missing an OCR Cooperative mode.
  24. I'm having a rendering error where after a Medium render, I get whacky walls and ground. Walls are green/black blobs and the ground are orange blue blobs. As shown below. How do I render "normal" walls and ground, do I have to render High, delete the lightmaps first? Any ideas? (by the way, getting this screen grab was painful ... had to put GRAW into a window then do a screen print shot. is there a better way? -- see my other post)
  25. This may seem like a dumb question, but how do I take a screenshot? If I'm in the editor, hitting the "Print Scrn" button doesn't seem to actually take a picture. Is there another way or is it an error between the chair and keyboard? - CM
  • Create New...