#tfl@irc.freenode.net logs for 1 Dec 2006 (GMT)

Archive Today Yesterday Tomorrow
tfl homepage


[00:02:26] --- Marzo_away is now known as Marzo
[00:02:28] <Marzo> Back
[00:02:32] <SleepingDragon> moo
[00:02:50] <Marzo> Mad cow disease again?
[00:02:54] <SleepingDragon> lol
[00:02:58] <SleepingDragon> No
[00:03:00] <SleepingDragon> close though
[00:03:06] <SleepingDragon> Mad mage disease :D
[00:03:14] <Marzo> Oh, mad AS a cow disease :-)
[00:03:26] * Marzo ducks
[00:04:11] <SleepingDragon> Lmao
[00:04:19] <Marzo> I don't know if you have noticed, but I imported some more SI intrinsics to BG (as well and some BG intrinsics to SI)
[00:04:59] <Marzo> I am thinking of importing also get_temperature and set_temperature, but thete is hard-coded gump and bark information which would be good to de-hard-code first
[00:05:16] <SleepingDragon> Hmm
[00:05:17] <Marzo> (as well as hard-coded warmth data for clothing and armor)
[00:05:20] <SleepingDragon> Yes
[00:05:26] <SleepingDragon> That would be very useful for TFL
[00:05:31] <Marzo> It would be neccessary for TFL
[00:05:34] <Marzo> lol
[00:05:45] <SleepingDragon> I want the desert area to actually be a desert :P
[00:05:54] <Marzo> This brings me to another point
[00:06:28] <Marzo> I have been thinking of finally moving the info in the dat files to text files and have diff patches for them
[00:07:16] <Marzo> Of course, Exult will still need to be able to read the old dat files
[00:07:23] <SleepingDragon> Yes
[00:07:33] <SleepingDragon> Have the original in /exult/data
[00:07:45] <SleepingDragon> and then diff patch on top of that one from __MODS__/data
[00:07:51] <Marzo> I have been thinking of having the new data files be able to specify ALL the shape data, including that which was previously hard-coded
[00:08:41] <SleepingDragon> That would be useful
[00:08:46] <SleepingDragon> Dont forget frame names
[00:09:02] <Marzo> Then, something like the current bodies.txt, paperdol_info.txt and shape_inf.txt files would be used to specify the hard-coded data from the original games -- being loaded after static dat files but before the new patch txt files
[00:09:41] <Marzo> And be used only for BG and SI, and any mods based on them -- there would be no need to use them for new games
[00:09:51] <SleepingDragon> Howso
[00:10:05] <Marzo> What I have though so far:
[00:10:30] <SleepingDragon> UUUGHHH
[00:10:35] <SleepingDragon> http://en.wikipedia.org/wiki/Ultima
[00:10:42] <Marzo> Have a (say) 'hardcoded.txt' file containing the data which was hard-coded in the originals
[00:10:42] <SleepingDragon> Its just a bunch of lists @_@
[00:10:55] <SleepingDragon> hmm
[00:11:07] <SleepingDragon> can Exult read text placed in flexes?
[00:11:23] <Marzo> I can probably arrange something, yes
[00:11:33] <SleepingDragon> ie, have say hardcoded.flx and inside have bodies.txt, paperdoll.txt, etc
[00:11:44] <Marzo> After loading the original dat files, Exult would load this hardcoded.txt and diff-patch the original data
[00:12:26] <Marzo> I am not intending this hardcoded.txt file to ever be edited by anyone except for the purposes of de-hard-coding data in Exult
[00:12:38] <SleepingDragon> what I mean is
[00:12:46] <SleepingDragon> have the files seperate, but bundled
[00:12:50] <SleepingDragon> for organization's sake
[00:13:17] <Marzo> I don't think it will really be all that neccessary, but I have been working on that assumption
[00:13:40] <SleepingDragon> heh
[00:13:47] <Marzo> (basically, add the aforementioned and already existing txt files be bundled in the respective game flx)
[00:14:10] <Marzo> I have thrown the idea of the master hardcoded.txt file just as a testing ground :-)
[00:14:32] <Marzo> That phrase came out wrong
[00:14:36] <SleepingDragon> heh
[00:14:55] <SleepingDragon> what you could do is have misc.txt and put anything not already in a datfile there
[00:15:15] <Marzo> In any case: the hardcoded txt files would only be needed for BG and SI (and hence, their expansions and mods)
[00:15:35] <Marzo> As all the data in them would be independently-specified in the new txt data files
[00:15:45] <Marzo> (and with many benefits too)
[00:15:47] <SleepingDragon> hehe
[00:16:54] <Marzo> And the hardcoded txt files should, in fact, *never* be distributed by any mods as Exult would likely not read them -- although I might retain support for the already existing txt files
[00:17:26] <Marzo> How does that sound so far?
[00:17:29] <SleepingDragon> Well thats what I was suggesting
[00:17:46] <SleepingDragon> Mind that a mod may want to change anything that was hardcoded though
[00:17:57] <Marzo> He can use the new data files for that
[00:18:04] <Marzo> *He->it
[00:18:24] <Marzo> They will be able to change all the hard-coded data
[00:19:12] * Marzo maniacally laughs and ominously states that he thinks of EVERYTHING! Mwahaha!
[00:19:15] <Marzo> :-)
[00:19:31] <SleepingDragon> Really
[00:19:39] <SleepingDragon> Whys there still Exult bugs then?
[00:19:40] <SleepingDragon> :P
[00:19:44] <Marzo> lol
[00:19:52] * SleepingDragon pokes the Exult bug tracker
[00:20:09] <Marzo> I am also thinking of making symbol tables for the original game usecode
[00:20:30] <Marzo> Maybe in the form of includes which UCC automatically adds to compiled usecode
[00:20:34] <SleepingDragon> Thats not really terribly neccesary
[00:21:36] <Marzo> But it would certainly be useful, as I could effectivelly decouple the association of low shapes and npcs and their usecode functions
[00:22:59] <Marzo> This would help new games as they would no longer need to follow the same paradigm as the original games
[00:23:12] <SleepingDragon> True
[00:23:35] <Marzo> And I am also thinking of having a way to specify the avatar's usecode number (instead of it being simply -356)
[00:23:52] <Marzo> Although I am not terribly sure about that
[00:24:20] <SleepingDragon> Now we're getting into the marginal use section
[00:24:21] <SleepingDragon> :-)
[00:24:28] <Marzo> Not really
[00:25:00] <Marzo> One of the main barriers to more than 356 NPCs is the fact that the avatar is -356 for usecode purposes
[00:25:14] <Marzo> And that the whole party is -357
[00:25:25] <SleepingDragon> You dont have to change the avatar and party numbers to increase the bounds
[00:25:35] <SleepingDragon> Unless theres some nasty hardcoding going on
[00:25:39] <Marzo> No, but it would likely make things easier
[00:26:18] <Marzo> I could always program Exult & Studio to skip NPC #s 356 and 357 for all intents and purposes
[00:26:46] <Marzo> (maybe have some indicator in to the effect that they represent the avatar and the whole part)
[00:27:14] <SleepingDragon> It WOULD be helpful to have it as a var and not as a const, at the least, though.
[00:27:26] <SleepingDragon> the avatar and party usecode nums that is
[00:27:39] <Marzo> Although it would only be useful for new games, now that I think about it
[00:27:53] <SleepingDragon> It owuld be nice to be able to define them with a directive or even just a redeclaration in the code
[00:27:55] <Marzo> Unless we reimplement ALL of BG's and SI's usecode
[00:28:15] <SleepingDragon> You could have any redecl be a pointer to the original
[00:29:02] <Marzo> In which case calls to the original might run into problems
[00:29:15] <Marzo> I will have to meditate more on this particular issue
[00:29:48] <SleepingDragon> For how many cycles shall thou meditate?
[00:29:59] <Marzo> In any case, I will add the ability to specify the event id for the talk schedule
[00:30:02] <Marzo> 3
[00:30:06] <SleepingDragon> Hehe
[00:30:24] <Marzo> (in the original BG, the NPC's function was called again with a DOUBLECLICK event)
[00:30:35] <SleepingDragon> Schedules period would be handy to have variable func numbers with as opposed to a const
[00:31:04] <Marzo> The usecode schedules more-or-less promise that
[00:31:33] <SleepingDragon> Not neccesarilhy
[00:31:44] <SleepingDragon> They can be customizable and still have fixed f'n numbers
[00:31:49] <Marzo> If it is determined that they do not impose a significant performance hit, you can expect a load of new intrinsics as well as the conversion of the normal schedules to UCC schedules
[00:31:59] <SleepingDragon> Hmm
[00:32:15] <Marzo> (at least I am thinking of doing that)
[00:32:28] <SleepingDragon> It would be a useful concept to perhaps seperate the new implementations as a seperate "exult" include or somesort mechanism
[00:32:49] <Marzo> What do you mean?
[00:33:04] <SleepingDragon> Instead of including all the new intrinsics, have them optional
[00:33:30] <Marzo> Why would that be a good thing?
[00:33:41] <SleepingDragon> Performance.
[00:34:09] <SleepingDragon> If a mod or new game doesn't use the new intrinsics, the added functions just become excess baggage.
[00:34:22] <Marzo> The problem would not be the intrinsics, silly, but the fact that usecode would be called every now and then for NPCs to detemine their scheduled actions
[00:34:35] <Marzo> :-)
[00:34:41] <SleepingDragon> ...
[00:34:48] <SleepingDragon> What I mean is if they dont use custom schedules
[00:35:02] <SleepingDragon> They should not need to include the header for custom schedules
[00:35:19] <Marzo> What I meant was that I intended to convert ALL schedules to usecode schedules and have Exult use *them* instead
[00:35:37] <SleepingDragon> Hmm.
[00:35:53] <SleepingDragon> That may present problems.
[00:35:58] <Marzo> The addition of new intrinsics would pose no real performance problems except, maybe, for Exult's loading time
[00:36:19] <Marzo> Which is why I started with the conditional I did
[00:36:44] <Marzo> (a bigger executable takes slightly longer to load)
[00:36:58] <Marzo> [22:31] Marzo: If it is determined that they do not impose a significant performance hit, you can expect a load of new intrinsics as well as the conversion of the normal schedules to UCC schedules
[00:37:13] <Marzo> Ah, I can see the source of the confusion
[00:37:49] <Marzo> I should have said that if it is determined that *usecode schedules* do not impose a significant performance hit, ...
[00:38:12] <SleepingDragon> A-ha
[00:39:02] <Marzo> As for the intrinsics: while the current limit on intrinsics is 1024, it can easily be changed to 65536 if needed
[00:39:08] <Marzo> (1024 intrinsics)
[00:39:26] <Marzo> Exult would be seriously bloated long before that, though
[00:39:43] <Marzo> (more than it is already)
[00:42:45] <SleepingDragon> Only a mere 65536?
[00:42:51] * SleepingDragon waves hand dismissivelhy.
[00:43:35] <Marzo> That is if I do not add any new special intrinsic-calling opcodes and I just use the original opcodes
[00:43:56] <Marzo> (I can literally change a single number to increase up to that limit)
[00:44:12] * SleepingDragon changes long to float.
[00:44:14] * SleepingDragon hides.
[00:44:20] <Marzo> lol
[00:44:42] * SleepingDragon looks around for float64
[00:45:00] <Marzo> You'll find it under 'double'
[00:45:07] <SleepingDragon> hehe
[00:45:13] <Marzo> :-)
[00:45:23] <SleepingDragon> In .NET its float64, just to be confusing :P
[00:45:41] <SleepingDragon> Well not really, but confusing because its not what you expect it to be.
[00:45:44] <Marzo> I think this is in preparation for 64-bit processors
[00:46:05] <SleepingDragon> Or just someone using a decent naming convention with variables for once.
[00:46:15] <Marzo> (M$ does occasionally do something right, you know)
[00:46:21] <Marzo> :-)
[00:46:40] <SleepingDragon> hehe
[00:50:54] <Marzo> Well, I am off to bed
[00:51:13] <Marzo> (and with a bad headache to boot :-( )
[00:51:18] <Marzo> Good night
[00:51:22] <SleepingDragon> Sleep well Avatar
[00:51:29] <-- Marzo has left IRC ("Marzo vanishes suddenly.")
[04:42:54] --> servus has joined #tfl
[11:11:58] <-- SleepingDragon has left IRC (Read error: 110 (Connection timed out))
[13:09:04] <-- Kirben has left IRC (Read error: 110 (Connection timed out))
[18:52:03] --> SleepingDragon has joined #tfl
[18:52:07] --- ChanServ gives voice to SleepingDragon
[20:28:36] --> Marzo has joined #tfl
[20:28:37] --- ChanServ gives voice to Marzo
[20:28:48] <Marzo> Hi
[20:29:06] <SleepingDragon> moo
[20:39:30] <Marzo> Here is an idea: you may want to consider creating a SF project for your UCC IDE
[20:39:59] <SleepingDragon> sometime
[20:40:09] <Marzo> That way, it has an actual chance of ever being finished :-)
[20:40:19] <SleepingDragon> ahahaha
[20:40:23] <SleepingDragon> getting finished
[20:40:26] <SleepingDragon> thats funny
[20:41:55] <Marzo> My point more or less :-p
[20:53:28] <Marzo> On another note, related to what I was saying last night: the get_temperature and set_temperature intrinsics only set lower temperatures; Furnace does it with eggs instead
[20:55:26] <SleepingDragon> should have the temps able to increase too
[20:55:41] <Marzo> It will require a lot of changes to the underlying code
[20:56:38] <Marzo> I am not saying it is not doable, but it will be a lot of trouble and for a (IMO) questionable benefit
[20:57:13] <SleepingDragon> Questionable?
[20:57:50] <Marzo> Well -- for starters, there are no equivalent to the freezing-colored gumps
[20:58:03] <SleepingDragon> Code Standards 101: Set commands should be able to set any logically sensible value.
[20:58:14] <SleepingDragon> Marzo: That's easily fixed
[20:58:27] <Marzo> Not in the o
[20:58:39] <Marzo> Damn delete and enter buttons being too close
[20:59:22] <Marzo> There would be the need to add new barks, and allow negative values of 'warmth' for clothing
[20:59:30] <SleepingDragon> No
[20:59:32] <SleepingDragon> Not at all
[20:59:50] <SleepingDragon> You dont need negatives for warmth
[20:59:55] <Marzo> Also, there would be the need to check if the total warmth exceeds a certain value, in which case the heat would begin
[21:00:08] <Marzo> Hm... maybe
[21:00:23] <SleepingDragon> Marzo you can outsource the handlers to UCC
[21:00:34] <SleepingDragon> all that needs done Exult-side is the calls
[21:00:44] <Marzo> brb
[21:00:50] --- Marzo is now known as Marzo_away
[21:07:47] --- Marzo_away is now known as Marzo
[21:08:28] <Marzo> RE: outsourcing handlers to UCC: how is it different than using UCC from the outset and ignoring the intrinsics completelly?
[21:08:55] <Marzo> I think it was done with intrinsics in the original because they did not have static vars
[21:08:59] <Marzo> Which we do
[21:09:21] <SleepingDragon> Thats what I meant
[21:09:22] <Marzo> Hm.
[21:10:06] <Marzo> In any case, I'll de-hard-code the data in the intrinsics for mods to the original SI
[21:10:15] * SleepingDragon pokes
[21:10:18] <Marzo> (in *those two* intrinsics)
[21:10:19] <SleepingDragon> TFL will need it
[21:10:34] <SleepingDragon> So that means BG needs to at least be capable of it
[21:10:35] <Marzo> Whom did you poke?
[21:10:50] <Marzo> Like I said, the intrinsics aren't really needed for it
[21:10:55] <SleepingDragon> Theres two people in these conversation, and I sure aint poking for it
[21:11:00] <SleepingDragon> Marzo: Yes and no
[21:11:08] <SleepingDragon> The intrinsics for changing temp no
[21:11:13] <Marzo> Even in SI, they used eggs for it
[21:11:20] <SleepingDragon> Intrinsics for changing the inventory and ztats gumps
[21:11:21] <SleepingDragon> Yes
[21:11:43] <Marzo> Only the stats gump were changed; the inventory wasn't
[21:11:58] <SleepingDragon> Right well we still need the ztats
[21:11:58] <Marzo> But I see your point
[21:13:23] <SleepingDragon> Indeedy
[21:13:27] <SleepingDragon> hot/cold
[21:13:30] <SleepingDragon> though
[21:13:32] <Marzo> Well, in the original, it was just a change in the frame number, keeping the shape number
[21:13:38] <SleepingDragon> just an intrinsic to change the gump
[21:13:41] <SleepingDragon> by frame or shape
[21:13:44] <SleepingDragon> would be nice
[21:13:59] <Marzo> I'll see what I can conjure up
[21:14:38] <SleepingDragon> then we can use it for more than hot/cold down the line
[21:14:44] <SleepingDragon> if that comes up
[21:15:00] <Marzo> But I think I'll worry about the hardcoded data first
[21:15:11] <Marzo> This being mostly a cosmetic effect after all
[21:15:24] <SleepingDragon> well first things first with this
[21:15:33] <SleepingDragon> is to dehardcode the SI data
[21:15:45] <SleepingDragon> Then what you make in place for SI should be portable,
[21:16:12] <Marzo> It is included in the enormous amount of things I intend to de-hard-code in the next round
[21:16:24] <SleepingDragon> I strongly dislike having to remember seperate intrinsics for SI and BG
[21:16:32] <Marzo> (what has been slowing me down is the *format* of the data)
[21:16:45] <SleepingDragon> heh
[21:16:58] <Marzo> Which is why I am slowly adding a lot of intrinsics from SI to BG and vice-versa
[21:17:11] <SleepingDragon> heh
[21:17:14] <Marzo> Unifying the intrinsics table
[21:17:20] <SleepingDragon> hehe
[21:17:51] <Marzo> Although I must say that, particularly in regard to intrinsics which have hard-coded shape information, I am hesitant to export to one or another
[21:18:12] <SleepingDragon> hmm
[21:18:16] <Marzo> (for example, the fire_cannon intrinsic, and the mark_virtue_stone and recall_virtue_stone intrinsics)
[21:19:27] <SleepingDragon> i wouldnt worry about
[21:20:18] <Marzo> Indeed, as we can use static vars for it
[21:20:25] <SleepingDragon> indeed
[21:20:33] <Marzo> Hm
[21:20:50] <Marzo> I think I'll rewrite the Mark and Recall code to use static vars
[21:21:09] <Marzo> It will make the attuning of the white virtue stone less hackish
[21:21:56] <SleepingDragon> Mmm hacks
[21:22:04] <SleepingDragon> hmm
[21:22:09] <SleepingDragon> Richard Stallman is an odd fellow
[21:22:36] <Marzo> (Right now, I move the stone to the place I intend to mark, use the intrinsic, then put it back in the original container)
[21:23:05] <Marzo> It would have the downside of breaking old games, though
[21:23:08] <SleepingDragon> I have a suspicion that I didn't put them any more at ease when I started the first lecture by leading everyone in a Bulgarian folk dance. Perhaps this raised questions in their minds about my affiliation with foreign powers.
[21:24:16] <Marzo> Hm... have you been contrinuting to the Scots Wikipedia today? :-p
[21:24:46] <Marzo> *contributing
[21:33:01] <SleepingDragon> Nope
[21:33:15] <SleepingDragon> thats from Richard Stallman's page
[21:33:15] <SleepingDragon> heh
[21:33:35] <Marzo> :-)
[21:33:49] <Marzo> I asked because I remembered something you said last night
[21:33:51] <SleepingDragon> the bit at the bottom is best
[21:34:09] <SleepingDragon> http://www.stallman.org/articles/texas.html
[21:34:12] <SleepingDragon> is the article
[21:47:12] <Marzo> brb
[21:47:18] --- Marzo is now known as Marzo_away
[22:24:23] --> Kirben has joined #tfl
[22:24:23] --- ChanServ gives voice to Kirben
[23:49:22] <-- Marzo_away has left IRC (Read error: 110 (Connection timed out))