• There is NO official Otland's Discord server and NO official Otland's server list. The Otland's Staff does not manage any Discord server or server list. Moderators or administrator of any Discord server or server lists have NO connection to the Otland's Staff. Do not get scammed!

So I'm in the process of designer an RPG server

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.
 
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.

Using the item attributes, you can already re-use sprites to create new items with same sprite id. It was done before with doitemsetattribute and getitemsetattribute, on another forum... If you would like I could take the time and hunt down the link for you. Basically created a new .xml file and from that it had a script to convert the new .xml file's items over to re-use same sprites...
 
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.

That would be amazing! I doubt that is going to happen however... I would be satisfied if the old way with being able to make your own like you said before with a new string in lua. That would still open up worlds of possibilities.
 
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.
 
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.

Maybe you also are like many and see what you want to see? He said himself he hasn't been keeping up to date with 1.0, however he does stress that his point is
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.
 
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."
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.
 
If you need help with converting scripts to 1.0 just ask.
I moved all scripts in my datapack from 0.3.7 to 1.0 and only thing I wasn't able to convert was upgrade system.
 
The script above can be optimized and almost cut half of the code.
 
The script above can be optimized and almost cut half of the code.
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.

Know what we have Hijacked this thread enough I'm deleting all my posts.
 
Back
Top