#nuvie@irc.freenode.net logs for 6 Aug 2006 (GMT)

Archive Today Yesterday Tomorrow
Nuvie homepage

[00:00:52] <SB-X> I like luteijns idea of low-level spell functions, but we also have to use some spells as monster abilities. (or potion effects) We don't want to have to duplicate the script code for slightly different situations, so maybe we can use the spell functions as normal actor attacks.
[00:01:24] <Yuv422> I was thinking along those lines too
[00:01:25] <SB-X> for example wisps teleport and spiders throw webs, and those effects are exactly the same as teleport and web
[00:01:33] <Yuv422> actors get given spells
[00:01:34] <SB-X> but they dont use mp
[00:01:54] <Yuv422> I think they get effect objects
[00:02:11] <SB-X> i know from researching them that tangle vines get them :)
[00:02:15] <SB-X> sleep charges
[00:02:22] <Yuv422> which are monster spells
[00:02:41] <SB-X> that's cool... so they use those like weapons
[00:02:43] <SB-X> similiar to u7
[00:03:07] <Yuv422> I think so
[00:03:09] <SB-X> you shouldn't see them in inventory (with pickpocket)
[00:03:13] <SB-X> but they are there
[00:03:17] <Yuv422> well I didn't look too closely at the time
[00:03:22] <SB-X> hehe
[00:03:25] <SB-X> me neither
[00:03:34] <SB-X> and mages actually do cast spells, which cost mp
[00:03:35] <Yuv422> maybe it's time to revisit
[00:04:09] <SB-X> im mostly going from the old docs so i'll need to look into the actual inventories too
[00:07:08] <Yuv422> I'm going out now
[00:07:14] <SB-X> hmm ok
[00:07:26] <SB-X> see you later
[00:07:30] <Yuv422> cya
[00:07:45] <-- Yuv422 has left IRC ()
[00:08:56] <SB-X> Maybe it was just in the SNES version but I distinctly remember the "Not enough MP." message being printed occasionally in battle when none of my party was attacking. I figured out that it was enemy mages or monsters trying to cast.
[04:56:03] <luteijn> see these two log pages about earlier research into eclipse (and magic storm), one is 3 years old, from just before Yuv's skiing trip, and the other about 1.5 years ago (also just before a trip, and an abandoned release plan): http://www.math.leidenuniv.nl/~wpalenst/nuvielog.php?log=5Mar2005 http://www.math.leidenuniv.nl/~wpalenst/nuvielog.php?log=18Jul2003
[04:57:34] <luteijn> See also the 'old docs' in the phorum, that have spell durations in them for some spells. (e.g. 10 minutes, 20 turns etc. 20 turns seems to match the 0x13 found by Yuv (off by one, maybe because of when it is checked/decremented?)
[04:59:49] <luteijn> I have a memory of a 'naturally' occuring eclipse in U6, maybe near the end of the first year (as SB-X set month to 0 made it eclipse, it might be once a year)
[05:20:51] <luteijn> Also, I've been playing a bit with map wrapping, inserting &(level?1023:255) at various places where it didn't wrap properly, and on my local copy I can fly around the world in all directions without crashing nuvie. However, the map display on edges/corners still isn't right, it should also wrap. I'll try to work on it some more later.
[06:31:49] <-- Kirben has left IRC ("System Meltdown")
[06:34:30] --> Kirben has joined #nuvie
[07:29:37] <SB-X> luteijn: my god, I don't remember those conversations at all
[07:29:42] <SB-X> we've been working on Nuvie way too long
[07:30:01] <SB-X> i vaguely remember seeing the eclipse now that you mention it
[07:32:28] <servus> You should start replacing logical numeric version numbers for Nuvie with confusing nonsense names like "Dapper", "Sarge", or "Sid" that evade making sense to people. That, and the fact that the last comment on Nuvie.sf.net is from 2005 makes the project look a lot more dead than being in this channel would lead one to believe :)
[07:32:38] <servus> I was kidding about the first part.
[07:32:54] <SB-X> I like the first part better than the second.
[07:33:25] <servus> Please don't do that.
[07:41:51] <servus> Hmm, combat seems to work in Nuvie now, with a few bugs :)
[07:42:09] <servus> Well, more unimplemented features than bugs. The fireplace instead of a moon in my calendar is a bug *grin*
[07:44:29] <SB-X> servus: when you have time can you look at why actor lighting isn't working in mapwindow?
[07:45:09] <SB-X> i dont know how the ambient lighting engine works so I can't fix it, but as far as I can tell the light around actors is requested the same as light around objects
[07:45:50] <SB-X> it displays lightglobes fine with original lighting, but not with smooth lighting
[07:47:15] <servus> Sure, let me cvs up. Do you mean held torches?
[07:47:37] <SB-X> yes, that's currently the only thing that creates light on an actor
[07:47:48] <SB-X> MapWindow.cpp:643
[07:49:32] <servus> Did I write the original lighting? I can't remember
[07:49:59] <SB-X> yes
[07:50:30] <servus> Soon as I can remember my sourceforge password... :)
[08:04:05] <servus> Hmm, which version of automake is used for this? I'm having problems...
[08:07:57] <SB-X> whichever is the newest should work
[08:08:09] <SB-X> it didnt work with the version in ubuntu breezy so i upgraded
[08:08:28] <SB-X> upgraded automake
[08:09:01] <servus> I'm on automake1.9... I'll tell ya when I get it to work
[08:09:39] <luteijn> hmm when testing around with baloon, I got more/less light whenever I picked something up/ dropped something..
[08:10:16] <SB-X> with smooth lighting?
[08:10:32] <luteijn> with smooth lighting. let me see if I can duplicate it now..
[08:11:24] <SB-X> I know the lighting method is wrong for torches, as it wont allow for multiple lit objects or spell effects, but other objects shouldn't add light.
[08:11:47] <SB-X> servus: you need autoconf too
[08:12:02] <servus> I know. I have it. I think it's some strange Debian problem. Almost there :)
[08:12:05] <SB-X> and there is an autogen.sh script to run first
[08:12:07] <SB-X> ok
[08:12:18] <servus> apt-get remove autoconf: Wants to uninstall Apache. Grr @ Debian.
[08:15:04] <luteijn> http://luteijn.xs4all.nl/~luteijn/nuvieU6003.sav
[08:15:44] <luteijn> e.g. drop the key or the boomerang, and get them a few times to see the effect. (the other objects might be ill-gotten...)
[08:17:23] <servus> There we go. apt-get forgot to ln -s /usr/bin/aclocal-1.9 /usr/bin/aclocal
[08:23:29] <servus> For Linux, do you think you should put in some sort of case-insensitive fopen wrapper, or default to uppercase filenames?
[08:24:24] <SB-X> we have a tool to convert U6 filenames to lowercase
[08:25:03] <SB-X> it's not a priority right now
[08:26:29] <SB-X> does debian have update-alternatives?
[08:27:47] <luteijn> mine seems to have
[08:30:42] <luteijn> There's many places where coordinates need to be 'wrapped' with &(z?255:1023), maybe the 'wrap_coords' function should be a little bit more accessible than 'protected' in Map? Or is that just my non-object-oriented way of thinking?
[08:30:47] <servus> Is there a quick way to set the time?
[08:31:31] <luteijn> rest
[08:31:34] <SB-X> luteijn: there should be a Map::get_pitch() or get_width() at least, which you'd use in other classes
[08:31:49] <SB-X> yeah rest works :)
[08:32:08] <SB-X> i dont know if wrap_coords should be protected... i just made it that way because nothing else needed it at the time
[08:32:15] <SB-X> and I wanted it to be inline
[08:32:25] <servus> But I can't use a bed! Oh I'll have to go out to the wilderness, blah :p
[08:32:38] <SB-X> alt-215
[08:32:57] <servus> Thanks, now ya tell me :P
[08:33:09] <servus> Do you know about the fireplace-as-a-moon bug?
[08:33:16] <SB-X> nope
[08:33:27] <SB-X> there are a few places with fireplaces where there should be something else
[08:33:50] <servus> At precisely 10PM, the little moon over the party name (that moves around) becomes a random fireplace frame
[08:34:05] <SB-X> wierd
[08:34:35] <servus> Happens on both Linux and Windows, newest snapshots
[08:34:50] <servus> Looking for a torch now... or the objlist :)
[08:35:03] <SB-X> i get a crash in windows at 9pm
[08:35:17] <SB-X> with a recent snapshot
[08:38:37] <luteijn> I think iolo starts out with torches.
[08:38:55] <luteijn> that savegame I linked to earlier is at night and torces are available ;)
[08:38:57] <servus> When a party member holds a lit torch, he lights up fine in smooth mode for me.
[08:39:15] <SB-X> interesting
[08:39:16] <servus> I go into solo mode with someone not carrying a torch and the torch-bearer remains all lit up
[08:39:40] <SB-X> it didnt work for eric
[08:39:47] <servus> I held a torch as Avatar, and solo'd to Dupre and slunk away. But dupre and Avatar have globes around them (Dupre just because he's the active char). It works in both Smooth and Original.
[08:40:06] <servus> I suppose I could try on OSX, but I really don't see what difference that'd make :)
[08:40:30] <SB-X> it didnt work for me either
[08:40:39] <SB-X> trying on windows now
[08:40:52] <servus> Ahh I see
[08:41:04] <luteijn> hmm If I make iolo wear a torch, he doesn't light up, no matter if I switch to a different character.
[08:41:09] <servus> When I light a torch, as a solo, the globe actually becomes smaller
[08:41:43] <SB-X> no lighting for me in windows snapshot either
[08:41:59] <servus> And now it no longer works
[08:42:26] <luteijn> also dropping/getting influences it, Iolo lit up after I dropped some reamining torches.
[08:42:28] <SB-X> be sure to reload or restart nuvie to test again
[08:42:39] <SB-X> really
[08:44:05] <luteijn> can't get avatar to light up
[08:44:49] <servus> Strange. Very touchy. There are different sorts of problems in both original and smooth mode
[08:45:51] <SB-X> sounds like an uninitialized variable?
[08:46:45] <SB-X> you cant rely on torch light to be consistent across getting, lighting, and dropping torches, but that's a different issue to whether they ever create a lightglobe
[08:47:55] <luteijn> eventually avatar and LB have lit up after dropping objects from them an d swapping around to different characters, appears something doesn't get updated proberly until you trigger it... I never dropped/got any lit torches just now, only other objects, like snake amulets kite shields and gargish scrolls.
[08:48:16] <servus> When solo Dupre picks up an unlit torch, he lights up, and when he lights/readies it, he stops lighting up, but he continues to actually call the globe-drawing function, regardless of whether he is active.
[08:48:33] <servus> Oh well, I won't bother you with it 'til I find out what's wrong :)
[08:50:18] <SB-X> I tried to make sure it was actually updating actor::light level before figuring it was a lighting bug.
[08:51:15] <SB-X> maybe it has to do with video gamma level and mine isn't as bright as either of yours
[08:51:27] <SB-X> so I don't see the lightglobe
[08:52:41] <servus> Nah, it's definitely getting called, but just not doing anything. Maybe draw-order problems or something funny. The fact that it starts calling it just for _picking up_ a torch is another problem entirely. Do you happen to have a link to a list of spam object codes handy? I want the torch code.
[08:53:00] <servus> (Never mind found one)
[08:53:18] <SB-X> be sure to check what level it's being called with
[08:54:20] <luteijn> cvs co docs
[08:55:05] <SB-X> it probably starts calling it because it adds light to the actor without checking that the torch is lit... but that's not a problem if it's actually making a lightglobe
[08:55:14] <SB-X> that's not what I'm complaining about :)
[08:55:49] <SB-X> the problem is when there isn't light after using an unlit torch from inventory
[08:55:50] <luteijn> actually picking up/dropping random objects seems to toggle lighting code. e.g. my castle british key, boomerang etc.
[08:56:21] <SB-X> handling non-torch objects shouldnt affect it either so that may be part of the same problem
[08:57:15] <servus> Do you not need to hold a torch in your hand for it to be illuminating?
[08:57:40] <servus> Was there lighting code at all before I started fussing with it?
[08:57:50] <SB-X> it's possibly allowed in some cases now but you're supposed to be holding it
[08:57:52] <SB-X> nope
[08:57:58] <servus> OK, taking a look :)
[08:59:08] <servus> Ah weird. Dupre-Solo picks up an unlit torch and starts a globe of "3", then he lights it and puts it in his hand to make an invisible globe of "5".
[09:00:20] <SB-X> the level is clamped to 5 in mapwindow, and I know that theres probably a bug in use_torch that causes the unlit torch to create light, but why is there an invisible globe of 5? why isn't it visible?
[09:01:11] <servus> Yeah, 5 is an invalid globe size, if you clamp it to 3, it works fine
[09:01:19] <SB-X> it's valid for original
[09:01:23] <servus> But there's the problem of lighting up for simple picking things up
[09:01:54] <SB-X> i doubt i even check whether the torch is lit or not when picking it up
[09:02:00] <SB-X> its only a problem if it does so for other objects
[09:02:25] <servus> But surely holding an unlit stick of wood in your backpack shouldn't cast light :)
[09:02:50] <SB-X> it will when it catches your backpack in flames
[09:02:59] <SB-X> if you try to light it
[09:03:03] <SB-X> anyway i'll fix that later
[09:03:08] <servus> Hehe, ok :)
[09:03:31] <SB-X> why does 5 work in original lighting mode?
[09:03:37] <SB-X> and not in smooth
[09:04:29] <servus> No clue, fixing that now. Original has 5, smooth has 3.
[09:04:56] <servus> I mean, original has 6, smooth has 3.
[09:05:08] <SB-X> ok
[09:05:46] <SB-X> instead of limiting the light level in mapwindow, i will add a warning printf if it goes over 3 or 5
[09:05:53] <SB-X> or 6
[09:06:30] <SB-X> to remind me to fix whatever's causing extra light
[09:06:32] <servus> I shouldn't clamp?
[09:06:40] <SB-X> not in mapwindow
[09:06:44] <servus> OK. It should never go over 5 though if original doesn't support it
[09:06:52] <SB-X> you said 6
[09:07:16] <SB-X> well youll have to limit it if it causes problems
[09:07:22] <SB-X> like invisible lightglobes
[09:07:40] <SB-X> but better to do that in screen where the rest of the lighting is done
[09:07:51] <servus> 6 values, valid range of 0-5.
[09:08:08] <SB-X> oh, ok
[09:08:25] <SB-X> so smooth will be the same
[09:09:09] <SB-X> i'm already planning to change actor lighting to use a list of light levels in addition to the light variable
[09:09:45] <servus> Yeah, the difference between smooth and original should be completely transparent everywhere except inside the actual low-level globe drawer.
[09:11:22] <servus> And I do actually clamp the globe size to 5 in the renderer, so you don't need to clamp it anywhere else.
[09:11:31] <SB-X> ah k
[09:20:39] <servus> There we go, problem #1 solved :). Did you want me to fix why it's lighting up just for picking up objects? luteijn's comment about lighting up on picking up garbage like keys?
[09:21:36] <servus> Ohh that's bizarre. When the avatar holds a lit torch, he generates a globe of 4, but when Dupre does it, he makes a "5" globe.
[09:21:45] <luteijn> if you can relatively easily see why it's doing that..
[09:30:25] <servus> Actually, I don't see one place that Actor::light is ever even modified. Looking...
[09:35:25] <luteijn> hmm can't figure out how to move a spell into a spellbook in nuvie.
[09:36:27] <SB-X> you cant
[09:36:45] <luteijn> bleh.
[09:37:11] <servus> SB-X: Where is actor->light ever updated? I rgrepped for "->light" and "\.light" and only came up with that area in MapWindow.cpp
[09:37:26] <SB-X> Actor::add_light
[09:37:53] <luteijn> some files are in subdirectories. did you include them in the grep?
[09:38:02] <servus> Oh I see.
[09:38:11] <servus> Yes, I just searched for \<light\> after saying that...
[09:38:30] <SB-X> U6UseCode::torch is the only place that should be adding light
[09:39:22] <servus> Noope, check inventory_add_object
[09:39:37] <SB-X> oh right, if it's lit flag is set
[09:39:38] <servus> That's where the (3) globe comes from!
[09:39:48] <SB-X> so I've got the lit flag wrong
[09:39:52] <servus> Maybe it's not a "lit" flag but "lightable" flag?
[09:40:04] <SB-X> keys?
[09:40:31] <SB-X> or that wouldn't make sense on keys i should say
[09:41:30] <servus> Why do it at all?
[09:41:39] <servus> When does just picking up an object *ever* light you up?
[09:41:45] <SB-X> if it's a lit torch
[09:42:03] <SB-X> inventory_add_object is also called when the game is loaded and actor inventories are created
[09:42:36] <SB-X> it should probably check, besides that flag, the frame_n or obj_n
[09:42:59] <luteijn> but then you add more hardcoded things ;(
[09:43:10] <servus> OK, but picking up an unlit torch puts it in my pack, and picking up a lit torch puts it in my hand, so clearly they are being handled differently elsewhere, and that's where the add_light should go, right?
[09:44:02] <servus> ohhh silly!
[09:44:03] <SB-X> yeah there shouldnt be an add_light when getting a torch in usecode because it's already in inventory_add_object
[09:44:08] <servus> if(obj->status |= OBJ_STATUS_LIT)
[09:44:09] <SB-X> thanks for tracking it down, i'll fix that one later
[09:44:10] * servus giggles
[09:44:13] <SB-X> lol
[09:44:25] <SB-X> sorry
[09:45:18] <SB-X> here luteijn thought we'd have to hardcode more magic numbers and it was just me forgetting how to use bitwise operators properly
[09:45:22] <SB-X> whew :p
[09:45:51] <SB-X> maybe i copy/pasted that from the line that was supposed to set it without thinking
[09:46:20] <servus> The problem still occurs though, unless I need to start a new game...
[09:46:43] <servus> Whoooa I started drawing a "7" globe there for a while.
[09:46:43] <SB-X> you may, but like i said earlier its probably still adding light twice
[09:46:57] <SB-X> i can fix that later
[09:47:53] <servus> When in combat mode, and I hit attack, it should auto-target the last guy I attacked.
[09:49:14] * luteijn reads back a bit, snickers at |= bug.
[09:49:17] <servus> Yes, things are looking decidely less silly now.
[09:49:26] * SB-X looks embarrassed.
[09:49:40] <servus> Well, I forgot to match 3 vs 6 globe levels, so that's an even bigger blunder.
[09:49:59] <servus> Want a patch? :) I don't have cvs write access.
[09:50:07] <SB-X> meh
[09:50:09] <SB-X> ok
[09:50:31] <SB-X> thanks for fixing those bugs
[09:51:49] <servus> More bugtesting and globe-size-tweaking is in order... and I'll be happy to work more on Nuvie if you have some specific tasks in mind. Do I need cvs write access?
[09:52:04] <SB-X> maybe
[09:52:39] <SB-X> i dont have any other specific tasks in mind
[09:53:22] <SB-X> but if you do then you'll need write access if you don't want to continue submitting patches
[09:54:18] <servus> Does Eric need to be the one to give me write access?
[09:54:25] <SB-X> yes
[09:54:30] <servus> If you guys don't want to, I can live with patches
[09:54:39] <servus> Just don't claim credit for my bugs! *grin*
[09:54:40] <SB-X> i'm just another player here
[09:55:02] <SB-X> np
[09:55:07] <SB-X> you can have my bugs too if you like
[09:56:25] <servus> I already had your bug
[09:57:20] <servus> I am doing unit testing on the globes, I'll be done soon. Nothing else I can work on without screwing up something that is in-the-works?
[09:57:50] <SB-X> you can write magic spell scripts
[09:58:06] <luteijn> but probably we need to extend the magic system a little first..
[09:58:21] <SB-X> oh yeah
[09:58:23] <luteijn> add a way to nicely select a target, and get input from the scroll.
[09:58:49] <luteijn> those are things I didn't do because I kept running into things that were hidden away in classes.. ;(
[10:00:05] <SB-X> it needs get_direction(), get_npc(), get_target(), and the latter two should both return the location and the targetable object or actor at that location
[10:00:32] <SB-X> you can cast any spell that doesnt take a direction on an actor or object or empty square
[10:00:55] <SB-X> i'll probably add those soon
[10:01:05] <SB-X> not sure what to return
[10:01:39] <luteijn> e.g. earthquake (do we need an effect for that?), armageddon (does that affect those actors? like minax in the original) etc.
[10:02:01] <SB-X> "those actors?"
[10:02:32] <luteijn> well actors with a question mark as we're not sure they were real actors, since the schedule issues they have..
[10:02:49] <SB-X> im pretty sure they arent, so I posted a bugtracker item about it ;)
[10:03:56] <SB-X> are you sure you'd rather do that by gluing together low-level function in the script, instead of just calling delete_all_actors? :)
[10:05:51] <luteijn> well original idea would be to iterate over all actors and 'kill' them.. but initially it can be a highlevel script ;)
[10:11:42] <SB-X> well I just made up that function name, so you might as well implement it with the list of actors in the script
[10:12:07] <SB-X> there is no way to kill actors and delete their body yet
[10:20:30] <luteijn> hmm I thought your delete_all_actors sounded familiar, and actually there's a 'clean' function in ActorManager that has "//delete all actors"
[10:21:16] <SB-X> oh, i didnt know that
[10:21:25] <SB-X> it wont drop their inventories though
[10:24:16] <servus> OK, added some general lighting bugfixes and tried to sync the smooth and original lighting up a bit better. How do you want your patch, SB-X?
[10:24:38] <SB-X> can you submit it to the patch tracker?
[10:24:55] <servus> I have no idea. I'll take a look
[10:25:08] <SB-X> thank you
[10:25:48] <SB-X> im not using linux right now and cant commit the patch to cvs yet
[10:26:46] <servus> Do you want a windiff patch?
[10:26:59] <SB-X> no
[10:27:28] <luteijn> I've made a bit of a mess from my local copy, putting those wrapping things in everywhere, need to redo that properly anyway. I can probably just drop my changes, and merge servus' stuff in instead.
[10:28:05] <servus> Hm, what's the preferred format for this patch tracker?
[10:29:05] <SB-X> not sure, that depends on whoever's doing the patching
[10:29:09] <SB-X> ask luteijn
[10:29:15] <luteijn> why does Actor::move use signed integers?
[10:29:15] <wjp> diff -u is usually best
[10:29:36] <luteijn> unified diff would probably work.
[10:29:37] <SB-X> that'll work
[10:29:40] <SB-X> :)
[10:32:25] <SB-X> luteijn: i dont know, but im hoping as long as uint16 is used everywhere for coords, the only wrapping functions need to be used from map, actormanager, and objmanager (and wherever a local mapbuffer or loop over coords is used)
[10:36:04] <servus> Actually... instead of magically setting brightness to 3 for picking up a lit torch, can't I pull the proper value from somewhere? *Looks*
[10:39:17] <servus> U6UseCode.cpp has #define TORCH_LIGHT_LEVEL 4... looks like a no, but I should at least make them match up.
[10:40:26] <servus> I am moving that #define to U6UseCode.h and using it in Actor.cpp
[10:40:34] <servus> Is that OK?
[10:43:58] <luteijn> sounds ok to me, altough maybe it needs to be in U6Actor somehow, as it (might be) game specific?
[10:45:12] <servus> Actor.cpp #includes U6UseCode.h so it's all fine
[10:46:11] <servus> Well, not the game-specific part. There are more problems I'm finding with how the Actor.cpp inventory_parse_readied_objects function handles picking up lit torches, especially if your hands are full. Permanent invisible torch:)
[10:47:32] <luteijn> A lot of the inventory related things seem to be fragile.. I think improvements are welcome :)
[10:47:58] <servus> Working on it :) I've managed to get my permanent light level over 20
[10:49:57] <SB-X> my new light list on actors will prevent multiple light sources of the same value from adding more light
[10:50:51] <servus> Should I stop fussing with this particular part, then, so as not to get this work clobbered?
[10:51:12] <SB-X> I don't know what you're doing.
[10:52:55] <SB-X> the only related functions im going to change are Actor::add_light, subtract_light, and U6UseCode::torch
[10:53:00] <servus> When I drop a torch, light it on the ground, then pick it up, it will try to put it in my hands, and add what looks like double light to my character. If it goes into my hands, I can unready it, and end up with a persistent light level of "4" which I cannot remove. If my hands were full, I end up with a permanent "8" light level.
[10:53:40] <servus> Light is added in Actor::inventory_parse_readied_objects and Actor::inventory_add_object and the Torch usecode
[10:53:52] <SB-X> i think that's just because i add light multiple times
[10:54:08] <SB-X> yeah i didnt even know about inventory_parse_readied_objects, but i mentioned the other two already :)
[10:54:17] <SB-X> i thought inventory_parse_readied_objects was only called on startup
[10:54:57] <servus> So I'm going to stop and wait to see what you do, and just send luteijn this patch now :)
[10:55:07] <servus> Maybe, I just now that add_light is there :)
[10:55:18] <SB-X> if you insist
[10:55:21] <SB-X> ok
[10:55:27] <luteijn> ok
[10:56:23] <servus> Huh? I just don't see what I could do when we are both editing the same exact lines :)
[10:57:02] <SB-X> code it anyway and let whoever merges it pick the best of each version
[10:57:13] <SB-X> i don't expect you to do that, however
[10:57:34] <SB-X> im too tired to work on it myself now
[10:57:45] <luteijn> or just let me merge what you have now, then it's 'in' already..
[10:57:57] <SB-X> :)
[10:58:05] <servus> Well it sounds like you are making this comprehensive light-source-list system. Uploading patch now
[10:58:56] <SB-X> nah, just a little improvement so you actually can have multiple light sources
[10:59:24] <SB-X> Actor::light was just a quick way to get light to appear around the actor
[11:00:14] <servus> Patch uploaded. Sounds like your fix will fix this problem. :)
[11:01:02] <SB-X> hopefully
[11:01:12] <SB-X> what about the fireplace moon problem?
[11:01:36] <servus> After I see what you're doing about the torch problem, I'll see if I need to do more work
[11:01:56] <servus> I didn't even look into it, and my eyes are going blurry for tonight... but it is extremely reproduceable.
[11:02:13] <servus> What is that "timer" widget called, and what renders it?
[11:04:12] <luteijn> I think we refer to it as 'sky', e.g. Game.cpp: get_view_manager()->get_party_view()->update(); // sky
[11:05:27] <SB-X> views/PartyView.cpp
[11:09:32] <servus> Is the moon system done? Moon alignment changes drastically at midnight. Is that on purpose?
[11:13:53] <servus> Awrr, I cannot reproduce it at all now, night! : o)
[11:17:08] <SB-X> yes it's done, it changes in u6 too
[11:17:26] <SB-X> i'm going off to sleep
[11:17:27] <SB-X> cya
[11:17:37] <luteijn> merging in Sam's changes
[12:10:15] <-- Kirben has left IRC (Read error: 110 (Connection timed out))
[12:17:44] <-- SB-X has left IRC ("*casts gate travel*")
[13:22:43] --> Yuv422 has joined #nuvie
[13:48:32] <-- Yuv422 has left IRC ()
[22:17:11] <servus> Hmm, reproduced the fireplace, and got a save of it. It says "Eclipse end".
[22:19:35] --> SB-X has joined #nuvie
[22:21:47] <servus> Ah-ha, views/PartyView.cpp:233 uint16 sun_tile = 0; and sun_tile is sometimes never modified after this! Should default to 362 to fix the fireplace.
[22:30:40] <servus> Or maybe more appropriately, add an "else return;" to the end of the if/else if sequence there at PartyView.cpp:234
[23:07:35] --> Kirben has joined #nuvie
[23:14:02] --> Kirben_ has joined #nuvie
[23:14:04] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[23:15:05] --- Kirben_ is now known as Kirben
[23:30:36] <SB-X> servus: Ah k, that's a new change. It shouldn't default to anything. (don't display sun at night)
[23:30:43] <SB-X> see http://nuvie.cvs.sourceforge.net/nuvie/nuvie/views/PartyView.cpp?revision=1.11&view=markup
[23:31:31] <servus> But for some reason the sun is being displayed when it shouldn't, and it defaults to fireplace.
[23:31:53] <SB-X> yes, it used to not
[23:31:58] <SB-X> the else return will work
[23:32:08] <SB-X> as long as we make sure you can't see an eclipsed sun at night
[23:33:32] <servus> Yes, that should work, but I don't see the eclipse anywhere in that version.
[23:33:41] <SB-X> nope
[23:33:47] <SB-X> i dont actually have the newest snapshot that's why I didn't see the bug :)
[23:34:09] <servus> OK well add an else return; and that's that.
[23:34:43] <SB-X> thanks for pointing the error out