Crossfire Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CF: light bug?
There are probably several map attributes that need to be added for future
expansion. A quick list off the top of my head:
indoor/outdoor flag: This would determine if weather affects the (snow, rain,
etc). It should also be used to determine if flying gains benefits or not (ie,
on an outdoor map, in theory you should be able to fly above the trees, not
have blocks view by trees, and not be slowed down. Flying indoors should gain
less (eliminate terrain loss, but still be hit by blocks view type of objects,
since you can not fly above teh walls.)
natural_light flag: Determines if the map gets its light from natural (ie,
the sun) sources. Outdoors map would generally have this set to true, indoor
maps to false.
There might be some others. It is probably easier to add the flags now and
ignore them, so that as you go through and update the map, you can update all
the flags at once, vs doing one now, and then 3 months down the road, going
through the maps again and updating it for something else,then 3 months later,
updating it for yet something else, and so on.
I personally don't like using realtime to base stuff on - rather, there should
be an internal time in crossfire (1 hour realtime = 1 day crossfire time
maybe?) This actually probably wouldn't be too hard to do - each tick could be
used as the internal time metric - the only thing requiring any work would be
to store the tick count accross runs, but even that would be pretty easy to do
(when server goes down, write it out to a file. While serving is running, do a
periodic write to that file also.)
If we want to really go with time, then there is much more to do:
1) some buildings (ie, shops) should be closed at certain times. In fact, for
shops, it might make sense for them to open at 8 am, close at 6 pm, and reset
during the night, but never during the day.
2) time controls should be added to objects. Objects do certain things at
certain times. A very simple example of this might be a window in a tavern.
During the day, these windows should give out light, but at night, they
shouldn't. Likewise, any torches/other sources of light in the tavern should
be lit at night, but not during the day.
The way to probably do that is have a time trigger in the object, and when
that trigger is hit, switch to the other_arch field. Then that other arch has
another time trigger, and switches to yet another other_arch. In theory, very
complex loops could then be done. Unfortunately, this would require a bunch of
new archetypes. Another more flexible method might be to use an objects
inventory - same general idea, but when we switch, the first object in the
inventory becomes the active object, the rest of the objects become part of
that new objects inventory, and the old object gets put on the end of the
inventory.
--
-- Mark Wedel
mark@pyramid.com
[to unsubscribe etc., send mail to crossfire-request@ifi.uio.no]
Follow-Ups:
References: