Wrote a few world weapons examples maps this week,
so I figured I'd post some pictures. If anyone wants the
map files, just lemme know. These are big pictures, so
the download is about 700K.
http://members.rogers.com/trepan/weapons.html
World weapons pictures
-
Terminator
- Private First Class
- Posts: 45
- Joined: Mon Dec 23, 2002 10:05 pm
- Location: England
Trepan can you post the script ..please.
weapon
name Fontain_of_Peace (free from the weapons)
position 0.0 0.0 0.0
rotation 0.0
initdelay 10.0
delay 100000.0 7000000.0 50000000.0 500000.0
type TH
end
weapon
name Fontain_of_Peace (free from the weapons)
position 0.0 0.0 0.0
rotation 0.0
initdelay 10.0
delay 100000.0 7000000.0 50000000.0 500000.0
type TH
end
Last edited by SGI on Wed Feb 25, 2004 10:35 pm, edited 1 time in total.
-
Homonculus
- Private First Class
- Posts: 29
- Joined: Wed Dec 24, 2003 8:10 pm
I've put the maps up as a ZIP file at the following location:
http://members.rogers.com/trepan/weapons_maps.zip
You really should read the included README.TXT before
trying to run any of them. A patch is required for BZFS to
improve the world weapons timing. A patch is also required
for bzfs 1.10.4 to get it to steal flags using a THief world
weapon.
enjoy,
trepan.
P.S. Creeperz, yup, lotsa free time
The source code for my mapping program is ~350Kbyte.
P.P.S. A few thoughts on world weapons (a little rant'ish):
1. They eat bandwidth. Each shot gets send to each conencted
player, so be wary.
2. World weapons are new and cool, but don't go overboard
(like me). IMHO, the best part of bzflag is the multiplayer aspect.
Getting continually killed by a scheduled weapon just doesn't
seem like a good way to kill time. That's also the reason I've tried
to keep my maps somewhat patterned (as opposed to a random
SW tsunami that strikes the entire map).
3. It might be good to eventually have the clients process the
world weapons shots. This would both save on bandwidth and
facilitate triggered world weapons (proximity, teleporter, driving-
over triggers might be fun). It would require NTP style syncing.
4. The maps that have a lot of reflectors in them can cause client
stuttering because of the amount of processing required to figure
out what each shot is doing. If the world weapons shots are ever
migrated client-side, then I would also suggest putting the path
information into the map (as multiple positions?). Not only would
it cut down on processing time, but it would also avoid unseemly
floating point errors that might crop up on different OSes. These
paths would have to be checked when the map is loaded to see if
they might hit other objects (or not checked, whatever)
5. Phew, rant done, I feel better, how 'bout you?
http://members.rogers.com/trepan/weapons_maps.zip
You really should read the included README.TXT before
trying to run any of them. A patch is required for BZFS to
improve the world weapons timing. A patch is also required
for bzfs 1.10.4 to get it to steal flags using a THief world
weapon.
enjoy,
trepan.
P.S. Creeperz, yup, lotsa free time
The source code for my mapping program is ~350Kbyte.
P.P.S. A few thoughts on world weapons (a little rant'ish):
1. They eat bandwidth. Each shot gets send to each conencted
player, so be wary.
2. World weapons are new and cool, but don't go overboard
(like me). IMHO, the best part of bzflag is the multiplayer aspect.
Getting continually killed by a scheduled weapon just doesn't
seem like a good way to kill time. That's also the reason I've tried
to keep my maps somewhat patterned (as opposed to a random
SW tsunami that strikes the entire map).
3. It might be good to eventually have the clients process the
world weapons shots. This would both save on bandwidth and
facilitate triggered world weapons (proximity, teleporter, driving-
over triggers might be fun). It would require NTP style syncing.
4. The maps that have a lot of reflectors in them can cause client
stuttering because of the amount of processing required to figure
out what each shot is doing. If the world weapons shots are ever
migrated client-side, then I would also suggest putting the path
information into the map (as multiple positions?). Not only would
it cut down on processing time, but it would also avoid unseemly
floating point errors that might crop up on different OSes. These
paths would have to be checked when the map is loaded to see if
they might hit other objects (or not checked, whatever)
5. Phew, rant done, I feel better, how 'bout you?