Flatlander
Species Developer
Deleted
Last edited:
<item id="1294" article="a" name="small stone">
<attribute key="weight" value="360" />
<attribute key="attack" value="5" />
<attribute key="weaponType" value="distance" />
<attribute key="shootType" value="smallstone" />
<attribute key="range" value="4" />
<attribute key="breakChance" value="3" />
<attribute key="ammoAction" value="moveback" />
</item>
<item spriteId="1294" id="99" article="a" name="small stone">
<attribute key="weight" value="360" />
<attribute key="attack" value="5" />
<attribute key="weaponType" value="distance" />
<attribute key="shootType" value="smallstone" />
<attribute key="range" value="4" />
<attribute key="breakChance" value="3" />
<attribute key="ammoAction" value="moveback" />
</item>
<item spriteId="1294" id="100" article="a" name="small training stone">
<attribute key="weight" value="60" />
<attribute key="attack" value="1" />
<attribute key="weaponType" value="distance" />
<attribute key="shootType" value="smallstone" />
<attribute key="range" value="7" />
<attribute key="breakChance" value="0" />
<attribute key="ammoAction" value="moveback" />
</item>
It would be far easier (just needs map editors to be edited aswell) to virtualy create items in items.xml
What do I exactly mean by that you think?
My idea is the following:
At the moment it's basicly like this, you can only create one item to one sprite, like this:
Code:<item id="1294" article="a" name="small stone"> <attribute key="weight" value="360" /> <attribute key="attack" value="5" /> <attribute key="weaponType" value="distance" /> <attribute key="shootType" value="smallstone" /> <attribute key="range" value="4" /> <attribute key="breakChance" value="3" /> <attribute key="ammoAction" value="moveback" /> </item>
Why don't we rather let the server read what sprite id it is and virtualisize a unique id for it, like this:
Code:<item spriteId="1294" id="99" article="a" name="small stone"> <attribute key="weight" value="360" /> <attribute key="attack" value="5" /> <attribute key="weaponType" value="distance" /> <attribute key="shootType" value="smallstone" /> <attribute key="range" value="4" /> <attribute key="breakChance" value="3" /> <attribute key="ammoAction" value="moveback" /> </item> <item spriteId="1294" id="100" article="a" name="small training stone"> <attribute key="weight" value="60" /> <attribute key="attack" value="1" /> <attribute key="weaponType" value="distance" /> <attribute key="shootType" value="smallstone" /> <attribute key="range" value="7" /> <attribute key="breakChance" value="0" /> <attribute key="ammoAction" value="moveback" /> </item>
It is just a small change in items.xml but it makes such a huge difference, what my idea does is easily explained.
It would make you able to create an infinite ammount of different items from one sprite, so you can have 200 different small stones and such but they all have a different id with different names and stats, just the sprite id will remain the same.
I know this would cause a bit of work for the map editor but this would bring up thousands more of possibilities and it would enhance the item flexibility by a lot.
Honestly I wouldn't do anything with attributes in the source.
Why do you have to do attack, defense, armor, etc in the source?
Just make an items.xml feature that allows you to add any attribute to any item.
Code:<attributes> <attribute key="armor" value="10"/> <attribute key="defense" value="8"/> <attribute key="virginitydamage" value="99999"/> </attributes>
Then when an item is created add all those attributes to it as defaults from the items.xml.
Then remove the seperation of onHealthChange and onManaChange in creatureevents and maybe bring back onStatsChange instead since it had leagues more functionality. And do all the Armor, Manashield, Defense, Animations, damageText, combatLog Entries etc in there.
go to weapons.xml, spells.xml and do the damage formula there (have a default.lua instead of function="default" or whatever it is now)
If instead of setting up TFS to be a Cipsoft Simulator, you set it up to have functionality at it's core, You immediatly get the best of both worlds.
You make me sad. Because I know you are mostly right.
I will agree that the average OT Player does not care about custom content. But to me that is no excuse for not having it.
If you have to make something anyway, why not make it so you can manage it from LUA rather than requiring source edits?
And it isn't just item attributes, I can do many things with 0.4 that you cannot do in 1.0.
And if you check my comment's Customizing TFS thread, I can do many things in my TFS you cannot do in 0.4.
I just hate going SO far backwards in time, into the stone age of functionality.
Sorry reading all your posts it seems that you're a limited scripter or programmer.
If you at least followed TFS 1.x development you will see that 99% of things possible to do in 0.4 is possible to do in 1.x IF you are a experienced scripter and have creativity
ItemAttributes can be done by script with no source change by the way.
The goal of TFS should be (in my opinion) to make it as easy as possible for the Typical and Intermediate users to do Advanced things.
This way, if you wanted to change monster AI, or how NPCs work, or change how manashield works, or anything you could easily do it.
There are a lot of substances which can be used instead of sugar without changing final effect. Players don't really care about these events you all miss so much in 1.0 and they(players) are easier to convince than you think.You are right, 99% of the things you can do in TFS 0.4 can be done in 1.0. The 1% missing is very important though.
That would be like making a cake and forgetting to add sugar, and saying "99% of the ingredients are in there, no one should complain."
It's been constantly re-done and changed and you can even see large portions of it noted out. It is obvious that it isn't a polished script, but thanks for the comment.The script above can be optimized and almost cut half of the code.