CrazyMahone
-
Posts
26 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Events
Posts posted by CrazyMahone
-
-
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.
-
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
-
-
Blowing up the fuel dump at the end ... that's assuming you're interested in blowing stuff up ...
-
well real objectives wont work, thats right.
but u can create waypoints and script some kind of objectives.
useing unit destroyed or area triggers
Goodie ... That's pretty much the scope of the objectives.
-
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.
-
But the map I have produced 1/3 done is pretty brutal ... a tough haul
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
-
well bear in mind that a 32 bit OS can only assign ~900MB to 1 application
when u have a big map u can see the difference what the graphic settings do to the system ram.
take a look in 800 x 600 windowmode and the play around with the graphics,
u will see in teh taskmanager that the usage of system ram will go up and down, due
to the settings u swithing.
and when u start to render it u will see how the system ram is loading and loading and ups its tooo much
so under a 64 bit OS that problem shouldnt exist.
did some1 try to render with a 64bit OS?
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
-
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
-
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
-
Here's why I am making GRAW1 maps: GRAW 2 completely sucks for online coop play, so this is still the game to make maps for. Bottom line - I haven't touched GRAW2 since I realized that the AI bots there shoot you with deadly acuracy well before they even get into your drawing distance. The game is broken in many respects and there won't be a fix, because they are already giving it away for free, plus they want to sell you an even more watered-down GRAW3 in a few months. Not for me. We play with a full server almost every night in GRAW1 and I doubt that will change anytime soon.
Going to continue with the tutorial in a day or two - am swamped right now trying to finish a new map, which is a remake of the Mission08 terrain. It'll be released in two versions, one hardcore (single death) and one loaded with crazy AI for the respawn crowd who doesn't mind dying 10 times before they make it to the finish.
(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
-
post your texture scope please
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.
-
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
-
probably a year too late, but since I just spent a few weeks figuring out how to do this map thing, I realize that there were a few things that I could not find explained anywhere on the net. So to save some other folks time who are late to the GRAW map making party, here's what I am putting together for the guys I usually play with - in the hope that I am not the only one making new maps this year. The tutorial focuses on how to remake existing GRIN maps into [GR] maps, but I'm sure you can pick up a few things from it even if you want to make a different type of map.
http://www.thegamerplanet.com/forums/showthread.php?t=18075
Thank you sir, this is an excellent tutorial.
-
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.
-
example how it should look like, taken out of a original map
<unit name="group_unit" group="mex_infantry_patrol1" group_id="base_mg2" vehicle_id="none" crew="false">
<order order="Guard" source_pos="-6792.8447 -19680.805 495.77448" order_pos="-7410.6191 -17857.822 496.38269" patrol_type="moveguard_recon">
</order>
<position pos_x="-6792.8447" pos_y="-19680.805" pos_z="695.77448"/>
<rotation yaw="0" pitch="0" roll="0"/>
</unit>
<unit name="m2hb_tripod" unit_id="4070" name_id="base_mg2" cover_off="false">
<position pos_x="-6962" pos_y="-19480" pos_z="489.80954"/>
<rotation yaw="0" pitch="0" roll="12.710446"/>
</unit>
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>
-
btw, with bot i mean an ai controlled human.
never heard the word bot?
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.
-
the gun and the bot need the same name,
then just activate the bot in the script like u normaly do
he will spawn on the gun
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.
- name=gun_4
-
the gun and the bot need the same name,
then just activate the bot in the script like u normaly do
he will spawn on the gun
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.
- name=gun_4
-
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?
-
run Fraps and it allows screen shots out of any D3D application, or hit printscreen, tab out of the editor and open an imaging app, hit paste and there you have it.
FRAPS reminded me that I have GameCam. Does the same sort of thing.
-
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.
-
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)
-
can you post a screenshot of what the resulting map looks like? sounds like a flat grass plane with a bunch of labyrinth walls is what this is best used for. Not my cup of tea, unless I don't understand the capabilities it has.
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
New OGR Map: Allison Point
in GR:AW - Map Modding
Posted
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.