#exult@irc.freenode.net logs for 1 Jan 2013 (GMT)

Archive Today Yesterday Tomorrow
Exult homepage

[00:03:37] <-- Malignant_Manor has left IRC (Quit: ChatZilla 0.9.89 [Firefox 17.0.1/20121128204232])
[00:55:46] --> DominusExult has joined #exult
[00:55:46] --- ChanServ gives channel operator status to DominusExult
[00:58:45] <-- Dominus has left IRC (Ping timeout: 255 seconds)
[00:58:45] --- DominusExult is now known as Dominus
[01:10:35] --> Marzo has joined #exult
[02:42:34] <-- Marzo has left IRC (Ping timeout: 255 seconds)
[04:32:13] <sh4rm4> <Marzo> wjp: I am thinking of 'porting' the files/tools still in plain C to C++
[04:32:30] <sh4rm4> why ? so that it compiles "faster" ?
[04:33:20] <sh4rm4> i'd do it the other way round
[04:34:21] <sh4rm4> it's kinda sad seeing all these C++ zealots ruining good C projects
[04:34:29] <sh4rm4> MAME went that route, now even GCC
[04:38:49] <sh4rm4> i published my latest project under a special license that forbids to convert it to C++
[07:09:08] <-- Dominus has left IRC (Read error: Connection reset by peer)
[07:09:50] --> Dominus has joined #exult
[07:09:50] --- ChanServ gives channel operator status to Dominus
[10:04:19] <wjp> sh4rm4: and then you call other people zealots?
[10:11:33] <sh4rm4> :D
[10:16:00] <sh4rm4> https://lwn.net/Articles/249460/
[10:16:44] <sh4rm4> these guys show up in almost any C project, and sometimes they succeed
[10:18:17] <-- Dominus has left IRC (Read error: Connection reset by peer)
[10:18:35] --> Dominus has joined #exult
[10:18:35] --- ChanServ gives channel operator status to Dominus
[11:01:50] <wjp> Please keep your crusades out of this
[11:56:00] --> Marzo has joined #exult
[12:06:29] <Dominus> btw...
[12:06:35] <Dominus> happy new year
[12:06:46] <Dominus> I have the feeling we will release something this year :)
[13:00:00] <sh4rm4> happy new year
[13:04:33] <-- Kirben has left IRC ()
[14:31:43] --> i30817 has joined #exult
[14:32:57] <i30817> Those speech recognition api's are interresting.
[14:32:58] <i30817> The latest and best are all online. The data requirements for them must be huge, and to get more data they make it a point to 'phone back' the requests, so they can improve the model.
[14:33:49] <i30817> I was hoping i could 'extract' a list of words data for recognition from their terabytes (the word list being ultima 7 responses)
[14:34:03] <i30817> But not one of the allows that.
[14:34:07] <i30817> Oh well.
[14:35:12] <i30817> Not going to upload flacs every time a conversation happens.
[14:36:52] <i30817> This idea was inspired by a complaint that ultima 7 ruined the need to pay attention to conversations by deprecating the parser. I thought 'if we could hide the responses, the parser feeling would be back'.
[14:50:37] <sh4rm4> deprecating the parser ?
[14:59:54] <Dominus> i30817: re:canons, please don't clutter bug reports with unrelated stuff. file an extra feature request in the Feature Request Tracker with something like "BG Keyring: multi direction canons" or so
[15:04:07] <i30817> sh54rm4: in ultima 6 and earlier; you typed responses from keywords on conversations;
[15:04:08] <i30817> U7 has the same system almost; expect now you can't type words, they are selected, and it's a implicit tree.
[15:04:10] <i30817> But hiding the 'feedback' so you have to _read_ the responses should still be possible. Actually i thought of voice recognition because a keyword system seems to be made to work with it; single words to recognize, low data.
[15:06:03] <i30817> Actually, it's not a tree in general, since you can almost always roll back to the beginning by asking 'job' or 'name'
[15:09:23] <i30817> Dominus: done
[15:11:20] <Dominus> i30817: thanks
[15:11:35] <Dominus> have you contacted munt/sergm about the changed mt32lib stuff?
[15:11:59] <i30817> Ehhh, i thought about it and he can't do much i think.
[15:13:16] <i30817> I think it might be possible by hooking up into the dosbox api that finds out the location of the conf file but...
[15:14:15] <i30817> it seems really complicated and not really public from the snooping around i did on the hope of adding a patch to the patch.
[15:14:50] <i30817> Currently in my patch it's hardcoded to linux '~/.dosbox'
[15:15:01] <i30817> since the ppa is only for ubuntu anyway.
[15:15:41] <i30817> Other alternatives is to search for a 'default' place first for the roms.
[15:16:14] <i30817> so that each program that uses the api doesn't have to copy the files everywhere on the file tree.
[15:17:12] <i30817> However it better be a user writable folder. 'Sharing' mt32 roms is probably a bad thing, even if only for reading.
[15:17:41] <i30817> (and would complicate the already complicated installation of exult)
[15:18:10] <i30817> (by requesting the location of the roms in addition to the location of the games)
[15:26:00] <i30817> What i do in my java programs is to find the home dir (different in each version of windows it seems) and plop down a .config/programname dir there (the linux way).
[15:26:48] <i30817> windows explorer recognizes that .dir is supposed to be a hidden directory, even if the flag is not set (but it can be set in java 7+)
[15:30:03] <Dominus> I think the one default folder on all OS would be much better approach on sergms side. just using the home folder is messy IMO
[15:38:27] <i30817> He is not using the home dir.
[15:38:28] <i30817> It's the "current dir", which is variable and can even not be the same dir the shell is in (if you're in a shell).
[15:38:30] <i30817> eg: $~: /bin/cat fileindir
[15:38:31] <i30817> the 'current dir' is for the program is ~, even thou it's location is /bin
[15:38:50] <i30817> Actually : always the same dir the shell is in
[15:38:57] <i30817> Not the same dir the program is in.
[15:39:23] <Dominus> I understand. more messy
[15:39:41] <i30817> the default folder on all OS necessally uses home as parent.
[15:40:00] <i30817> Because all OS only have the 'home' concept shared.
[15:40:48] <Dominus> then one can make it dependent on the OS and not one setting for all os :)
[15:40:55] <Dominus> same as Exult :)
[15:40:55] <i30817> unless you want to dump the roms in program location (which wouldn't work anyway, for the reason above)
[15:42:14] <i30817> or better to say - wouldn't work without additional effort, because you can't just say fopen("ROM_FILE"); lalalala
[15:42:35] <Dominus> but, well if you can patch it, no problem? official dosbox patch -> your patch
[15:43:37] <i30817> yes but if i patch his patch it's highly likely it will break when he updates it; since i merging HIS patch into the ppa build and only then patching on top of the changes it does.
[15:44:27] <i30817> i wanted it like this so that when he updates the api, he also does the work of updating the mt32 patch
[15:44:30] <i30817> <- lazy
[15:44:47] <Dominus> :)
[15:44:53] <sh4rm4> <i30817> What i do in my java programs is to find the home dir (different in each version of windows it seems)
[15:45:03] <sh4rm4> it's %USERPROFILE% everywhere
[15:45:25] <Dominus> yeah but the actual location of this varies quite a bit :)
[15:45:29] <i30817> different in 'reality', just not in code.
[15:46:28] <sh4rm4> well, it's different "in reality" on any linux system either
[15:46:46] <sh4rm4> /home/luke /home/fred, ...
[15:47:00] <Dominus> but it is still /home/username
[15:47:23] <Dominus> on Windows it can be /Windows/username (Win95, 98)
[15:47:40] <Dominus> and other places later on...
[15:47:47] <sh4rm4> yes, and in windows it's C:\[translation of documents & settings]\username
[15:48:14] <Dominus> pre Visat
[15:48:19] <Dominus> pre Vista
[15:48:33] <sh4rm4> it's like that for 2000/XP as well
[15:48:50] <Dominus> yes but it changed in Vista again
[15:48:54] <sh4rm4> iirc win98 had "C:\Eigene Dateien"
[15:49:24] <i30817> For instance here is what i do now (hope it's ok to dump a bit of code here)
[15:49:25] <i30817> http://nopaste.info/17651eb19e.html
[15:49:28] <i30817> And every thing in the program that want's to write to the filesystem uses the derived path as parent afterwards
[15:49:28] <i30817> So it checks 'is there a local dir to write in the program location ? No? Try the in home? Not writable? Fallback to tmp'
[15:49:52] <Dominus> so you see quite confusing on Windows if you want to point people there
[15:50:58] <sh4rm4> i tell them: press WIN-R and enter %USERPROFILE%
[15:51:03] <sh4rm4> that works everywhere
[15:55:27] <Dominus> then there is the question whether that is the right location
[15:55:37] <Dominus> APPDATA seems more like it
[15:59:51] <sh4rm4> it's usually "right enough", and if it isnt writable there's something terribly wrong anyway. so you're not to blame if a write fails
[16:00:54] <sh4rm4> writing to %TEMP% is not really a sane alternative, because it'll be deleted regularly on system startup in corporate environments
[16:02:11] <sh4rm4> anyway, i'm luckily done with windows *shrug*
[16:06:36] <i30817> It's what there is if everything else fails.
[16:15:08] <i30817> strange. I refreshed the main page of the the Feature Requests section on sourceforge and it duplicated my feature request
[16:17:41] <-- sh4rm4 has left IRC (Remote host closed the connection)
[16:19:02] --> sh4rm4 has joined #exult
[16:41:41] <-- i30817 has left IRC (Remote host closed the connection)
[18:43:40] <Dominus> hmm, that sleeping in beds bug from agentorangeguy is annoying. In BG the Avatar goes to bed after a while in SI he never goes to bed
[18:44:10] <Dominus> nice to watch with OpenGL enabled since that doesn't fade :)
[18:44:36] <Dominus> I wonder what happens with Malignants fade bug when using OpenGL scaler :)
[18:49:30] <Eviltar> actually i30817, in the fm-towns Ultima 6 you could click to select resposnses also http://www.hardcoregaming101.net/ultima/Ultima%20VI%20The%20False%20Prophet/ultima6%20-%20FMTOWNS%20-%2001.png
[18:50:46] <Eviltar> I wish it was like that in all the other ports as well, with voice acting even
[18:57:43] <Marzo> After a lot of work, I found out the real reason behind all the ordering issues: the fact that Exult allows objects whose graphics intersect on-screen to be unsorted relative to one another
[18:58:26] <Marzo> So all I ever needed to tackle was the cases where Exult returns zero
[20:08:55] --> Malignant_Manor has joined #exult
[20:09:41] <Malignant_Manor> Dominus: The OpenGL bug is is blue on the tracker.
[20:14:36] <Malignant_Manor> Marzo, Do you remember the lighting inaccuracies? http://exult.sourceforge.net/forum/read.php?f=1&i=328418
[20:14:48] <Marzo> I do now
[20:15:08] <Marzo> Link broken
[20:15:23] <Malignant_Manor> http://exult.sourceforge.net/forum/read.php?f=1&i=328417&t=201436
[20:16:23] <Malignant_Manor> I tried to link with the message reply link and accidentally removed the last part.
[20:17:03] <Malignant_Manor> The post I linked to was yours on the second to last but there are more relevant posts.
[20:18:14] <Malignant_Manor> I'm not sure if this should wait until after release or not.
[20:19:30] <Malignant_Manor> I noticed that ranged combatants do still run to point blank range sometimes.
[20:22:47] --> i30817 has joined #exult
[20:24:49] <i30817> Eviltar: maybe the keywords are the better interface, but the guy had a point you don't even need to read or understand the U7 dialogs anymore (especially if you already played it).
[20:24:50] <i30817> I'd want to have this as a alternate.
[20:24:52] <i30817>
[20:24:53] <i30817> Plus i'd feel like a real dorkmaster whispering 'job' and 'name' to my computer into the night.
[20:26:17] <i30817> And it seems like a good fit for the android port too.
[20:29:37] <i30817> though the game has bigger problems than conversations on a small screen... like the dragging an clicking.
[20:34:27] <i30817> Still. The one feature i really want to have is ToEE-like combat... ooohhh.
[20:34:28] <i30817> Never going to happen ofcourse.
[20:35:20] <Malignant_Manor> Eviltar, Nuvie adds click-able conversations, but it still needs some manually input for quite a few things. The game did not keep track of data and Nuvie can only use highlighted words that were revealed in the current conversation plus some presets (Name, job, bye, leave).
[21:18:41] <Dominus> Malignant_Manor: yes, I know that the opengl bug has been reported. I think it was me who labeled it down to blue :)
[21:19:02] <Dominus> It was just fun exploiting that bug to watch the avatar in his sleep
[21:19:13] <Malignant_Manor> You said you couldn't find it.
[21:19:13] <Dominus> OpenGL=Peeping Tom mode
[21:19:31] <Dominus> you must have misread something I wrote :)
[21:19:57] <Malignant_Manor> I wonder what happens with Malignants fade bug when using OpenGL scaler
[21:20:09] <Malignant_Manor> seems like you couldn't find it
[21:20:33] <Dominus> nope
[21:21:06] <Dominus> I was just asking myself what would happen if one uses OpenGL scaler when trying that fade-in bug you reported
[21:21:18] <Dominus> that you and marzo debugged last night
[21:22:09] <Malignant_Manor> You would see the npcs quake.
[21:22:37] <Dominus> does it stop or just endlessly quake?
[21:23:17] <Malignant_Manor> It stops but Exult stops running the script that turns the lights back on.
[21:25:58] <Malignant_Manor> The problem is trying to fix this for all possible cases, which could be many. We could easily delete the egg that causes this instance and no one would even notice the difference.
[21:27:09] <Dominus> yes, I understood that. If you hadn't noticed this somewhere else that would be a way
[21:27:34] <Malignant_Manor> I'm pretty sure I have noticed it elsewhere.
[21:28:08] <Dominus> I believe you
[21:28:53] <Malignant_Manor> I just can't remember a specific trigger area.
[22:24:20] <-- sh4rm4 has left IRC (Remote host closed the connection)
[22:29:45] <Dominus> hmm, nice, next automake will break break and break things
[22:30:53] <Dominus> other projects by removing configure.in support but our stuff will break too
[22:38:20] <Dominus> hmm, when did we break cannons?
[22:43:33] <Dominus> hmm, if it ever worked then we have broken it ages ago
[22:44:03] <Dominus> it's broken in my first snapshot I kept from april 2010
[22:45:02] <Dominus> I volunteer Marzo since he is the last to mention cannons in the changelog
[22:45:21] <Dominus> "'fire_cannon' intrinsic renamed to 'fire_projectile'; unknown parameters
[22:45:21] <Dominus> have been decoded and implemented. Also, this intrinsic is confirmed to
[22:45:21] <Dominus> be present in SI as intrinsic 0x8C."
[22:45:33] <Dominus> 2007-10-13
[22:45:58] --> Kirben has joined #exult
[22:45:59] --- ChanServ gives channel operator status to Kirben
[22:54:00] <Malignant_Manor> Some problems with the sleeping seem to be caused by setting the Avatar's schedule to sleep before the bed is set.
[22:54:56] <Dominus> that sounds strange
[22:55:19] <Malignant_Manor> If there isn't a bed, the schedule will find its own.
[22:56:59] <Dominus> hmm, in SI it seems to happen with set beds as well, not to mention all other kind of means to sleep
[22:57:25] <Malignant_Manor> I've only looked at BG.
[22:58:30] <Dominus> I skipped looking at BG since it seemed to work ok for me :)
[22:59:27] <Malignant_Manor> I'm looking at BG choosing the wrong bed to go to.
[23:00:06] <Dominus> ah that
[23:01:42] <Malignant_Manor> Setting the bed in the intrinsic before setting sleep schedule didn't work.
[23:06:14] <-- Marzo has left IRC (Ping timeout: 252 seconds)
[23:35:30] <-- Malignant_Manor has left IRC (Read error: Connection timed out)
[23:38:56] --> Malignant_Manor has joined #exult
[23:43:42] <Malignant_Manor> I fixed the bed detection, but for some reason, Wait_for_arrival doesn't actually wait until the Avatar goes to the bed or the 5 second setting.