#nuvie@irc.freenode.net logs for 15 Apr 2003 (GMT)

Archive Today Yesterday Tomorrow
Nuvie homepage

[00:48:11] --> sbx has joined #nuvie
[00:55:12] --> SB-X has joined #nuvie
[01:00:46] --> Kirben has joined #nuvie
[01:16:00] <-- sbx has left IRC (Read error: 113 (No route to host))
[01:21:34] --> armchair_avatar has joined #nuvie
[01:25:49] <-- armchair_avatar has left IRC (Client Quit)
[01:49:04] <-- Eclair has left IRC ("Who turned out the lights?")
[02:25:35] --> animeloe has joined #nuvie
[02:25:39] --- animeloe is now known as Eclair
[03:08:08] --> Yuv422 has joined #nuvie
[03:08:14] <Yuv422> hi
[03:15:10] <SB-X> hi
[03:15:12] <SB-X> bbl
[03:15:15] --- SB-X is now known as sbx|afk
[03:27:44] --- sbx|afk is now known as SB-X
[03:27:46] <SB-X> b
[03:33:25] <Yuv422> how's things?
[03:36:43] <SB-X> fine
[03:36:47] <SB-X> i was watching tv
[03:36:58] <SB-X> now im fixing input<->keyword comparison in nuvie conversations
[03:37:19] <Yuv422> ah k
[03:37:40] <Yuv422> MsgScroll doesn't handle shifted/capslock chars.
[03:38:09] <Yuv422> we might need to look at a different part of the event struct
[03:38:19] <SB-X> you can test SDL_GetModState
[03:38:37] <Yuv422> yesh
[03:38:39] <Yuv422> yeah
[03:38:56] <SB-X> you wont need SDL_keysym for that
[03:39:39] <Yuv422> I thought I'd be able to get the actual char straight from the key structure
[03:39:52] <Yuv422> without having to test for modifier keys
[03:41:33] <SB-X> SDL_keysym has unicode
[03:41:39] <SB-X> if you want to use that
[03:41:58] <SB-X> you have to enable unicode first
[03:42:47] <Yuv422> it's probably not that important
[03:44:04] <Yuv422> oh one other thing
[03:44:57] <Yuv422> I made the peek_at_input() method to look at the input buffer while MsgScroll was still in input_mode.
[03:45:15] <Yuv422> so checking for input_mode == false kinda nullifies that ;)
[03:46:10] <SB-X> how do i know if its in input mode?
[03:46:42] <Yuv422> just a sec. phone call
[03:48:21] <SB-X> is peek_at_input used for external checking of input? if so, when it returns something, get_input can still return NULL, which causes a crash if i assume the input is not NULL
[03:49:04] <SB-X> i think i didnt know what peek_at_input was for, sorry
[03:49:58] <Yuv422> hehe np
[03:50:07] <Yuv422> I should comment more. :)
[03:50:30] <SB-X> what i was doing was "if(peek_at_input()) input=get_input()"
[03:50:43] <Yuv422> ah k
[03:51:15] <Yuv422> get input should return null till input_mode is set to false
[03:51:21] <Yuv422> get_input
[03:51:49] <SB-X> so i can change it to "input = get_input()... continue when input != NULL"
[03:52:09] <Yuv422> yes
[03:52:16] <Yuv422> let me double check
[03:52:45] <Yuv422> yes get_input only returns input then input_mode = false
[03:53:12] <Yuv422> be back in a bit
[03:56:38] <-- Eclair has left IRC ("Who turned out the lights?")
[04:22:53] <SB-X> peek_at_input() is fixed
[04:23:10] <Yuv422> I'll work on Actor inventories soon
[04:23:45] <Yuv422> and portraits
[04:26:19] <Yuv422> you need a get_worktype function too, right?
[04:26:29] <Yuv422> in Actor
[04:26:39] <Yuv422> and flags get/set functions
[04:30:36] <SB-X> that will be useful
[04:31:48] <Yuv422> I've got to findout where the avatars picture number is stored to
[04:31:50] <Yuv422> +o
[04:32:07] <Yuv422> probably someware in objlist :)
[04:33:57] <SB-X> its not in one of the portrait.[abz] then?
[04:34:21] <Yuv422> no, just which picture to use
[04:34:34] <Yuv422> the avatar pics ar in portrait.z
[04:34:39] <SB-X> oh the number
[04:35:42] <Yuv422> I wonder if they use that info to tell the avatars gender aswell?
[04:38:18] <Yuv422> does the converse script ask the engine for a portrait with readied items?
[04:38:49] <Yuv422> as opposed to just the actor pic.
[04:43:46] --> animeloe has joined #nuvie
[04:43:50] --- animeloe is now known as Eclair
[04:53:51] <SB-X> it just requests the npc number
[04:54:09] <SB-X> and shows the inventory if they are in the party
[04:56:59] <Yuv422> from memory the original used to show inventory for some NPCs. I could be wrong though
[05:07:56] <SB-X> do you know any of them?
[05:08:01] <SB-X> specifically
[05:08:07] <Yuv422> hehe no
[05:08:16] <Yuv422> I'm tring to find one
[05:08:24] <SB-X> i can look and see if they do something extra
[05:08:34] <SB-X> bf (d3 02) a7 = show Dupre's portrait and inventory from Shamino's script
[05:09:47] <Yuv422> the guards south of britan
[05:13:17] <Yuv422> hmm the original u6 locked up Bochs. :)
[05:13:50] <SB-X> do you know if Bochs or dosbox is faster?
[05:14:14] <Yuv422> last time I checked dosbox didn't emulate u6 correctly on OS X.
[05:14:58] <Yuv422> I'd say dosbox would be faster as it is tailoured to dos emulation.
[05:15:37] <SB-X> ok
[05:15:41] <SB-X> i just have a slow computer
[05:15:49] <SB-X> but i might be able to speed up dosbox
[05:15:55] <Yuv422> It is slow for me aswell
[05:16:19] <Yuv422> and slows right down when in combat mode or when pathfinding
[05:18:43] <SB-X> do you know any normal npc's that show inventory?
[05:18:56] <Yuv422> haven't found one yet
[05:19:13] <Yuv422> they would probably be ones that you were ment to fight
[05:19:31] <Yuv422> so you could see their weapon/armour etc.
[05:19:53] <SB-X> they must have hardcoded it
[05:20:03] <SB-X> unless its something undiscovered in another datafile
[05:20:31] <Yuv422> maybe it is only the guards then?
[05:21:25] <SB-X> they could have some flag set to show their inventory with portrait
[05:21:52] <SB-X> i mean not npc flag, something else
[05:22:06] <Yuv422> yeah quite possibly
[05:22:14] <Yuv422> just got to find it. ;)
[05:22:31] <Yuv422> I rewrote my schedule.txt doc
[05:22:49] <SB-X> why?
[05:23:06] <SB-X> added numbers?
[05:23:17] <Yuv422> started on worktype descriptions
[05:23:45] <SB-X> ok
[05:23:49] <SB-X> did you check shopkeepers?
[05:24:00] <Yuv422> what was the number again?
[05:24:44] <SB-X> um
[05:24:56] <SB-X> 0x90
[05:25:39] --> animeloe has joined #nuvie
[05:30:30] <SB-X> i moved a new game directory over the one used by nuvie so i could see how britain looks
[05:31:03] <SB-X> i notice the glitch where the screen doesnt redraw there still
[05:31:11] <SB-X> until you hit something
[05:31:28] <Yuv422> is this in nuvie?
[05:31:31] <SB-X> yes
[05:31:57] <Yuv422> I don't quite follow
[05:32:28] <SB-X> if you hold the arrow key down the screen freezes
[05:32:39] <SB-X> until you let go or the avatar is blocked
[05:33:03] <Yuv422> really
[05:33:19] <Yuv422> hmm might be due to the speed of your computer
[05:33:23] <SB-X> but i didnt see it in bucaneer's den
[05:33:46] <Yuv422> so the screen only updates when you hit something?
[05:33:57] <SB-X> or stop holding the arrow key
[05:34:18] <Yuv422> is this with a scaled window?
[05:34:40] <SB-X> yes
[05:34:42] <SB-X> point x2
[05:34:55] <Yuv422> can you try it unscaled
[05:35:18] <SB-X> ok
[05:35:56] <SB-X> same thing
[05:36:07] <SB-X> http://sourceforge.net/tracker/index.php?func=detail&aid=713539&group_id=76419&atid=547063
[05:36:25] <SB-X> that is the same bug on the tracker
[05:36:48] <SB-X> or similiar
[05:37:26] <SB-X> that one just says skipped frames though, it doesnt say it stays frozen until the avatar hits an obstacle
[05:38:14] <Yuv422> I've got to fix up object detection
[05:38:29] <Yuv422> at the moment the engine does a lot each time you move
[05:39:05] <-- Eclair has left IRC (Read error: 113 (No route to host))
[05:39:10] <Yuv422> I bet it is running pretty high on the CPU%
[05:39:29] <Yuv422> did you try running at x1 scaling?
[05:39:55] <SB-X> x1 scaling?
[05:40:06] <SB-X> is that the same as unscaled?
[05:40:57] <SB-X> when i leave the britain area it goes normally again
[05:41:19] <Yuv422> it might be the blacking then.
[05:42:18] <Yuv422> the blacking algorithm is quite expensive
[05:42:30] <Yuv422> but that should be constant
[05:42:33] <SB-X> hmm
[05:42:40] <Yuv422> maybe it is the wall reshaping?
[05:43:09] <SB-X> speaking of leaving the britain area, i already reached cove
[05:43:15] <SB-X> where it runs normally
[05:43:24] <SB-X> but that house with wounded soldiers really is crazy :)
[05:43:41] <Yuv422> hehe don't tell moonspark
[05:44:08] <SB-X> one of the guys hopped away with the bed
[05:44:14] <SB-X> and turned into a lute
[05:44:24] <Yuv422> hehe
[05:44:29] <Yuv422> I know what it is
[05:44:41] <Yuv422> there is alot of objects in britan
[05:44:56] <Yuv422> that mens lots of traversing through the object lists
[05:45:10] <Yuv422> which might be slowing you down.
[05:45:20] <SB-X> so it never is able to finish the list and redraw?
[05:45:35] <Yuv422> but it should redraw
[05:46:09] <Yuv422> it should still display each frame
[05:47:04] <Yuv422> ah
[05:47:09] <Yuv422> I know why.
[05:47:29] <Yuv422> SDL sends all the keyboard events at once if they buffer up
[05:47:57] <Yuv422> so you'll be receiving alot of buffered keyboard events at once.
[05:48:09] <SB-X> but the event loop should get them all
[05:48:11] <SB-X> in turn
[05:48:30] <Yuv422> the event loop gets all waiting events at once
[05:49:17] <Yuv422> while ( SDL_PollEvent(&event) ) {
[05:49:17] <SB-X> but its not stopping that
[05:49:39] <Yuv422> in Event::update
[05:49:40] <SB-X> it handles the events, when it unfreezes the avatar has moved
[05:49:46] <SB-X> thats what i meant by it gets them all in turn
[05:49:57] <Yuv422> yes
[05:50:16] <Yuv422> it just means you get most of your key presses in one go
[05:50:23] <SB-X> and?
[05:51:03] <Yuv422> and hence you don't break out of the SDL_PollEvent while loop till you block
[05:51:16] <Yuv422> and the game can get ontop to the events again
[05:51:24] <SB-X> oh
[05:51:35] <SB-X> why does it only happen in some places?
[05:51:56] <Yuv422> maybe they are the only places that put enough load on the CPU
[05:52:10] <Yuv422> with lots of objects to look through
[05:53:10] <SB-X> if i go west and east, just south of the blue boar tavern, that is where it either freezes or doesnt
[05:53:42] <Yuv422> mine stutters a little there too.
[05:53:49] <Yuv422> only slightly though
[05:53:57] <SB-X> i mean if im east of that it doesnt freeze, but west of that it does
[05:54:59] <Yuv422> I was thinking of adding a blocking map
[05:55:32] <Yuv422> so when moving you can quickly check the blocking map to see if you are blocked at a perticular location.
[05:55:51] <SB-X> what will you use that for?
[05:55:57] <Yuv422> at the moment you;ve got to treverse through all objects at that location
[05:56:09] <Yuv422> after getting that location of out the object list
[05:57:45] <Yuv422> out of
[05:58:31] <Yuv422> what speed cpu do you have?
[05:58:40] <SB-X> 200MHz
[06:00:57] <Yuv422> hehe doesn't make my code look good, does it.
[06:01:15] <Yuv422> considering the original ran on a 33Mhz machine
[06:01:24] <Yuv422> or maybe even less.
[06:02:16] <SB-X> i didnt think about that
[06:02:25] <SB-X> that was pretty fast :)
[06:02:56] <Yuv422> I'll have to spend some time profiling Nuvie
[06:03:08] <Yuv422> so we can get the speed up. and the load down. ;)
[06:03:46] <Yuv422> It is good you;ve got a relatively slow machine to test on. :)
[06:04:07] <SB-X> or you can just set higher requirements
[06:04:32] <SB-X> like exult
[06:04:36] <Yuv422> hehe that would just be lazy
[06:05:02] <Yuv422> and we can't have our developers running into spped issues... now can we. ;)
[06:05:15] <SB-X> lol
[06:05:17] <SB-X> ok
[06:05:46] <SB-X> to be fair you probably had the "that would just be lazy" comment typed up before i even mentioned exult :)
[06:06:04] <SB-X> ultima7 was completely different
[06:06:43] <Yuv422> yes. u7 makes u6 look quite dated. *g* but U6 was still my fav.
[06:07:30] <Yuv422> I'll work on the portraits / inventory first though
[06:07:34] <SB-X> u7 had to have strange memory hacks enabled to do what it did so fast
[06:07:36] <SB-X> ok
[06:10:24] <Yuv422> oh and one other thing
[06:10:52] <Yuv422> don't forget you can always mention noteworthy changes in the ChangeLog file
[06:11:16] <SB-X> !@#$
[06:11:18] <SB-X> oops
[06:11:25] <SB-X> i forgot there was a ChangeLog
[06:11:36] <Yuv422> hehe
[06:11:37] <Yuv422> np
[06:11:46] <SB-X> should we be adding every change to it?
[06:11:53] <SB-X> s/we/i/
[06:12:43] <Yuv422> not every little thing
[06:13:01] <Yuv422> if you make a change that is noticable to the end user then stick it in the chnagelog
[06:13:25] <Yuv422> or if you've done some major work which might effect others working on the project
[06:13:45] <SB-X> ok will do
[06:15:24] <SB-X> can i use ladders?
[06:16:07] <Yuv422> not properly
[06:16:24] <Yuv422> I still can't find an easy way to match up the surface and dungeon ladders
[06:16:30] <Yuv422> all other ladders work.
[06:16:41] <Yuv422> but that's not much use if you can't get to them.
[06:17:00] <Yuv422> there is also a problem with the edges of the dungeon levels
[06:17:06] <Yuv422> I've got to fix
[06:19:05] <SB-X> the one in the wayfarer's inn almost matches
[06:19:14] <SB-X> it lands in a room with a ladder at least
[06:19:39] <Yuv422> they all nearly match
[06:19:45] <Yuv422> that's what is frustrating
[06:22:25] <Yuv422> Willem suggested a small search around the area to find a close ladder
[06:22:29] <Yuv422> I might try that.
[06:22:40] <Yuv422> I hope ladders aren't too close. :)
[06:25:44] <Yuv422> oh I've just had an idea
[06:32:20] <SB-X> ?
[06:32:26] <SB-X> i was afk
[06:32:42] <Yuv422> just trying another ladder match formula
[06:32:47] <Yuv422> it didn't work
[06:33:08] <SB-X> did you try to just use closest ladder?
[06:33:55] <Yuv422> not yet
[06:34:12] <SB-X> what are the surface and dungeon sizes?
[06:34:15] --- animeloe is now known as Eclair
[06:34:24] <Yuv422> 1024x1024 surface
[06:34:28] <Yuv422> 256x256 dungeon
[06:35:51] <SB-X> do you have a list of all ladders locations?
[06:36:07] <Yuv422> hehe nope
[06:36:13] <SB-X> that might help
[06:36:19] <Yuv422> you could get them by watching loadObj
[06:36:26] <SB-X> ok
[06:36:46] <SB-X> did you try to see if the ladders order within each plane matches up?
[06:36:55] <Yuv422> i think it might be effected by which super chunk you're in
[06:37:07] <SB-X> like ladder 1 on surface matches ladder 1 on dungeon?
[06:37:07] <Yuv422> no but I though that might be the case
[06:37:11] <SB-X> hmm
[06:37:30] <Yuv422> don't forget their are two types of ladder
[06:37:37] <Yuv422> with the same oj_n
[06:37:39] <Yuv422> obj_n
[06:37:48] <Yuv422> they just have differing frame_n
[06:39:49] <SB-X> what is the obj num?
[06:40:12] <Eclair> hey there
[06:40:19] <Eclair> found my Ulitma stuff :)
[06:40:24] <Eclair> how's the development?
[06:41:25] <Yuv422> good
[06:41:32] <Eclair> nice
[06:41:52] <Yuv422> SB-X has done lots of good work on the converse files ;)
[06:42:01] <Eclair> just give me a holler when a "formiable" release (CVS) is out
[06:42:03] <SB-X> ty ty
[06:42:04] <Eclair> and I'll test it
[06:42:11] <SB-X> but theres a lot to do with it
[06:42:22] <Eclair> sorry I can't really help with the nitty gritty
[06:42:26] <SB-X> Yuv422: what is the obj n of ladders?
[06:42:26] <Yuv422> np Eclair
[06:42:28] <Eclair> I know nothing about programming
[06:42:29] <Yuv422> will do
[06:42:37] <Yuv422> it's in ObjManager.h
[06:42:44] <SB-X> ooh
[06:42:45] <SB-X> sorry
[06:42:51] <SB-X> shouldve realized that
[06:42:53] <Yuv422> np SB-X
[06:42:57] <Eclair> well.... I can read programs, but can't actually do programming :(|
[06:43:20] <Yuv422> you can help just as much by testing Eclair. ;)
[06:43:29] <Eclair> which is what I want to do
[06:43:34] <Eclair> I'll give screenies as well :)
[06:43:46] <Yuv422> :)
[06:43:53] <Eclair> me likes screenies.... good for one's health in the Ultima world ^_^
[06:44:53] --> vividos has joined #nuvie
[06:44:58] <vividos> hi
[06:45:05] <Yuv422> hi
[06:45:08] <SB-X> Eclair: what is the cpu speed you use to test nuvie on?
[06:45:10] <SB-X> hello
[06:46:13] <vividos> Yuv422: read my mail?
[06:46:18] <Yuv422> yes
[06:46:30] <Yuv422> SB-X has fixed those issues
[06:46:40] <Eclair> ::OS:: Linux Mainframe 2.4.20anb8 i686
[06:46:42] <Eclair> errr
[06:46:44] <vividos> yes, saw it
[06:46:48] <Eclair> ::MEM:: [Free: 8088 kB]:[Used: 508472 kB]:[Total 516560 kB]
[06:46:48] <Eclair> ::MEM%:: [Usage: 98.4342573950751%]:[Bar: ||||||||||]
[06:46:57] <vividos> I already fixed a bunch of memory leaks in my CVS, but there are some more issues
[06:46:59] <Yuv422> I'm interested to hear where we're leaking though. :)
[06:47:01] <Eclair> P2 466 (OC)
[06:47:14] <Eclair> *kicks script*
[06:47:17] <Yuv422> I fix some the other day
[06:47:20] <Eclair> 512MB RAM
[06:47:21] <Yuv422> +ed
[06:47:35] <SB-X> i dont have any kind of profiler like that
[06:48:06] <vividos> first, the Game object wasn't destroyed at the end, and ~Game didn't destroy most of it's pointer objects
[06:48:22] <SB-X> we could use an unloadGame
[06:48:28] <SB-X> the reverse of loadGame
[06:48:45] <vividos> hmm, is the Game object supposed to be used more than once?
[06:48:56] <Yuv422> yeah I haven't looked at clean up on quit.
[06:48:59] <SB-X> no
[06:49:27] <vividos> so it could go into the destructor
[06:49:35] <Yuv422> maybe in the future if we support more than on game from a central mnu
[06:49:35] <Yuv422> menu
[06:49:49] <Yuv422> one
[06:49:56] <Yuv422> hehe argh typing!
[06:49:57] <SB-X> ah
[06:50:09] <vividos> then the Game object could be constructed again
[06:50:10] <Yuv422> a destructor clean up sounds good
[06:50:34] <vividos> next thing I wondered was the static variables in U6lzw ...
[06:50:56] <Yuv422> for the stack and dictionary?
[06:50:57] <vividos> they aren't delete'd and a non-static version of the variables work perfectly
[06:50:59] <vividos> yes
[06:51:41] <Yuv422> yeah I don't know why I did it like that. ;)
[06:51:59] <Yuv422> maybe to speed things up but that is hardly a time critical section.
[06:52:07] <Yuv422> feel free to change it if you like. :)
[06:52:10] <vividos> the objects don't have to be allocated for every U6lzw class perhaps?
[06:52:39] <Yuv422> it would help to make them thread safe too. :)
[06:52:49] <vividos> ok then
[06:52:50] <Yuv422> but we don't need that now.
[06:53:45] <Yuv422> U6Lzw was a quick conversion from nodling's original C lzw code
[06:53:48] <SB-X> vividos: can you talk to npcs?
[06:53:56] <Yuv422> I was eager to see some results at that stage. ;)
[06:54:17] <vividos> no, it prints some error message
[06:54:28] <SB-X> cW != next_codeword_size?
[06:55:12] <Yuv422> are you using a 'r' without a 'rb' someware SB-X?
[06:55:26] <SB-X> ah
[06:55:29] <SB-X> that may be it
[06:55:41] <SB-X> i thought i was using rb ill look
[06:56:08] <vividos> yes, that error msg
[06:56:23] <SB-X> files/U6Lib_n.cpp
[06:56:26] <SB-X> line 199
[06:56:28] <vividos> actually, no: cW != next_free_codeword!
[06:56:32] <SB-X> hehe
[06:56:48] <SB-X> vividos: try changing that line to use "rb" instead of "r" and talk to an npc
[06:57:14] <vividos> ok
[06:57:28] <vividos> next thing was in Actor::loadSchedule
[06:57:56] <Yuv422> hmm I thought I fixed the memory issue there?
[06:58:03] <vividos> a Schedule** array is allocated, but I can't free the allocated Schedule objects because the length of the array isn't stored anywhere
[06:58:14] <Yuv422> ah k
[06:58:21] <Yuv422> but it is NULL terminated.
[06:58:34] <vividos> hmm ok
[06:59:19] <vividos> a better solution would be to use a std::vector to store the Schedule objects
[06:59:32] <vividos> (I simply don't like malloc() calls :)
[07:00:06] <Yuv422> I've never used this vector thing.
[07:00:13] <Yuv422> I'm new to C++
[07:00:17] <vividos> ok
[07:00:19] <Yuv422> as you can probably tell. ;)
[07:00:24] <Yuv422> I'll check it out.
[07:00:50] <vividos> std::vector behaves just like a normal C array, but with bounds checking and automatic free
[07:01:00] <SB-X> im using a couple in Converse, dont know if im using them properly since im not that experienced with C++ either :)
[07:01:15] * vividos looks at Converse.cpp
[07:01:50] <SB-X> it is part of STL
[07:01:54] <SB-X> (vector)
[07:02:41] <SB-X> vector<Schedule *> *sched;
[07:03:16] <SB-X> vividos: i am just using it like an array
[07:03:23] <vividos> it would be better to use vector<Schedule> sched
[07:03:39] <vividos> the Schedule* pointer are not automatically deleted then
[07:05:16] <vividos> Converse::collect_args() isn't used, I guess :)
[07:05:37] <SB-X> nope
[07:05:41] <SB-X> do you have new cvs?
[07:05:55] <Yuv422> I've got to go away for a bit.
[07:06:02] <Yuv422> be back later.
[07:06:09] <vividos> 'till then
[07:06:15] * vividos updates CVS
[07:09:39] <vividos> nothing problematic in Converse, I think
[07:12:19] * vividos tries out conversations and gets some "unknown command unimplemented" errors
[07:12:34] <SB-X> aah
[07:12:39] <SB-X> it doesnt work well :)
[07:12:51] <SB-X> but at least it shows it instead of just errors to console
[07:12:56] <vividos> yes
[07:13:11] <vividos> to continue conversations I press space, but the only thing that happens is that the arrow moves to the right
[07:13:20] <SB-X> oops
[07:13:26] <SB-X> only enter and escape work there
[07:13:28] <vividos> aah, have to use return :)
[07:14:51] <vividos> hmm, are the keyworlds highlighted in the original u6?
[07:14:58] <SB-X> yes
[07:15:01] <SB-X> where you see @word
[07:15:14] <vividos> yes
[07:17:49] <vividos> I'm at TileManager now ... desc_buf could be made a std::string
[07:19:11] <SB-X> do you still work on uu engine?
[07:19:37] <vividos> yes
[07:20:07] <SB-X> hows it going?
[07:22:07] <vividos> it progresses well at the moment
[07:23:52] <SB-X> thats good :)
[07:24:22] <SB-X> oh, dont talk to the beggar outside the castle in britain
[07:24:27] <SB-X> that seems to cause an infinite loop
[07:24:44] <vividos> ok :) can't go there either
[07:25:20] <SB-X> just as well then
[07:30:14] <vividos> hmm, what IDE/whatever do you use for developing?
[07:32:54] <SB-X> nedit
[07:35:10] <vividos> under linux?
[07:35:28] <vividos> ok to move the ~Converse to the .cpp file?
[07:35:46] <SB-X> yeah im using slackware linux 8.0
[07:36:02] <SB-X> sure
[07:36:05] <SB-X> ill move it
[07:36:09] <SB-X> since im editing that file now
[07:36:14] <vividos> ok good
[07:36:27] <vividos> you could add a "delete src", too
[07:37:29] <SB-X> oh
[07:37:31] <SB-X> forgot about that
[07:37:37] <SB-X> ok
[07:37:58] <SB-X> src used to be static, passed to Conversefrom Game until i moved it
[07:38:19] <vividos> ah ok
[07:44:10] --> armchair_avatar has joined #nuvie
[07:47:03] <-- armchair_avatar has left IRC (Client Quit)
[07:49:29] <vividos> Look::readDescription() returns a malloc()ed string, which is never freed
[07:55:26] <vividos> have to go offline for some time
[07:55:28] <-- vividos has left IRC ("Leaving")
[08:10:42] * Yuv422 looks at all the fixes on nuvie-cvs :)
[08:13:23] --> vividos has joined #nuvie
[08:14:11] <vividos> re
[08:14:37] <Yuv422> thanks for fixing all those issues vividos! :)
[08:14:53] <SB-X> wb
[08:14:57] <vividos> no problem!
[08:15:02] <vividos> still have some leaks :)
[08:15:06] <Yuv422> I should have put all that stuff in when I originally wrote those classes.
[08:15:30] <vividos> I guess ObjManager holds a linked list with all objects or so
[08:15:37] <Yuv422> yes
[08:15:39] <Yuv422> several
[08:15:45] <vividos> the list isn't freed anywhere; should that happen in the dtor?
[08:15:58] <Yuv422> yeah I'll fix that up.
[08:16:52] <vividos> good; most leaks are in the ObjList/U6LList thing
[08:16:57] <Yuv422> as I might change the obj structure a bit soon
[08:17:05] <vividos> ok
[08:17:12] <vividos> about the Look::readDescription() ...
[08:17:57] <vividos> it returns a malloc()ed string that is never freed. it's probably better to keep the returned string in a std::string
[08:19:31] <Yuv422> I'm not too familiar with C++ strings.
[08:19:59] <Yuv422> I couldn't find out how to initailize a C++ string from a C string
[08:20:24] <Yuv422> it is easy if it is a const char *
[08:20:29] <vividos> just std::string::assign() it or pass it in the constructor
[08:20:41] <Yuv422> can assign take char *
[08:20:59] <vividos> yes, the pointer is automatically converted to const char*
[08:21:07] <Yuv422> ah
[08:22:29] <Yuv422> hehe you better not look in MsgScroll then. hehe lots of evil C string stuff in there. ;)
[08:23:07] <vividos> heh :)
[08:23:21] <vividos> btw, what exactly does Look::readDescription() do?
[08:23:57] <Yuv422> it grabs the string from the data buffer.
[08:24:02] <Yuv422> I think. let me check
[08:24:04] <vividos> it looks like a strdup() function :)
[08:24:15] <vividos> since it only duplicates the given string
[08:24:41] <Yuv422> hehe yeah
[08:24:52] <Yuv422> oh and it updates the max_len
[08:25:20] <vividos> ah ok, max_len is a class member
[08:25:52] <Yuv422> I've got to go now
[08:26:06] <vividos> bye Yuv422!
[08:26:08] <Yuv422> I'll talk to you guys tomorrow
[08:26:11] <Yuv422> cya
[08:26:12] <SB-X> cya
[08:26:17] <-- Yuv422 has left IRC ("Read error: 69 (Excessive tongue)")
[08:33:05] <vividos> have to go too. bye!
[08:33:18] <-- vividos has left IRC ("Leaving")
[08:35:45] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[08:35:48] --> Kirben2 has joined #nuvie
[08:35:54] --- Kirben2 is now known as Kirben
[10:14:03] <-- SB-X has left IRC ("X-Chat [1.6.4]")
[10:35:26] <-- Kirben has left IRC (brunner.freenode.net irc.freenode.net)
[10:40:55] --> Kirben has joined #nuvie
[13:13:30] <-- Eclair has left IRC (brunner.freenode.net irc.freenode.net)
[13:14:40] --> Eclair has joined #nuvie
[14:21:22] --> laxdragon has joined #nuvie
[15:07:06] --> wjp has joined #nuvie
[16:21:20] <-- Kirben has left IRC ("System Meltdown")
[17:01:04] --> armchair_avatar has joined #nuvie
[17:01:52] <armchair_avatar> hihi
[17:05:38] <wjp> hi
[17:08:35] <armchair_avatar> i found a bug
[17:10:51] <wjp> can you post it to the nuvie bug tracker?
[17:10:53] <wjp> http://sourceforge.net/tracker/?group_id=76419&atid=547063
[17:12:31] <armchair_avatar> it's too insignificant and too easy to fix
[17:13:24] <armchair_avatar> in Converse.h in line 94, there should be an "std::" in front of "stack"
[17:17:05] <wjp> ah, I think I can manage to fix that, yes :-)
[17:18:22] <wjp> in fact, it doesn't even compile here without fixing it
[17:19:25] <wjp> committed; thanks
[17:19:32] <wjp> bbl
[17:42:30] <-- armchair_avatar has left IRC ("Client Exiting")
[18:12:37] <-- Eclair has left IRC (brunner.freenode.net irc.freenode.net)
[18:12:37] <-- laxdragon has left IRC (brunner.freenode.net irc.freenode.net)
[18:12:37] <-- wjp has left IRC (brunner.freenode.net irc.freenode.net)
[18:12:37] <-- ChanServ has left IRC (brunner.freenode.net irc.freenode.net)
[18:13:04] --> ChanServ has joined #nuvie
[18:13:04] --> wjp has joined #nuvie
[18:13:04] --> laxdragon has joined #nuvie
[18:13:04] --> Eclair has joined #nuvie
[21:37:09] <-- wjp has left IRC ("Zzzz...")
[23:23:08] * Eclair is away: ... food