furnidata... an Idea

I've probably posted this in the wrong section. I was hesitant to weather this belonged in the discussion section or not. Feel free to move it if need be.

So I had this really elaborate idea earlier today. My anitmutant on my GTE edit uses the figuredata.xml to determain if the look is legitimate or not.. so why not use furnidata.xml to replace the furniture table in the database..

After much thought I figured out ways to handle all the wired, teleports, venders ext. from the xml file. But the one thing I'm stumped by is how to handle the height?..

Does anyone have an idea on how this could be possible? If it's possible? I could make a separate table with all the furniture ids and heights, but that beats the entire idea of removing the furniture table.

Any and all idea are welcome!
@The General @Sledmore @Droppy @Vaulient @Gaby

- - - Updated - - -

Current thoughts:
-Each items seems to have a special type, for instance clothing has a special type of 23 the only items without a special type (1) are, regular furniture, wired furniture, teleports and vendors.
-Vendors could be handled with an array of hand items ids in the database?
-Wired always starts with the name of the wired - my furniture table seems to use the wired name as a type anyway so that can be handled easily.
-I checked and some teleports don't have "tele" or "teleport" in the name (could be handled via the database too?)
-Tried to see how multiheight was being handled. Taking a look at xmas11_elewood it shows 0.5 in custom params (increases by this each time?)
-Petfoods seems to have a custom param of how much nutrition they provide for the pet. I presume the other values are which pets are able to eat the foods
-Looks like the packet for interacting with an object sends back a different param depending on the interaction count of the item.

-What could "<excludeddynamic>0</excludeddynamic>" mean?

This is exactly how Azure fucked up and how everyone is complaining it is annoying.

No, you're wrong. Furnidata should be rendered from the database not other way around.

Quote:

---

Originally Posted by The General

This is exactly how Azure fucked up and how everyone is complaining it is annoying.

No, you're wrong. Furnidata should be rendered from the database not other way around.

---

Was just a thought. I'm sure habbo renders it from the the xml files from the information provided in them, but I could be wrong. Why would this be a bad approach?

- - - Updated - - -

Quote:

---

Originally Posted by Jonteh

Please don't tag me in your crap.

---

Just tagged some people who knew a little about this kind of stuff, so I could get some feedback and ideas about what I'm trying to achieve. Sorry?

Quote:

---

Originally Posted by The General

This is exactly how Azure fucked up and how everyone is complaining it is annoying.

No, you're wrong. Furnidata should be rendered from the database not other way around.

---

Considering furnidata is usually cached anyways (requiring a refresh, either live or with a server restart to change the data), it's honestly not that bad of an idea, given what a total clusterfuck state that table is currently in. But he's right about the Z-height, that's not in there.

Habbo actually renders the furnidata, productdata and figuredata XML/JSON from their database, it's not maintained as a separate copy. The smart move would be to put all data in the furniture table and use a PHP script or something to render it (cached copy of course) based on the info in the database. Perhaps have the server regenerate it when it starts (through like an API task to communicate with the web server), and have :refresh_whatever trigger that same task.

Just food for thought. @Charlotte Potts idea isn't retarded, but it is backwards. It's significantly more convenient to have the records in the database anyways, makes it easier to modify or add customs.

Quote:

---

Originally Posted by scottstamp851

Considering furnidata is usually cached anyways (requiring a refresh, either live or with a server restart to change the data), it's honestly not that bad of an idea, given what a total clusterfuck state that table is currently in. But he's right about the Z-height, that's not in there.

Habbo actually renders the furnidata, productdata and figuredata XML/JSON from their database, it's not maintained as a separate copy. The smart move would be to put all data in the furniture table and use a PHP script or something to render it (cached copy of course) based on the info in the database. Perhaps have the server regenerate it when it starts (through like an API task to communicate with the web server), and have :refresh_whatever trigger that same task.

Just food for thought. @Charlotte Potts idea isn't retarded, but it is backwards. It's significantly more convenient to have the records in the database anyways, makes it easier to modify or add customs.

---

My whole idea for this was to have my Emulator pull the furnidata from habbo to construct my catalogue_items for every item itself when habbo updates and store them in an "unsorted" section in my catalogue for sorting. Then all I'll need to do is grab the swfs from habbo and I'm done.

- - - Updated - - -

This way I can be sure that all my furniture is working correctly due to the fact that it's all coming from habbo. I'll have no missing furniture and nothing will be broken. All the interactions will be correct and data will be correct.

Ah, interesting idea. Been done before of course but interesting none the less. Most people who add new items this way usually just bulk-add and work out the Z-height later.

And no need to be an ass, @Jonteh. (S?)He's just thinking out loud and wanted to ask some of the veterans for input. Isn't that kind of the idea of a help section (in lieu of a proper discussion area) anyways?

Quote:

---

Then all I'll need to do is grab the swfs from habbo and I'm done.

---

Not really, you can automate this too.

Quote:

---

Originally Posted by The General

Not really, you can automate this too.

---

I use your tools to do grab the furniture anyway :-)

Didn't have time to reply, saw the mention though haha. I think the best option is to do it the other way around. Save all the furniture data in the database (which is actually already done) and generate your furnidata by querying the database. Of course this is really heavy for your server, because every person logging into the client will make the query happen. So it's better to apply some sort of cache or make a cron job run which generates a new XML every so many hours. This way you won't have to add furnidata to your furnidata file yourself, only to the database, then just wait a few hours and everything is generated.

My whole idea was to use the furnidata from habbo to create all my sql files automatically so I didn't have to do them. I was planning to make it detect and add all the missing items from my catalogue and add them for me (with default values), in a section of the catalogue named "unsorted".

I was going to do this as a separate application, but since I noticed habbo provided alot of the data in the xml files already. I had a thought about just calling it from the initial startup in place of the "SELECT * FROM furniture" and use the data provided in the xml file to construct my furniture data.

- - - Updated - - -

I tested this out earlier to see if it was possible to do, and the only flaw in the system I could see was it took a little longer to boot up when it initialized the furniture cache. But it works!

Quote:

---

Originally Posted by Gaby

Didn't have time to reply, saw the mention though haha. I think the best option is to do it the other way around. Save all the furniture data in the database (which is actually already done) and generate your furnidata by querying the database. Of course this is really heavy for your server, because every person logging into the client will make the query happen. So it's better to apply some sort of cache or make a cron job run which generates a new XML every so many hours. This way you won't have to add furnidata to your furnidata file yourself, only to the database, then just wait a few hours and everything is generated.

---

Never heard of caching...

- - - Updated - - -

Quote:

---

Originally Posted by Gaby

Didn't have time to reply, saw the mention though haha. I think the best option is to do it the other way around. Save all the furniture data in the database (which is actually already done) and generate your furnidata by querying the database. Of course this is really heavy for your server, because every person logging into the client will make the query happen. So it's better to apply some sort of cache or make a cron job run which generates a new XML every so many hours. This way you won't have to add furnidata to your furnidata file yourself, only to the database, then just wait a few hours and everything is generated.

---

Well this is how habbo works x)

Quote:

---

Originally Posted by The General

Never heard of caching...

- - - Updated - - -



Well this is how habbo works x)

---

How would you know how Habbo works?
Anyways, reasons for Azure loading furnidata on start up is still unclear to me, I'd have done it in a different way. Still trying to figure out the easiest and proper way to do this without the usage of a database.

Quote:

---

Originally Posted by Dominicus

How would you know how Habbo works?
Anyways, reasons for Azure loading furnidata on start up is still unclear to me, I'd have done it in a different way. Still trying to figure out the easiest and proper way to do this without the usage of a database.

---

Same way I do, I'd imagine. ^_^

Long story short, don't try to do it without the database, do it without the XML file. At least don't depend on it. Store all its data in the database and regenerate the file when necessary with a script. It makes a lot more sense to keep things in a single, easy to modify format.


Sent from my iPhone using Tapatalk