Re: [crossfire] Crossfire 2.0+ features/priorities
Brendan Lally wrote: > On 2/1/06, Miguel Ghobangieno <[EMAIL PROTECTED]> wrote: >> And a setting to show (by default) 1 attack message >> per second or so (rather then "char punches once, and >> again, and SUPRISE again!"). > > I want the rate of attacks to be down to about one (or two at most) a > second - at least for 'normal' weapons (like broadswords). Try > swinging a sword more than twice a second consistantly, and then you > will see why I think this a reasonable limit (yes, you can do more > with a fencing sword like a foil or epee, but they don't do much > damage anyway, if someone wants to add them with stupidly high weapon > speeds, they could still do so). - having fewer attacks means more > time to think in combat, less hack and slash, more strategy, and less > CPU overhead too. The counter of course is that crossfire doesn't mimic real time - IIRC, time in the crossfire world is 8-10 times faster than real-time. That said, I wholeheartedly agree that crossfire is too fast, so should be slowed down. Slowing it down would have another effect, that being that it would take longer to kill stuff, and thus money would be accumulated slower (As well as exp, and/or alternate ways of exp become more valuable). But if physical attacks are slowed downs, spells also have to be moderated in some way. And that can start to get trickier if the player has multiple wands/etc. That said, if the smooth movement stuff is a high priority item, I'd think that would completely redo movement and actions, and that could be the time to fix it then. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Bigworld-ized pupland status?
And so says Miguel Ghobangieno on 02/02/06 01:38... > What's the status on bigworldized pupland (IE: when is > it going in?). /me awaits the glorious addittion. Snapshot is up at http://lalo.revisioncontrol.net/crossfire/ Next in the TODO list: - Re-do the Nurnberg castle, it's so out of scale it's ugly - Paste the contents of Lone Town - Add exits to the army camp, weapon research lab, tower of ordail, barbarian ruins - Add the freedom army's clandestine port - Fix all exits in /pup_land (isn't there a script to do this?) - Release/merge - Do the Rainbow Islands - Release/merge - Work on other quests on the continent best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical:http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] cfclient colouring
Brendan Lally wrote: > On 2/1/06, Mark Wedel <[EMAIL PROTECTED]> wrote: >> Brendan Lally wrote: >> actually, I don't think there is anything specific about using 16 colors. >> I >> think it was just that 16 colors were used - it could very well be 12 or 25 >> - as >> far as X is concerned, it doesn't care (unless someone only had 4 bit color, >> but >> I don't know if such hardware ever existed). > > ega cards on (very) old IBM PCs support only 16 displayable colours, I > don't know if they can run X though. - in any case their resolution > probably wouldn't be enough to show the entire screen. And they'd have the same issue with all the graphics themselves - I can't imagine that the existing graphics reduced to 16 colors would look very good. > >> Private colormap is a leftover from 8 bit display - most 8 bit hardware >> could >> only display 256 different colors at a time, but out of the palette of 16 >> million (24 bit color). So one would use colormaps to determine what colors >> of >> the palette your are drawing. > > Is that why I have seen colours shift with application focus on very > old sparc systems running X? Yep. Since only 256 colors could be displayed at a time, if you want best image selection, you'd allocate a private colormap so one could get all 256 colors for their own application and not share those with other applications. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Transports
Lalo Martins wrote: > Which leads to another idea - some transports could be set up to behave > as pets when unpiloted (behave as pets, not count as pets - killpets > shouldn't kill them), so that you have 2 horses, you put your stuff on > one, mount the other, and the "cargo" horse follows you. If on another > adventure you have an ally, he can borrow your second horse and mount it > normally. Probably wouldn't be too hard, but there may be some issues as related to the object actually moving and not (the object would have to have speed). But you also perhaps get odd issues - I shouldn't be able to load the horse to the max so I don't carry anything, and then run home and have that horse 'teleport' like pets do to keep up my pace. If I run away, that horse should just stop moving. The problem here is the map transitions - for example, if I'm returning to scorn, my horse should follow me into the gatehouse if nearby. But if he is 10 maps away, he shouldn't. The problem right now I think is that the pets don't catch up until they move. So what happens, players moves onto gatehouse, the pet moves, but it has no real clue how close/far it was from the player. This could perhaps get fixed by adding some special code for when the player changes map to also moves the pets at that moment. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Transports
> > Also, how about setting up shipping routes and roads by placing > directors for transport on them? Is the point here to have boats automatically sail from point A to B, or to give players a clue? If the idea is to give players a clue, I think some other things could be more useful - buoys to mark routes, light houses to mark points, etc. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities
On 2/1/06, Miguel Ghobangieno <[EMAIL PROTECTED]> wrote: > And a setting to show (by default) 1 attack message > per second or so (rather then "char punches once, and > again, and SUPRISE again!"). I want the rate of attacks to be down to about one (or two at most) a second - at least for 'normal' weapons (like broadswords). Try swinging a sword more than twice a second consistantly, and then you will see why I think this a reasonable limit (yes, you can do more with a fencing sword like a foil or epee, but they don't do much damage anyway, if someone wants to add them with stupidly high weapon speeds, they could still do so). - having fewer attacks means more time to think in combat, less hack and slash, more strategy, and less CPU overhead too. > I > don't think we should mess with the amount of hp > clients or monsters get nor the weap attributes. I want to get rid of reflect spells and reflect arrows as abilities, I think they too effectively nerf lightning spells, and make cone spells to useful. However I would like to have a 'recast' spell, which would cast a copy of any spell that hits a player in the opposite direction for a short period of time (couple of seconds). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities
I think we should have plots and reputation system in for 2.0. And a setting to show (by default) 1 attack message per second or so (rather then "char punches once, and again, and SUPRISE again!"). It would also be good if the int for hp, maxhp, sp, and maxsp (used for alters) was raised to int 32 (it's int 16 now, right?). I don't think we should mess with the amount of hp clients or monsters get nor the weap attributes. We may want to explore the use of regents or something for spells as talked about before (you need this before you can cast uber powerfull spell). More spells... such as circular spells (not 'nova spells', orbiting spells: ring of fireball, etc etc) might be nice too. Transports would be good too. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Bigworld-ized pupland status?
What's the status on bigworldized pupland (IE: when is it going in?). /me awaits the glorious addittion. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Transports
On 01/02/06, Brendan Lally <[EMAIL PROTECTED]> wrote: > On 2/1/06, Alex Schultz <[EMAIL PROTECTED]> wrote: > > Well, IMHO this may not add too much for the player to use, but I can > > see it as something that would add alot of depth to the gameplay. Not > > sure how worth it it would be to do though, as it is indeed alot of > > complication, though I would say it would certainly improve the player > > experience. > > The small ships would be fine I think, as long as they can still > 'attack' each other and have such an event create a 'battle' map, > where there are two ships with all their occupants, plus cannons, etc > to fight each other. (there could then be pirate ships patrolling just > outside the main shipping lanes, and on PVP servers, groups of players > could be pirates themselves). By seperate map I meant something more along the lines of "pocket dimension" that a large transport will have, without any representation of the surrounding world. Yes, it would add a lot of complexity, so perhaps it would be best to leave that as a possible extension for the transport system in the future, and get a working transport system first. Also, how about setting up shipping routes and roads by placing directors for transport on them? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Transports
On 2/1/06, Alex Schultz <[EMAIL PROTECTED]> wrote: > Well, IMHO this may not add too much for the player to use, but I can > see it as something that would add alot of depth to the gameplay. Not > sure how worth it it would be to do though, as it is indeed alot of > complication, though I would say it would certainly improve the player > experience. The small ships would be fine I think, as long as they can still 'attack' each other and have such an event create a 'battle' map, where there are two ships with all their occupants, plus cannons, etc to fight each other. (there could then be pirate ships patrolling just outside the main shipping lanes, and on PVP servers, groups of players could be pirates themselves). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Transports
Mark Wedel wrote: >1) I had thought about transports having maps associated with them (map of a >ship, etc). But that adds a lot of complication - first, you need to somehow >make those maps unique, update exits, etc. But also, you get issues of actual >appearance. IMO, when driving around/whatever, you just want a relative small >thing moving about. So you would have the case that you enter/board the ship, >it takes you to a new map, but then to sail it, you then have to transition >back >to it just being the ship icon, not the entire map. To me, this just adds a >lot >of complication without adding a whole bunch. > Well, IMHO this may not add too much for the player to use, but I can see it as something that would add alot of depth to the gameplay. Not sure how worth it it would be to do though, as it is indeed alot of complication, though I would say it would certainly improve the player experience. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities
I think a better solution would be to, rather then show every attack message, only show one every 1 second or so. Friendly fire is setable in the settings file and can be set low to compensate. --- Mark Wedel <[EMAIL PROTECTED]> wrote: > But this is also tied to player speed. Unless you > make attack speeds really > slow, but that doesn't work will with current > movement code - really, attack > speed I don't think has much effect if it is slower > than the players normal speed. > > So I think without some significant changes, hard > to slow it down to the point > you can read it out without some major > restructuring. If we say the player > speed is 0.5, that is still 4 attacks/second. > > I think to be at a 'readable' pace, it would need > to be closer to about 1 > attack/second. But you still want to move at a > reasonable pace. So to do that > 'slow' attack, you'd need some code restructuring - > basically, you'd have to > have a separate 'weapon_speed_left' variable or the > like - if you try to move > onto a monster, if your weapon_speed_left is less > than zero, you just can't move > there (right now, you'd attack the monster). > > I had suggested a long time ago adding something > like 'damage factor' as a > setting, which divides/multiplies damage > done/received. This provides a > convenient way to make adjustments without having to > change all the archetypes > and the like > > If we're going to start adjusting HP of > creatures/players, I'd state a primary > goal to be that monsters and players have more > similar HP. One of the problems > right now is monsters have so many more hp than > players that targeting spells at > other players become almost instant death. > > > ___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Transports
On 2/1/06, Lalo Martins <[EMAIL PROTECTED]> wrote: > Me, I'm sticking with Brendan's "indoors square is 1 fathom, outdoors is > 1 chain" scale. It makes the best sense, even if it makes the > "continent" ridiculously small. > > BTW, I keep referring back to that message, and every time I have to > search for it again, so I posted it here: > http://wiki.metalforge.net/doku.php/map_scale Yes, I forget to get around to committing the changed signposts/directions for that, thanks for reminding me. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Transports
And so says Mark Wedel on 01/02/06 14:44... > 4) Scale is always an issue. Arguably, players are too big for most stuff in > the bigworld map (or all buildings must use magic to be bigger on the inside > than they appear). For that matter, right now, things like the longships > and > the like would appear out of scale - a longship could apparantly only hold 2 > people based on size, which obviously isn't correct. But I'd say it is > something that is hard to really get right given we still have varying scales > in > the game. Me, I'm sticking with Brendan's "indoors square is 1 fathom, outdoors is 1 chain" scale. It makes the best sense, even if it makes the "continent" ridiculously small. BTW, I keep referring back to that message, and every time I have to search for it again, so I posted it here: http://wiki.metalforge.net/doku.php/map_scale > Also, thinking about this, probably necessary to have some flag to denote > if > items can in fact be loaded into the transport. You can't necessarily pile > stuff onto a horse, but could on a wagon. Just a capacity, as already described in the proposal. You *can* pile some amount of stuff on a horse, after all. Which leads to another idea - some transports could be set up to behave as pets when unpiloted (behave as pets, not count as pets - killpets shouldn't kill them), so that you have 2 horses, you put your stuff on one, mount the other, and the "cargo" horse follows you. If on another adventure you have an ally, he can borrow your second horse and mount it normally. > 6) Damage - damaging transport requires a whole new set of code and > complication. Do transports now have resistances and the like? Do they > heal, > etc? I'd say this could perhaps be done later, but not sure how compelling > it > is to do it - may just really create more bother and complications. I think that would have to make a distinction between living and nonliving transports. Being able to fix nonliving transports would make skills (smithery) even more interesting. Living transports heal normally, and consequently can be healed. Nonliving transports, when damaged beyond their HP, break - you can use a skill to fix them, but you can't use them like that. Living transports die. Which suggests things like horse armor. But then, let's leave these ideas for the future. I agree initially they can just not take damage. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical:http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] cfclient colouring
On 2/1/06, Mark Wedel <[EMAIL PROTECTED]> wrote: > Brendan Lally wrote: > actually, I don't think there is anything specific about using 16 colors. I > think it was just that 16 colors were used - it could very well be 12 or 25 - > as > far as X is concerned, it doesn't care (unless someone only had 4 bit color, > but > I don't know if such hardware ever existed). ega cards on (very) old IBM PCs support only 16 displayable colours, I don't know if they can run X though. - in any case their resolution probably wouldn't be enough to show the entire screen. > Private colormap is a leftover from 8 bit display - most 8 bit hardware > could > only display 256 different colors at a time, but out of the palette of 16 > million (24 bit color). So one would use colormaps to determine what colors > of > the palette your are drawing. Is that why I have seen colours shift with application focus on very old sparc systems running X? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
