1 |
root |
1.6 |
apartments: |
2 |
|
|
|
3 |
|
|
ultracheap |
4 |
|
|
cheap |
5 |
|
|
moderate |
6 |
|
|
expensive |
7 |
|
|
luxury |
8 |
|
|
|
9 |
|
|
/scorn/apartment/apartments ultracheap 1 silver |
10 |
|
|
/santo/dominion/sdomino/appartment cheap 10 silver |
11 |
|
|
/darcap/darcap/apartment moderate 30 silver |
12 |
|
|
/navar_city/apartments/apartment expensive 250 |
13 |
|
|
/pup_land/nurnberg/apartment/main expensive 300 |
14 |
|
|
/pup_land/lone_town/apartment/groundfloor luxury 50000 silver |
15 |
|
|
/brest/apartments/brest/town/house luxury 30000 silver |
16 |
|
|
/azumauindo/ranbounagisatoshi/apartments/sapartment cheap 100 silver |
17 |
|
|
/azumauindo/suno-yamatoshi/apartments/lapartment1 expensive+ 1000 silver |
18 |
|
|
|
19 |
|
|
grundsteuer: level * tage * partments in silber max. 30 |
20 |
|
|
spielzeit: |
21 |
|
|
|
22 |
|
|
|
23 |
root |
1.5 |
2006-09-16 01:38:16 17 objects in mortal queue |
24 |
|
|
2006-09-16 01:38:16 Got unknown value in map header: race human |
25 |
|
|
2006-09-16 01:37:33 invalid type defined in shopitems in string cloak:5;spellbook:35;ring:15;book:28;scroll:25;wand:28;armour improver:2;weapon improver:2;rod:32;potion:10;horn:35;amulet:17;power_crystal:25;gem:0;lamp:-10;*:-90; |
26 |
|
|
2006-09-16 01:37:17 Map darkness for poison on /quests/peterm/FireTemple/Fire2 is too high (6) |
27 |
|
|
|
28 |
root |
1.4 |
requirements need to be dcoumented: json-sykc, safe:hole, gperf, glib, std::tr1 (::unoredred_map) |
29 |
root |
1.2 |
|
30 |
root |
1.1 |
Various bits, in no particular order. This is far from a complete list - |
31 |
|
|
however it keeps growing as various problems are discovered that |
32 |
|
|
don't have an easy fix. Some of the things are put here just so my mailbox |
33 |
|
|
doesn't overflow. |
34 |
|
|
|
35 |
|
|
------------------------------------------------------------------------------ |
36 |
|
|
Known Bugs: |
37 |
|
|
|
38 |
|
|
These are things which don't work as expected, but are difficult enough to |
39 |
|
|
fix that they get put here: |
40 |
|
|
|
41 |
|
|
Make lighting not go through walls. Maybe move it to the 'set_wall' |
42 |
|
|
function - hard to do so that it is still somewhat efficient yet the same |
43 |
|
|
light source does not illuminate the same space multiple times. |
44 |
|
|
|
45 |
|
|
If a shop is placed in a random map (special map), the objects below the |
46 |
|
|
shop wall stick around - normally not much a problem, unless it is placed |
47 |
|
|
in a glory hole (treasure level), in which case coins are now beneath the wall. |
48 |
|
|
|
49 |
|
|
Slaying is sloppy in that it uses strstr. This, an item that has 'slaying |
50 |
|
|
giant' (like holyword of mostrai) will kill ants. strstr matching was most |
51 |
|
|
likely added to support comma seperated slaying lists (slaying demon,undead). |
52 |
|
|
However, the code should really insist on exact matching, and if necessary |
53 |
|
|
break apart the comma seperated list. Probably best to make something like a |
54 |
|
|
'does_slay()' function which can be used all over the place (consistent |
55 |
|
|
behaviour is a good thing). If performance for this becomes an issue, making |
56 |
|
|
a slaying a set of pointers could be done (char **slaying), and it gets filled |
57 |
|
|
in at load time, and at save time, gets filled in the opposite direction. |
58 |
|
|
However, from a simple basis, a check in does_slay() can be done to see if |
59 |
|
|
slaying does contain a comma, and if not, just do simple strcmp, and only if |
60 |
|
|
it does does extra work need to be done. MSW 2003-03-28 |
61 |
|
|
|
62 |
|
|
|
63 |
|
|
------------------------------------------------------------------------------ |
64 |
|
|
Future feature requests |
65 |
|
|
|
66 |
|
|
- Change code so that if a player kills another player, he gets no |
67 |
|
|
exp. Perhaps also log number of times a player has killed another player |
68 |
|
|
so problematic player killers can be more easily tracked. This should |
69 |
|
|
be pretty simple, but is mostly here because I want to re-write the |
70 |
|
|
kill_player for the new skill code, and that should clean things up |
71 |
|
|
up a bit to make this code easier to put in. |
72 |
|
|
|
73 |
|
|
- Allow possibility of one players magic not harming another player (should |
74 |
|
|
probably be a flag/settings value) - given that most spells are large |
75 |
|
|
area of effect spells, this may make cooperative adventuring easier. |
76 |
|
|
However, this could be a little odd - if my friend it immune to my fireball, |
77 |
|
|
shouldn't I be immune to my fireball also? But if that is allowed, you |
78 |
|
|
now have the case people could cast fireballs on themselves and hit a |
79 |
|
|
whole bunch of surrounding monsters. Perhaps allow this no damage |
80 |
|
|
attribute based on different spells, eg, it could be argued that for bolt |
81 |
|
|
spells you'd aim it so that it doesn't hit your friend, but that same |
82 |
|
|
claim can't be made for fireballs. Or maybe add something like the |
83 |
|
|
ability of spells to not take effect to some range, eg, 'cast lightning |
84 |
|
|
bolt range 6' or the like, in which case it goes 6 spaces before the |
85 |
|
|
lightning actually starts. |
86 |
|
|
|
87 |
|
|
- Refine blocking of spaces - instead of 'blocks all or nothing', ability |
88 |
|
|
to block walking but not flying, block swimming (for future expansion |
89 |
|
|
of oceans). Also, add different LOS blocking for differing conditions - |
90 |
|
|
if flying, jungles shouldn't block line of sight, but they still should |
91 |
|
|
if your walking. Also, add seperate blocking (pass) for monsters and |
92 |
|
|
players, eg, block_monster and block_player. What should probably be done |
93 |
|
|
is make this a bitmask or the like with multiple possiblities. If the |
94 |
|
|
object doesn't have another bitmask set, object can't pass through. For |
95 |
|
|
compatiblity reasons, no_pass should set all the new no_pass_.. bits. |
96 |
|
|
Note that these bits should also be extended for movement of more than |
97 |
|
|
just the player, eg, spells, diseases, etc. Thus, you could have something |
98 |
|
|
like a 'no spell propogation' space - players could still cast spells on |
99 |
|
|
themselves, but range spells don't go anywhare. |
100 |
|
|
|
101 |
|
|
- Ability for stores to set different prices for goods (eg, remote store |
102 |
|
|
charges more for the services it provides). |
103 |
|
|
|
104 |
|
|
- dm command 'Follow' which lets him see what a player is doing, where he |
105 |
|
|
is going, etc. |
106 |
|
|
|
107 |
|
|
- Further control on what players can do on maps/spaces. For example, |
108 |
|
|
prohibit players from shouting, attacking others, issuing tell, |
109 |
|
|
etc. |
110 |
|
|
|
111 |
|
|
- Change inscription - instead of looking at range field of the player, |
112 |
|
|
have the spell to be inscribed part of the inscription command, eg |
113 |
|
|
'inscribe scroll of identify'. |
114 |
|
|
|
115 |
|
|
- If player tries to login with same name/password as a character currently |
116 |
|
|
active, drop the old connection and associate the player with the new |
117 |
|
|
connection. Useful if connection is dropped but server hasn't detected |
118 |
|
|
it yet. |
119 |
|
|
|
120 |
|
|
- Generalize the code better - split between 'rules' and 'engine'. The engine |
121 |
|
|
would be the aspect of loading/saving objects, dealing with maps, and |
122 |
|
|
basic object support (exits, levers, etc - things useful for any working |
123 |
|
|
system). The 'rules' would be the more general genre of the game - |
124 |
|
|
a science fiction game would have a different set of rules than the |
125 |
|
|
fantasy game. And even the same genre may have a different ruleset |
126 |
|
|
(ie, adding new skills). This is sort of like the current server/common |
127 |
|
|
split, but goes a bit more than that - the engine would be able to compile |
128 |
|
|
into an executable with the addition of some basic stub functions, |
129 |
|
|
but playing as such would really just amount to a ghost moving accross |
130 |
|
|
a world which time is pretty much stopped (as monsters would be in the |
131 |
|
|
rules side, and not engine). |
132 |
|
|
- Changing the stat generation system - instead of roll based, give some |
133 |
|
|
number of points. This makes it easier for players to choose what they |
134 |
|
|
want to play - otherwise, I think some clients will be written that will |
135 |
|
|
do this for the players in any case. |
136 |
|
|
- Change draw_info so that server tells client what type of message it is |
137 |
|
|
instead of the color. Client can then decide what color to draw it |
138 |
|
|
or other special handling. |
139 |
|
|
- Change code so that objects 'spill over' to other spaces if too many |
140 |
|
|
get piled in one space. |
141 |
|
|
- More/better maps. Add more quest maps or maps to take advantage of |
142 |
|
|
newer features (ie, church maps for each god, maps for alchemy quests |
143 |
|
|
or with rare ingredients, etc) |
144 |
|
|
- Add some identifier for unique objects so that if the player that has |
145 |
|
|
a unique objects quits the game, the object goes back into circulation. |
146 |
|
|
- Add flag to make price of objects not affected by charisma or other |
147 |
|
|
abilities. This should act like gems do right now (pay 1.03, receive |
148 |
|
|
0.97). In this way, gems don't have to be hardcoded, and other items |
149 |
|
|
could be similarly set. Nuggets should be added to this list - its possible |
150 |
|
|
to make small amounts of money alchemy silver and then selling the nuggets. |
151 |
|
|
- Add/change door handling - make them more real life - they stick around, |
152 |
|
|
can be opened, closed, different keys for different doors, etc. This |
153 |
|
|
sort of mimics the gate behaviour, except keys may need to open them, etc. |
154 |
|
|
|
155 |
|
|
- Add armor quality, with armor being damaged as it is used. Add repair |
156 |
|
|
shops to go with this. Uncertain if people really like this idea or not |
157 |
|
|
Further notes from mailing list: |
158 |
|
|
Item has current quality rating - different items have different max |
159 |
|
|
ratings - magic would increase its rating. ITem operates normally |
160 |
|
|
when it has 50%+ of its quality. At less than 50%, item loses |
161 |
|
|
functionality in a limited fashion (eg, multiply quality percentage |
162 |
|
|
by two to determine effective abilities in terms of percentage.) |
163 |
|
|
Item max qualities should be in the same range for most all items, so |
164 |
|
|
that powerful items given to low level characters get dinged up just |
165 |
|
|
as fast as their normal items. |
166 |
|
|
Diminished effects would be handled in fix player. |
167 |
|
|
Cost to repair based on how damage item is (100 = half cost, |
168 |
|
|
0 = full cost). Items can be repaired on pro-rated basis. Repair |
169 |
|
|
anvils would need to get added. |
170 |
|
|
Items are damaged based on how much damage player takes - more |
171 |
|
|
damaging attacks have higher chance to do item damage. Amount of |
172 |
|
|
damage done to items might depend somewhat on damage done to player. |
173 |
|
|
Acid attacks would be changed to use this same code - they just |
174 |
|
|
always damage items at a much higher rate. Different ideas is that |
175 |
|
|
chance of item damage is fixed, but amount done is based on damage |
176 |
|
|
sustained. Other idea is that chance of damage is based on |
177 |
|
|
real damage (percent, square root, other adjustments, perhaps |
178 |
|
|
ignoring low values), but damage is somewhat constant. |
179 |
|
|
Should probably be tunables in settings to determine amount of damage |
180 |
|
|
done to item, and how often item is damaged. |
181 |
|
|
|
182 |
|
|
- Change players draining exp from others. Currently, there are problems |
183 |
|
|
in that it not adjusted based on levels, so there are various abuses |
184 |
|
|
draining from low level characters. Also, generally it is not possibled |
185 |
|
|
to drain exp from monsters. Possible ideas: |
186 |
|
|
- Change draining from other players to be a ratio of levels (ie, a level |
187 |
|
|
10 character draining from level 5 only gets half the exp. |
188 |
|
|
- Ability to drain exp from monsters (might make drain weapons more |
189 |
|
|
useful). Maybe have monster lose some portion of the exp he would |
190 |
|
|
award when drained, and try to adjust level/other stats downward as |
191 |
|
|
it looses exp? |
192 |
|
|
- Fix map loading/saving so it can do it over several ticks for smoother |
193 |
|
|
performance (maybe thread it?) |
194 |
|
|
- Add adjustments to objects that adjusts chance of skill success. |
195 |
|
|
Eg, objects the player use may adjust the characters effective level in |
196 |
|
|
using a skill. Likewise, objects/monsters could have resistances to |
197 |
|
|
certain skills (eg, skill_resist values). |
198 |
|
|
|
199 |
|
|
- Delete oldest swapped map in case the TMPDIR disk fills up while |
200 |
|
|
swapping out a map. To do this, detection of error on save would need |
201 |
|
|
to be done (presently, the fputs are done without return value checks.) |
202 |
|
|
|
203 |
|
|
- Seperate weapon speed and real speed for players - one is used for attacking |
204 |
|
|
only, and the other for movement only. Right now, a characters real speed |
205 |
|
|
could become the weapon speed when they attack something. |
206 |
|
|
Make speed more variable for some actions (limit how much can be picked up |
207 |
|
|
at once, certain skills should take longer than others.) |
208 |
|
|
- Make monster pick up more intelligent - only pick up items if they may be of |
209 |
|
|
some use (perhaps base this on int - stupid monsters might pick up everything) |
210 |
|
|
- Add different dragon scales, in which different types of armor could be made |
211 |
|
|
from. |
212 |
|
|
- Add random terrain type square. Idea being you might make something a |
213 |
|
|
random tree, and when the map is loaded, it chooses a tree random. This |
214 |
|
|
would allow some variation in maps each time with possibly keeping the bulk |
215 |
|
|
of it the same (Depending how extensively the random trees are used. |
216 |
|
|
- Allow transportation objects (ie, horses, carts, dragon, griffins, boats, |
217 |
|
|
etc.) Flying objects should probably ignore line of sight for most |
218 |
|
|
objects (you are above the forest or mountains, but then fog should still |
219 |
|
|
affect things). To do this, a terrain type value probably needs to be added, |
220 |
|
|
and this acts a bitmask. Thus, transports compare bitmasks to see if |
221 |
|
|
travel through that is allowed. |
222 |
|
|
|
223 |
|
|
- Change identification handling. Possible idea is to have different levels |
224 |
|
|
of identification, with low level only showing basic information, and high |
225 |
|
|
level showing full detail. Skill identification should basically use this, |
226 |
|
|
with the skill level determining actual level. Depending on level of |
227 |
|
|
identification, different information may be revealed (value, face, |
228 |
|
|
name, etc). |
229 |
|
|
- Allow monsters to be randomly generated on a map without generators (ie, |
230 |
|
|
orcs show up in forests or whatever.) Uses this as an option to use instead |
231 |
|
|
of the existing random encounter code. |
232 |
|
|
- Have monsters potentially attack others if they are damaged by a friend. |
233 |
|
|
It looks like the code should already allow this, but I think the problem is |
234 |
|
|
that monster reevaluate their objectives too often, and which time they |
235 |
|
|
switch back to attacking the player. |
236 |
|
|
- Allow treasure lists to be specified as part of the objects message |
237 |
|
|
- Perhaps print out a message shortly before a spell effect is about to end. |
238 |
|
|
- Rewrite all variables, using own typedefs of type: |
239 |
|
|
[us]int8, [us]int16, [us]int32 : Variables that should be at least that |
240 |
|
|
size (is there actually anything that needs to be precisely some size?) |
241 |
|
|
These typedefs can be set depending on system type. |
242 |
|
|
- If communication remains the same (keyword matches), |
243 |
|
|
highlite the keywords or in some way make them more noticable so players |
244 |
|
|
can know to use them. This is no worse than many commercial games which |
245 |
|
|
give you just a few choices to choose from to continue a conversation. |
246 |
|
|
- Statues turning into golems when activated (like doors). |
247 |
|
|
- Figurine (when a figurine pet dies, it becomes a figurine, and can be reused) |
248 |
|
|
|
249 |
|
|
- Ability to aim at targets not in the front row. This should apply for |
250 |
|
|
most range attacks (thus, in a group of orcs, the ones not immediately |
251 |
|
|
around the player could still use missile weapons.) |
252 |
|
|
|
253 |
|
|
- Better sound support - instead of having hardcoded events for sounds (eg, |
254 |
|
|
button push, door open, etc), sounds should be tied to objects, with some |
255 |
|
|
number of sound events (eg, object active, object destroyed, object moved, |
256 |
|
|
objected attacked, repeat forever, random, etc). Information about how far |
257 |
|
|
they can be heard (in spaces) should also be contained. When a sound is |
258 |
|
|
played, then do a simple check to see nearby players, and if one is within |
259 |
|
|
potential range, then check for intervening objects (walls). Walls would |
260 |
|
|
have some dampening effect, counting for more spaces (something behind a |
261 |
|
|
wall may sound 5 spaces further away.) |
262 |
|
|
Exactly how to store the sound information would need to be investigated - |
263 |
|
|
the cheapest in terms of memory would be something like how animations are |
264 |
|
|
done - have a global array of the sound information. However, sound |
265 |
|
|
information would be tied pretty closely to object types (eg, if the sound |
266 |
|
|
info said its used for both apply and destroy, then if some other object |
267 |
|
|
used that same info, it'd also get that apply and destroy behaviour). This |
268 |
|
|
is probably good enough - one could make individual sound information |
269 |
|
|
sequences for the individual parts if those were needed. |
270 |
|
|
|
271 |
|
|
- Make the elevation of terrain adjust line of sight. If on the tallest |
272 |
|
|
mountain, you would be able to see over neighboring mountains and not |
273 |
|
|
get your view blocked. |
274 |
|
|
|
275 |
|
|
- Change attacktype handling. Currently, attacktypes are just bitmasks, |
276 |
|
|
so if a weapon does 'dam 30' it does 30 dam for all attacktypes it has |
277 |
|
|
set. |
278 |
|
|
The idea is to make an array of dam values for the attacktype, so |
279 |
|
|
you could have a weapon like 'phys 12, fire 6'. This then gets adjusted by |
280 |
|
|
appropriate resistances the creature has. |
281 |
|
|
For attacktypes that are effects (slow, paralyze, etc) dam should be the |
282 |
|
|
potency of the effect (number of ticks player is effected). |
283 |
|
|
If an item has multiple dam values set, then it would do damage from all |
284 |
|
|
the attacktypes (eg, a phys 10 fire 3 is something like a flameblade |
285 |
|
|
which does mostly physical and a little fire). |
286 |
|
|
|
287 |
|
|
- Improve material code: |
288 |
|
|
1) Make material file more readable. Mostly, make it one entry per |
289 |
|
|
line (no comma seperated lists), with values 0 by default, so only |
290 |
|
|
values that are different need to be entered. Maybe make materials |
291 |
|
|
archtypes, and then use treasurelist type setup below? |
292 |
|
|
2) Remove random material selection from the material file and put it |
293 |
|
|
elsewhere - basically, more fined grained material control (silver daggers, |
294 |
|
|
but not silver axes for example). Perhaps the idea of material |
295 |
|
|
type treasurelists? |
296 |
|
|
3) Remove material bitmask. Instead, have a pointer to the actual materialtype |
297 |
|
|
struct, and determine basis on that (eg, this could burn up, etc). If |
298 |
|
|
necessary, add some appropiates field to the material struct that |
299 |
|
|
denote those abilities. |
300 |
|
|
4) Suffix to be used for alternative image names and animation sequence |
301 |
|
|
for objects (eg, dagger.111.gold for example) |
302 |
|
|
5) Some way to denote that even though 'materialname' is set, that the loader |
303 |
|
|
should still do appropriate adjustements for the material. Thus, if a |
304 |
|
|
person sets the material in the editor, the server will adjust the values |
305 |
|
|
appropriately. |
306 |
|
|
6) Allow for multiple materials in same object. Trickier to do this. |
307 |
|
|
7) More hints for materials. Eg, is it a notable material that should be |
308 |
|
|
included in the object name, or mundane? Likewise, is it a type of material |
309 |
|
|
that can be reconstituted (metals) or not (wood, stone, etc) |
310 |
|
|
|
311 |
|
|
Improve exit/teleporter code. With tiled maps, it is now desirable to move |
312 |
|
|
monsters between those maps, so exits should be able to move monsters. Add |
313 |
|
|
bitmask/flag to exit to denote what it moves - players, monsters, or |
314 |
|
|
objects. |
315 |
|
|
|
316 |
|
|
Add exp rewarder type object. It's basic properties: |
317 |
|
|
1) amount of exp to reward the player (stats.exp) |
318 |
|
|
2) Skill to award the exp to (skill field) |
319 |
|
|
3) Flag to denote we should teach the player this skill if they don't |
320 |
|
|
have it (can_use_skill flag?) In this way, rewarders could grant |
321 |
|
|
skills to the player. |
322 |
|
|
4) Different ways to be activated (walk on/fly on, as well as it being |
323 |
|
|
activated from something that 'pushes' it (aka, magic mouth, button, |
324 |
|
|
etc)). In the case of another object activating it, the player |
325 |
|
|
would still need to be on the space the object is on. |
326 |
|
|
5) Use the 'slaying' field to denote that if the player has a force in |
327 |
|
|
his inventory by the same name, he doesn't get the reward, and if |
328 |
|
|
they don't have such a force, we add one to the player (so you can't |
329 |
|
|
get the same reward repeatedly). Use something like 'value' or |
330 |
|
|
other field to denote how many ticks the force lasts for. If value |
331 |
|
|
is zero, then force never expires |
332 |
|
|
6) Use nrof to denote how many times the reward works. Eg, if nrof |
333 |
|
|
is 1, then once a player uses it, no one else can get that reward |
334 |
|
|
until the map resets. |
335 |
|
|
|
336 |
|
|
Secondary features: |
337 |
|
|
|
338 |
|
|
These are more features (low priority at that) to be added. Some of these |
339 |
|
|
may be related to items above, or they may be things that just would not |
340 |
|
|
add a lot to the game (IMO). |
341 |
|
|
|
342 |
|
|
- Flag so that there is a random chance that an object will or will not appear |
343 |
|
|
on a map (this is perhaps better handled by treasurelists. Unfortunately, |
344 |
|
|
treasurelists can not be set in the maps). |
345 |
|
|
- Ability to have pixmaps set in maps or otherwise be able to load images |
346 |
|
|
without having to rebuild the default images. |
347 |
|
|
|