#tfl@irc.freenode.net logs for 7 Nov 2008 (GMT)

Archive Today Yesterday Tomorrow
tfl homepage


[00:03:01] <NotADragon> Phew
[00:03:11] --- Marzo_away is now known as Marzo
[00:06:56] --- ChanServ gives voice to NotADragon
[00:07:47] <Marzo> I took a look at the classes, and did some (uncommitted) work
[00:08:08] <Marzo> Do you intend the classes to be by city, by NPC or what?
[00:11:18] <NotADragon> I'm not sure, at current, which would be best. I was hoping to grab you for your input on that, actually :-)
[00:15:59] <NotADragon> I was thinking the easiest situation may be to have an egg in the towne that could be referenced by the usecode in that towne and arbitrarily assigned resource pools. The problem with that solution becomes a problem of knowing in any given function which egg you'd be looking at. I'm not sure if assigning properties to eggs would be an issue or not..
[00:17:14] <Marzo> The eggs could be differentiated by their qualities
[00:17:24] <Marzo> But I don't think using an egg for this is the best choice
[00:17:27] <NotADragon> That made more sense in my head ... but if you need anything clarified, just ask.
[00:17:33] <NotADragon> What would you suggest, then?
[00:18:10] <Marzo> The merchants themselves call the required usecode to update the resources when you talk to them
[00:18:47] <NotADragon> And how would the different townes' resource pools be stored, then?
[00:18:51] <NotADragon> A class?
[00:18:56] <Marzo> The first time you talk to a merchant in each town, a timer is set, and this timer is used to update the resources
[00:19:16] <NotADragon> I mean actually storing them.
[00:19:19] <Marzo> A class could store all of a city's data, yes
[00:19:22] <Marzo> And manage the timer
[00:19:31] <NotADragon> Is it possible to have an array of classes?
[00:19:43] <Marzo> I don't think so, but I will have to check
[00:20:05] <NotADragon> An easy solution would just to make an array of resources. That's all a towne'
[00:20:13] <NotADragon> *towne's resource pool need be.
[00:20:22] <Marzo> I agree
[00:20:32] <NotADragon> Just an array of the Commodity class
[00:21:07] <NotADragon> Some complications arise with refined commodities, in this case, but these would likely be in merchant's inventories and not the towne proper, anyways.
[00:21:52] <NotADragon> I'm thinking a towne resource pool would be the base resources. Rock, ore, trees, livestock, etc. And then merchants would take them and 'refine' them ... and then make them into whatever they sell.
[00:22:39] <Marzo> What I was thinking was this: each town has a class that manages all of its resources(the resource management has yet to be implemented; a class can't have a class as a member var)
[00:22:58] <NotADragon> Yes, I figured there was no inheritance model.
[00:23:16] <Marzo> There is inheritance; there isn't class member variables
[00:24:06] <Marzo> A merchant 'asks' its town for a given amount of a given resource, and the class determines the availability of it
[00:24:09] <NotADragon> Ah
[00:24:26] <Marzo> (and does all required management)
[00:24:36] <NotADragon> Complication: we want to make sure resources are more or less evenly distributed.
[00:25:33] <Marzo> (I didn't add class member variables because UCC requires you to initialize all member variables; and it would be complicated to prevent you to have a class of the parent type as a member variable)
[00:25:56] <NotADragon> True.
[00:26:07] <Marzo> That can be dealt with by implementing a maximum each NPC can get from the resource pool per day
[00:27:23] <NotADragon> Aye, I had the same idea with a 'max' for the pool too, in the case producton exceeds demand (we don't want evnetual overflows in the data, not to mention the imbalances that could occur)
[00:27:42] <Marzo> Aye
[00:28:13] <NotADragon> (Apologies for the typing, had a long, hard day at work)
[00:29:20] <Marzo> We could also have all commodities have a "quality" field that determines (limits) what it can become
[00:29:45] <Marzo> For example, you could get 'diamonds' only in a town with high quality stone mining
[00:29:57] <NotADragon> I had that thought with ingots - as you may note. I am not sure if it makes sense elsewhere.
[00:30:27] <Marzo> It could determine the kinds of vegetables and food you can get, at the very least
[00:31:04] <Marzo> And it doesn't have to be literally 'high quality = good stuff' either
[00:31:39] <Marzo> We could use it as an index in a lookup table that determines the food stuff available in a town
[00:32:22] <Marzo> Thus, we could have a town that has mutton but not beef or pork, and so on
[00:32:49] <Marzo> Yew would be rich in venison, for example, while New Magincia would have lots of mutton
[00:37:41] <NotADragon> That ... might be overcomplicating it a bit, at least for now. Lets get the basics going before we get that kinda thing added
[00:45:22] <NotADragon> So how bad did I mangle classes? :-)
[00:45:41] <Marzo> Well, they can't have static vars in them for one :-)
[00:46:24] <Marzo> I have already fixed that locally, and implemented inheritance for the gem and ingot classes from the base commodity class
[00:46:44] <Marzo> Which is why I suggested implementing a 'quality' field for all commodities, by the way
[00:47:26] <Marzo> I haven't committed yet because I wanted to discuss the econ_commodities.uc file first
[00:47:32] <NotADragon> Oh?
[00:48:10] <Marzo> The first is a general suggestion: it is overall better to have static variables like classes declared in a function
[00:48:56] <Marzo> (for one, you can ensure that it will be properly initialized before it is used)
[00:49:38] <NotADragon> I debated between the two, and ended up just doing what seemed the least like for me to bungle :P
[00:49:39] <Marzo> The other point is that, as long as you keep the function name the same, the data will be kept between recompilation, even if you add more static variables before
[00:49:53] <Marzo> (saved data, that is)
[00:50:18] <Marzo> This is good to keep from losing data when upgrading the mod
[00:50:34] <Marzo> (although it will be best for when the mod is in a 'bugfix-only' stage)
[00:50:58] <Marzo> In particular, this is what motivated me to ask about your intentions for the classes
[00:51:14] <Marzo> (editing this file, that is)
[00:51:24] <NotADragon> What exactly do you mean by 'it keeps the data across recompilation?'
[00:51:57] <Marzo> The best example is with the keyring
[00:52:13] <NotADragon> You mean in the savegames?
[00:52:23] <Marzo> Yes
[00:52:42] <NotADragon> Ah, nifty :)
[00:52:57] <Marzo> If the keyring was a plain variable, any upgrades I made that added static vars before the keyring would cause it to lose data
[00:53:05] <Marzo> (plain static variable, that is)
[00:53:42] <Marzo> But as long as I don't touch the keyring declaration-initialization function, I can move it at will and still keep the saved data
[00:54:00] <Marzo> (and yes, I noticed the grammar error above)
[00:54:28] <Marzo> I hope I am making sense, I am too tired to be much coherent...
[00:55:06] <NotADragon> Well, the intention with the classes is to have "basic commodity" -> "refined commodty" -> "item" There's a third step for forging. And a special class for gemstones for the cut and quality, ingots for purity. As far as storage goes, it's a towne 'low level' pool feeds into merchant 'mid-level' pools that merchants conume to make their items.
[00:55:19] <NotADragon> The finer points of implementation are up to debate
[00:55:50] <Marzo> I think we should debate the finer points before writing any usecode
[00:58:28] <NotADragon> Well, what's your suggestion, then? I'm all ears. When it comes to programming myself, I would best describe my method as "stumbling towards something that works", after all :-)
[00:58:41] <Marzo> :-)
[00:59:04] <Marzo> While that usually works, I find that deciding what to do beforehand can result in far better code
[01:00:33] <NotADragon> Well, before we get too, too complicated, I want to have the basics running in a prototype ... that way anything fundamental about the economics that doesn't work can be tested, and evened out, before we build on that. Gotta make sure a house has a solid foundation before you start on the second or third floor :-)
[01:02:59] <NotADragon> That's where I'm coming from, there, at least.
[01:03:47] <Marzo> I am thinking of at least deciding what exactly we want it to do
[01:04:06] <NotADragon> The basic system I have ... each commodity can make X amount of Y refined commodity (exact values would have to be worked out) which you'd need to make item Z
[01:05:02] <NotADragon> Big items, a two-handed sword, for example, may take more than one of the refined commodity.
[01:05:40] <NotADragon> Every day it would regenerate basic resources at the rate specified in the Commodity's regen_rate
[01:05:53] <NotADragon> Which would then be taken by the merchants to make refined Commodities
[01:06:10] <NotADragon> I've debated making this take a certain amount of time for the merchant.
[01:06:14] <NotADragon> I'm not sure yet.
[01:07:00] <NotADragon> Then they would take a certain amount of these commodites, and make items out of them from a given list for the merchant.
[01:07:45] <NotADragon> I think how I will approach that is have a few basic merchant types - a "blacksmith" would have an array of generic arms and armour. A "farmer" will have a bunch of vegetables and fruit etc.
[01:10:29] <NotADragon> Eventually I want to emulate a little bit of "trade" -- but I want the base economics working fully before I even attempt that.
[01:21:12] --- Marzo is now known as Marzo_away
[01:50:05] --- Marzo_away is now known as Marzo
[01:50:21] <Marzo> In any event, I am going to bed; see you later
[01:55:50] <-- Marzo has left IRC ("Marzo vanishes suddenly.")
[02:26:18] <-- NotADragon has left IRC ("ChatZilla 0.9.83 [Firefox 3.0.3/2008092417]")
[10:01:40] --> Marzo has joined #tfl
[10:01:41] --- ChanServ gives voice to Marzo
[10:13:02] --- Marzo is now known as Marzo_away