ingame Cloth Calc for version 1.34 (tw-db.info)

[DeletedUser]

Not that I know of. Yes you have to enter the new jobs separately in each world.

 

[DeletedUser]

ok i did it

thank you for the formulas and the answer

 

[DeletedUser]

Since a few time I'm facing some troubles with the script in Alamogordo. Today I reset the cache setting from the tool's option, and since I get an error message every time I try to update the data.
The error message is: "tw-db.info: a db-error occured " and then after I can't use the script.

 

[DeletedUser380]

Since an old bug is present on beta worlds once again, ClothCalc users playing here will need to manually update ClothCalc to the newest version, which is able to handle it. Sorry for inconvenience...
http://tw-db.info/?strana=userscript

For game developers: "version":"master\n revision aadf7ae (2013\/09\/20 15:40:31)" - this string cannot be converted into a valid version number used by TheWestApi

 

[DeletedUser3123]

I manually updated and get the next message: Type Error: this.wnd is null

I get it on all my Dutch and Beta worlds.

 

[DeletedUser1406]

I manually updated and get the next message: Type Error: this.wnd is null

I get it on all my Dutch and Beta worlds.

Did you uninstall the previous version before installing the new one?

 

[Diggo11]

For game developers: "version":"master\n revision aadf7ae (2013\/09\/20 15:40:31)" - this string cannot be converted into a valid version number used by TheWestApi

It's not a bug as I recall. Since we switched source control systems our revisions are now hash identified instead of numbered, so there is no way to provide a number for unamed builds. We fixed this to now always return a version string instead of NaN, so you can generally assume string return type means a beta build and then compare based on update timestamp. (Thought we may use unix format timestamp as string, but the task is not closed yet, so who knows...)

 

[DeletedUser380]

in the Game.init method:
...
Game.version=parseFloat(data.westVersion.replace(/[^.\d]/g,""));
...
TheWestApi.version=Game.version;
...

where data.westVersion (not actually data.version like I thought previously) is set as "westVersion":"master\n"; and therefore TheWestApi.version == NaN

One doesn't have to look at it for too long to see that this obviously isn't right, and definitely isn't already fixed... A lot of scripts rely on TheWestApi.version, even TheWestApi itself does and it won't work properly (for example checking registered scripts for compatibility) unless you have some valid version number. I really think you should consider using at least the previous/next ordinary version number to initialize the Game object, for example by having "westVersion":"2.06 master\n" or something that parses to a meaningful version floating point number.

 

[DeletedUser3123]

Did you uninstall the previous version before installing the new one?

No, I never needed to uninstall. But you're right. I had both the new and the old version in my list. Removing the old one did the trick. Thanks for your quick reply.

 

[DeletedUser3409]

tw-db is again problems.
does not open

 

[DeletedUser]

tw-db is again problems.
does not open

Because of some minor updates. The script won't work on newer versions even if it could be compatible. It is written in the script to not accept versions newer than x.y

 

[DeletedUser]

..if you refer to the website - that had some problems again yesterday, not related to beta but in general.

As for the script, Petee released a new version yesterday that resolves the beta "version" problem.

 

[DeletedUser380]

###########################################​

If you used to get the TW-DB Calculator JSON parse error or ClothCalc would never finish loading data from our server, it should be fixed now. Also, all calculations should be faster and the website load levels much better.

Minutes ago, I have updated the TW-DB Calculator (and ClothCalc server side components as well) with a brand new algorithm for computing best set combinations. This was the slowest part of our calculator for players with many set items and in cases of really good inventories, the calculation was so long that we had to interrupt it in order to prevent server overload, causing the issues mentioned above.

I've been trying to get myself to invent a new algorithm for months, but I never had enough time to do some really intense thinking. Yesterday, that thinking finally yielded an adaptive algorithm using some nice tricks, which should make a good job of knocking your socks off. Where some really good inventories would not have their calculation finished even in a minute, the algorithm should now handle anything in a few seconds. Users with average inventories probably won't notice that much of a difference, but there's a fraction of a second too.

If you know about someone who's ClothCalc didn't work because of this issue, spread the news!

###########################################​

 

[DeletedUser3230]

http://tw-db.info/?strana=schopnosti

Is a got tool if you want to find what you could get for a job, duels or FF. But mow all those sets are crowding the picture.

A new player has no way of getting Nattys, Munnys- October fest or whatever set. So I need an option to omit special sets and maybe even named items- so you only see the ones you can afford to buy at a reasonable price.

 

[DeletedUser1406]

A new player has no way of getting Nattys, Munnys- October fest or whatever set.

He can buy them anytime :p

 

[DeletedUser]

how? exept market

 

[DeletedUser2888]

There is a problem with calculating speed. On all my worlds, indian set is not the fastest according to the clothcalc but indian set is still the fastest. Can this be fixed?

 

[DeletedUser380]

Yes, it can.
(and it just was :-))

 

[DeletedUser2888]

Great thanks

 

[DeletedUser3230]

is it going to be possible to restore the option to se if we have the stuff the travelling merchant is selling?

I think we are many who miss that. It is one of the major set backs we have from the new flashy shiny shop.