posted
Dan, I think for the next patch, you should add a Trade option between players. Then we could make gold and items worth something. I also think you should make trophies tradable =P I'll give an example of why a trade window would be useful.
Item Requires - 1 Trophy A (not findable), 1 Trohpy B (not findable), 30 Trophy C (not findable)
Trophy A requires - 20 Trophy D (Trophy D drop rate is 5) 30 Trohpy E (Trophy E Drop rate 15)
Trophy B Require - 7 Trophy F (Drop rate 20) + 10 Trophy G (drop rate 20)
Trophy C requires - 3 Trophy H (Drop rate 50)
So...in all that's 1x20 + 1x30 + 30x3 + 1x7 + 1x10 essentially 20 + 30 + 90 + 7 + 10 giving you a total of 157 trophies to obtain to make said Item. MEaning hours of work for one item.
And if you have several items like this in your World, supply + demand will = high prices. Gold wont due, can too easily be obtained with people pooling. So an Item for Item trade would be better Even better a trophy for item trade would be better....and to make it honest, a trade window with acceptance from both parties would be required. So like 60 of Trophy A taded for 1 Very very unique rare Item would be lets say a fair trade (in accordance to the law of supply and demand).
I know that was all probally confusing, but I have trust in you Dan that you'll understand the blabbering that took place just above.
Posts: 45 | Registered: Jan 2005
| IP: Logged
SET cookiename, "arrayentry#<index>" SET_SUBSTR value, 0, 3, *#<cookiename>
That'd let me use (and destroy, like a normal POP command) a value from the stack instead of a cookie from the hard drive.
This is the sort of extension of the stack's capabilities which could make it significantly more useful. I mean, it's already great at switching values between two cookies, but array lookups are really good at slowing scenes down, and I think that this could *start* to alleviate that problem. A little.
As always, thanks in advance.
-------------------- Constantinople! We shall never forget your zany barge poles! Posts: 4232 | From: Gresham, OR | Registered: Nov 2003
| IP: Logged
posted
I'd kind of like a shielding spell. For a certain amount of time or damage, whichever came first, the shielding spell would absorb part or all of the damage intended for the shielded player.
-------------------- Constantinople! We shall never forget your zany barge poles! Posts: 4232 | From: Gresham, OR | Registered: Nov 2003
| IP: Logged
posted
How about the ability to lock/unlock equipment in slots. By that I mean having certain equipment once equiped unable to take off unless a certain condition is met. Heres a quick example. You equip a "Cursed Sword". Your character is now unable to un-equip it until a condition it met. The condition could be met by meens of token, trophy, item, possibly cookie setting.
O ya also could add a setting for scene in which no players can un-equip anything. Un-able to switch equipment is also included into all of this too.
posted
Dan we talked about this in emails, and you asked me to put it up here so you could remember.
The quest chapter book.
Make all tokens reside under a chapter using the BEGIN_CHAPTER and END_CHAPTER commands, So all the TOKEN definitions between the BEGIN and END, no matter what their IDs are, are assumed to be members of that chapter (and ideally will list in the order shown)
BEGIN_CHAPTER (normal chapter description) information, only no token range is declared (individual token definitions, in any order, but all assumed to be inside the 'current' ("begun") chapter END_CHAPTER
Chapter 2, with token 11 will still be slotted under the main chapter it resides in so it appears like this to the player in his/her quest book:
BEGIN_CHAPTER 2, "The End of Life" TOKEN 12, "You grew very old" TOKEN 3091, "You are frail" TOKEN 11, "You die."
This chapter thingy is well needed as not all worlds follow an order of numbers for there there tokens quests. as mine is all over the place, and by having these commands i will be able to set my quest chpater book up like everyone else can.
Posts: 1040 | From: Australia | Registered: Dec 2001
| IP: Logged
posted
this would be an option, you wouldn't have to do anything.
the BEGIN_CHAPTER command would replace the CHAPTER command for people who chose to use it.
Tokens encountered in the quest file would be credited to the most revent BEGIN_CHAPTER command (so they could be defined in a neat little block after the BEGI_CHAPTER command, or they could be wandering throughout the file in the spaghetti you may already have :-)
And the idea is they would be displayed in the order in which they occurred in the quest file. (as opposed to the order of the token #)
Not sure if an END_CHAPTER command is actually needed.
-------------------- He knows when you are sleeping. Posts: 10752 | From: California | Registered: Dec 1998
| IP: Logged
posted
Would appreciate a merging of the host (+ host's party) with the "allies" in-scene. That way, when I started a fight against a monster, but gave the hero a healing monster as an ally, the monster would actually heal him.
To prevent the breaking of summon/all in that case, it would be nice if the counting/summoning loops could be made separate. As it is now, if you cast a summon/all on a summoned monster, it sets up a feedback loop and brings out well over a hundred of them.
Thanks!
-------------------- Constantinople! We shall never forget your zany barge poles! Posts: 4232 | From: Gresham, OR | Registered: Nov 2003
| IP: Logged
posted
A coockie to check the number of incarnations of a char would be usefull. The point would be to check SSVs whenever a char incarnates (the first time he camps/enter a scene), to reconfigurate the world accordingly (it could be used for special events for example). Since SSVs are pretty laggy, it's impossible to check that in every camp, so such a cookie would make it possible, with no uber-lag whenever you enter a scene.
posted
Campaigns: the remedy for huge worlds download.
This is an idea I have in mind since a few years, but I never posted it. I think it's about time now.
Since the beginning, I've been torn between 2 constraints: I wanted to have a world as large and well-looking as possible (which means, a lot of maps, pseudo-high rez pictures, a bunch of skins, an oversized SFX folder, etc), and still keep the size of the zip as low as possible. Despite this fact, the world became huge. Athelias is about 45Mb now. SP, RoT, and other popular worlds are as big.
Yet, when I look at my world, I notice it's made of different regions (Athelias island, the desert, the Old World, etc.), completely indepedant. Every region has its own quests, monsters, etc. Basically, you could level a char in one region and never go to another one, it wouldnt matter. Hence the idea of making campaigns.
But... Using this kind of art would make it huge. Larger than any world published. Too large, probably. And I know I cannot ask players to download a 200Mb ZIP. It works with Sylvendir alone, as it's a comparatively small world. It wouldn't work for Athelias plus Sylvendir (Athelias 2) - it wouldn't even work for the revamped version of Athelias using Sylvendir-like art (high quality zone maps, etc).
But wait. Do the player need Sylvendir to play Athelias? They don't. Do they need the files of the desert (a region of Athelias) to play the world. No. Do they need the files of the Old World? Nope. So why couldn't I make those files an optional download?
Let's say: you have the ZIP of the world, containing what you need to play: a core region, with core quests, the levels, spells, items, monsters, etc. tables. Then you have subfolders, containing new quests files, making a new campaign. These subfolders would have their own maps, sfx, possibly skins folders. They'd have their own version too. And they could be downloaded as plug-ins for the world. You wouldn't need them to play the world - they'd be required only to enter the new regions. You could release patches for those new regions, without changing the core quest files. That would solve the downloading issue.
At the moment, I stumble on this world size issue. If I want to improve the art of my world and keep a decent size, I have to cut 3/4 off my world. But I just cannot throw away my work. And anyway, players like it because of the number of places to explore, the hundreds of quests, etc. Campaigns would solve this problem. I'd split it in 4 or 5 parts, and that's it. And the new regions I will add would become new campaigns, so they wouldn't increase the size of the world.
I hope it's doable. This is the only thing I need to make something really new in WoS, and I'm sure many world devs would take advantage of this option.
Oh and by the way... happy new year!
EDIT - Sorry for talking so much of my world(s), but I was taking them as a concrete example to illustrate this idea.
posted
How about adding an option to config.ini allowing the world developer to change what hand training you need in order to equip a weapon of that type. Also how about adding an additional argument or inserting into one that is already made to allow weapons to be used at a certain hand training level. Kinda like how spells are with their element training levels.
Posts: 550 | From: USA-WI | Registered: Aug 2001
| IP: Logged
I'm not the first dev vto notice this issue, but I think it has never been reported before. Here is the problem: the server doesn't check the version of the world the players have (nor if it's a legit or modded version) when setting new SSV values, which means a modder with scripting skills can change the value of any SSV.
Modders are allowed to play online because they're not supposed to be able to interact with legit characters. But this security issue ruins this idea. Of course, server admins could use the noMod option to prevent it from happening, but wouldn't it be better to check if the player has a legit version of world whenever he tries to set or get SSV, and disable the commands in case of modified quest files?
Alternatively, a new server rule setting an official world version could do the job, but it may be problematic when a new patch is released (as it generally takes a few days before everybody has the newest version).
Also, the fact server admins are able to modify the SSV, as they're stored locally, may be another problem. Wouldn't it be possible to encrypt them as you do with cookies, and give us a way to check if the values were changed by the server admin?
[I claim SSVs are fundamentally insecure, as is anything stored outside of the core hero file (anything 'extensible'). However, in theory the code already prevents someone with a modified copy of the world from setting SSVs, so that would be news to me if they could. -s]
The latest version of AHS, which includes a quest emulator, makes me able to reconfigurate every scene online, add new quests, change dialogs, actors - almost anything actually - via the SSVs. To reduce the lag, I made server patches: servers have an official version, checked every now and then (the idea would be to check it whenever the char incarnates only - hence my last request), and if a player has outdated datas he starts downloading the new configuration. Of course, as we're talking about SSV, the cookies set are the same for every character - yet a player would have to fetch them all for every character he plays. With account-wide cookies we could get rid of this unnecessary downloading.
I know account-wide cookies would let us do things that ain't encouraged, such as banning a whole account. But actually it wouldn't change anything. We're already able to ban a whole account if we want to (just make a small script included or called in every scene, and send the SOUL ID of the player you want to nuke to the server). I don't encourage hard scripted account banning, but it's already something we can do so having account-wide cookies wouldn't make it worst. Or you could also restrict them to cookies set with the GET_SERVER_VAR command, to make this kind of unwanted script harder to write for the new WDs...
posted
This is not a bug as I'm doing something I probably shouldn't do but... my items and trophies tables are bugged.
Next patch I'm going to implant a trading script in Athelias. Players will be able to set up their own shops in a specific area, and sell the items and trophies they have, thanks to SSVs. And as I want it to look good, I decided to make a custom interface, showing the items/trophies sold by every player. To do so, I copied all the items/armors/swords/.../.../trophies art files into the skins folder and pick them accordingly. My first idea was to make a clone of my items and trophies files (items.txt and trophies.txt - the thing #included in quest.txt) and paste and copy them into a DevTable so I can have the item class (and make it point to the according skin) and the image row (to have the pose ID).
But... I'm lazy. Very lazy. And mainly, I'd like not to have to update two files whenever I want to add one more item or trophy (I'd have to update both items.txt and the DevTable). So I had the idea of #including a DevTable between +ITEMS and -ITEMS (the same goes for trophies). WoS didn't seem to be too pissed by my trick. The items and trophies are just fine... except I can no longer use the /props editor. WoS does read the DevTables as if they were any other .txt file #included, but the props editor doesn't. If I open it and select "items" or "trophies" it shows the datas of the last /props thingy checked instead (spells or monsters).
Of course I could try not to be that lazy and make a clone of the files as it was originally planed, but it would be sooo easier if the /props thingy wasn't that stubborn...
[the /props thingy really wants to edit on a one file per category basis, sorry. I don't think you would be happy when /props deleted all your items when you updated a single trophy -s]
posted
Samsyn: I didn't try to merge the items and trophies into one table. I made one devTable for items, and another one for trophies - everything is fine except for the props editor.
EDIT - OK, apparently it's not related to the fact I use DevTables. The same thing happens if I put my items in a file called a.txt. I guess /props doesn't look for what's #included in quest.txt but for a file called items.txt in the root folder.
[correct, that's what I meant, it is hard-wired to look for items.txt monsters.txt etc.. so something which started out as a convenience (breaking monolithic quest.txt into convenient slices) became a 'standard' (you MUST use items.txt). Except that you don't *have* to use /props so in theory the freedom is still there Just not the convenience. -s]
[I see... however an "easy" way to fix that would be to add an option to the /props editor to let us load a different file for the items/monsters/etc. The editor would keep looking for monsters.txt for example by default but we could manually make it load another file instead.
Or... I could also try to stop being lazy and make a DevTable clone of items.txt etc and update both files whenever I add or modify an item
posted
Add some way to un-equip a piece of equipment or weapon from a player. Example: no weapons are allowed to be equipped while a player is in the holy temple. so it forces the player to un-equip his weapon, thus if a player equips a weapon it would execute some script. I just need a way to un equip a weapon from players hand.
Posts: 1040 | From: Australia | Registered: Dec 2001
| IP: Logged
posted
Makarei's suggestion would also help not to freeze when morphing into another class (the problem isn't completely identified but I noticed WoS doesn't like when you have something equiped the new class can't use).
And as we're talking about this, an optional map flag (well, there is no such a thing as a mandatory map flag anyway) to prevent from switching your equipement. It could be used on special PK maps, or in a few quests (for instance, players have to equip a specific staff in a quest of Ath before they fight a monster to lower its level: lvl 200 with the thingy equipped, level 300 otherwise - that's pointless if they can switch after the battle has begun). It would also helps with scripts like: a specific allied monsters joins you in battle if you have some item equiped. Of course, WDs with more imagination will find other fancy things to do.
Flmalord: thanks for the offer - I think I'll manage to do that on my own. That's a good idea.
posted
Interesting idea, the extra equip control stuff. How about only being able to equip an item if you can equip all of the items in a set, and then forcing all of them to be equipped or not?
@Mad: Interesting spelling of the screen name, but you're welcome for the idea, and I figured you could manage on your own.
-------------------- Constantinople! We shall never forget your zany barge poles! Posts: 4232 | From: Gresham, OR | Registered: Nov 2003
| IP: Logged
posted
I have two places where i need to control what the player has equipped, the first is simply a restricted area dis-allowing the use of weapons being equipped thus when player encounters first entrance scene the script should force the weapon out of players hand and put in there backpack. thus allowing them to enter the area. a Map flag preventing weapons from being equipped would reduce player checks.
The second place i need to control equipped items is more like a CUT scene, except its a playable scene where the player lives the role of an ancestor thus taking on his attributes, health, mana, and items. i.e (class morph) The player then works there way through this little storyline and eventually battles it out with a main character of the storyline, after the battle "I need a way to un-equip specific item id's so they can be removed from the player" After that the player is returned to there original state.
I know you might see this silly Dan, as you did say once along time ago, removing items from a players equip slot is wrong. but i need these special items removed as they are after all one set of best equipments in the game. and the player cant open any of the locations to these items until they have completed this little storyline. so i dont see how this could be unfair, unless you mean unfair for cheaters but that would be silly.
Posts: 1040 | From: Australia | Registered: Dec 2001
| IP: Logged
posted
Actually you can. Just class morph the player into a class that doesn't use that item, and afterwards state the TAKE I? command. this will unequip the item and remove it from the player. however armor will remain.
I just need away to force the player to unequip item id from there armor slots. - its not that much to ask is it?
- And I wouldn't have posted the TAKE items from player slots in this world dev notes if this wasn't a suggestions thread. - but since it rather is, this is a suggestion i would like to see implemented in wos.
posted
A quick test shows that TAKE ixxx works with equipped items as well. At least, it works when taking them with Terminal commands, in the camp scene. So, not quite sure what the problem is.
Edit: A TAKE/GIVE pair works wonders for unequipping things they only have one of.
posted
Yeah it will take the items but will leave the images of the item still equipped. thus thinking the player still has the equipped items equipped, even though there not in the players inventory.
Posts: 1040 | From: Australia | Registered: Dec 2001
| IP: Logged
posted
That issue seems to me more like a bug than a request for "new" development. In the interim, why not create a 0 stat set of armour that uses the stock "naked" images and GIVE that to the player in place of whatever you TAKE?
-------------------- Come ride with me through the veins of history, I'll show you how god falls asleep on the job. Posts: 5438 | Registered: Dec 2003
| IP: Logged
posted
Uh, in my tests, that did not occur. When TAKEn, the item was both removed from currently equipped, and the inventory. The image reset to display no weapon.
-------------------- Constantinople! We shall never forget your zany barge poles! Posts: 4232 | From: Gresham, OR | Registered: Nov 2003
| IP: Logged
posted
Problem solved then! I'd tell you to jump on MSN Chris but alas I changed my password recently and the new pass is so secure that even I can't remember it.
-------------------- Come ride with me through the veins of history, I'll show you how god falls asleep on the job. Posts: 5438 | Registered: Dec 2003
| IP: Logged
posted
Yes As i have said it works for "weapons" but not other equipment like "rings, boots, armor, helm etc" I can get the weapon to disappear but not the other stuff.
wos feels so limited at times.. i might have to prolong this world until wos has options to do what i want like turn a level 1 into a level 90 character. I think dan wants me to make another evergreen replica with limitations. Posts: 1040 | From: Australia | Registered: Dec 2001
| IP: Logged
posted
i have tired many times but still get the image appearing on the player. unless your using the default image strip, where as i am using another image strip. i doubt that be the cause but i will try it and see.
Try a ring that is 0 level to be worn.. and has a probability of -1 to be found, and 0 gold value. and let me know if it still works.
posted
Only one at a time will remain shown; as the next one is taken, the previous image changes. This means that whichever item you take last is the only one shown still equipped, at least in my latest tests. Hovering over the show all button seems to cause the last one to go away.
-------------------- Constantinople! We shall never forget your zany barge poles! Posts: 4232 | From: Gresham, OR | Registered: Nov 2003
| IP: Logged
posted
Nope can't get it to work, so i will have to modify the world to fit with the limitations of wos, again.. Posts: 1040 | From: Australia | Registered: Dec 2001
| IP: Logged
posted
New suggestion: lastClick, lastAttack, lastSpell, lastToss.
These four cookies would, very simply, return the actor ID (not bite number) of the last actor right-clicked, attacked, cast upon, and tossed to, respectively. Useful for acting upon array elements based upon which actor is clicked.
New suggestion: No bite numbers in CUT scenes/bite number settings.
Alternatively:
SCENE <ID #>, <bkgnd>, <scenestyle>, <name>, <fx>, <weather>, <colorTable>, <bitenumbers>
A simple boolean argument to enable or disable the bite numbers in that scene.
... because I hate seeing "Actor Command #1" when it's most definitely not. I'm sure others will find many uses for the option as well.
-------------------- Constantinople! We shall never forget your zany barge poles! Posts: 4232 | From: Gresham, OR | Registered: Nov 2003
| IP: Logged
posted
Would appreciate it if all arguments not specified in a CALL were destroyed when that CALL was made, and the same for a RETURN. Kind of a pain to have this show up:
Okay, now I'm excited. N_TH token will be crazymazingawesome for cleaning up all sorts of messy workarounds, as well as greatly simplifying several functions I've written. This patch is gonna be great!
-------------------- Constantinople! We shall never forget your zany barge poles! Posts: 4232 | From: Gresham, OR | Registered: Nov 2003
| IP: Logged
posted
Would it be possible to make items also have the option of generating new trophies? So you use the ammo, and are left with the residue/remainder of it once its used. Maybe take it to get recycled for a discount on replacement ammo.
How do the items work? Does it only work if the weapon consumes trophies, then it consumes it on each attack, or could you have a healing potion that when used, consumes a certain number of trophies as a cost? Then what happens if you have an item(weapon) that consumes trophies when used, and a spell attached to it that also consumes/generates trophies?
Posts: 1145 | Registered: May 2005
| IP: Logged
quote: Generally, I resist this sort of cookie since it feels like the world developer is the one that specified this info in the first place, so they should just magically already know the answers, but to the degree they help, here they are
And I generally do. But my scripts don't, and neither do my beta testers. Easier to let them use a "find" command to give themselves one or more trophy, item, spell, etc. than to have them dig through the item files looking for what they want.
Aside from that, they can be used in normal scripting for various reasons. I find that these types of cookies are just generally useful.
-------------------- Constantinople! We shall never forget your zany barge poles! Posts: 4232 | From: Gresham, OR | Registered: Nov 2003
| IP: Logged
posted
SCRIPT scenes. We have SCENE, WELL, FIGHT, CUT already, why not SCRIPT?
A SCRIPT scene would take CUT one step further: instead of not showing the player (as CUT does), SCRIPT would not show anything. The player would be able to interact with the map and other players, and they could enter other scenes and camp/fight, etc. When they exited, they'd be dropped back to the map as usual.
The accompaniment to this would be the ability to specify (in world.ini or similar location) what the exit and flee buttons actually do (with GOTO_EXIT and FLEE being the defaults), so that they could be changed to GOTO SCENE 3, for instance.
This would accomplish scripts running on maps, though I can see that it would be quite difficult. I suspect this is the most reasonable way to implement it, though, if you ever decide to.
-------------------- Constantinople! We shall never forget your zany barge poles! Posts: 4232 | From: Gresham, OR | Registered: Nov 2003
| IP: Logged
Printer-friendly view of this topic
![[Smile]](smile.gif)
![[Embarrassed]](redface.gif)
![[Frown]](frown.gif)
![[Razz]](tongue.gif)
I'm sure others will find many uses for the option as well. 
