MT 1.3b35 development progress

[salmelo]

when you say "get right" do you mean get it too not repeat the same card until you reshuffle or whatever, or do you mean something else?

That's the easy part

The hard part is keeping it correctly in sync across all connected people, making it as impossible as possible to cheat, give the cards a place to "live" so you can interact with them, and possibly make them interact with the map.

ah

[Orchard]

Edit: Also /settokeproperty does not display the output of all the properties being changed which with large macro's where you may be updating several properties and a state can get very spamtacular, a command to for damage that updates states under 4e could look like something like

Code: Select all

/stp [p_TempHP - i_damage][p_HP = p_HP + min(0, p_TempHP)][p_TempHP = max(0, p_TempHP)][state_Dying = bnot(max(min(p_HP,1),0))][state_Bloodied = bnot(max(min(p_HP - p_Bloodied,1),0))]

Which when it is expanded in the output will make everyone cry

You ain't kidding about that...which is why we need abbreviated output stat. Where are we on that anyway? I lost track.

It's the need for heinously extended macros like that which convinced me that abbreviated output with mouseover details were necessary from a usability standpoint. And while I'm capable of implementing a usability study, I'm only 3rd-rate as a usability guru. I can think of people that I know personally that are much more qualified, and people that they know personally that are more qualified than them. That makes me at least 3rd-rate. But I still know enough to know that we need abbreviated output badly, but with instant access (mouseover) to the details of the macro for the GM (and possibly the players--that's something that could be toggled in the server setup).

I may just have to learn Java in order to make this happen. If only I had the spare time to do it. I still haven't had the time to work on documentation like I really want to. Argh!

[trevor]

DEV EXPLANATION: colored light

Those that are playing with the dev version have asked questions about the way the colored light works. This is an explanation.

In order to make the color overlapping look acceptable I combine all the same-color light areas and combine them into a single painted object. This cuts down on a ton of on screen clutter (if you'd like to see for yourself, comment out the combination loop in ZoneRenderer.renderLight() ).

But that by itself creates a problem because there is a concept of bright vs non bright. If I just render the lights from the colors listed it creates shadowy looking areas inside of bright light, which is especially distracting and ugly.

So we need a concept of making a light "bright", which does not currently exist. I might tweak around a little with the light and see what I can do, but it may require a model change which I'm trying to avoid.

So for now, light that does _not_ have a color specified is considered bright light and everything colored is considered non bright. That means that it first renders all colored light, and then removes all of the non colored areas from that. So colored bright lights don't exist right now. I'm aware of this oddity and am tinkering to find a nice solution.

But that's why you are seeing what you are seeing. As long as you don't have colored bright light, you are fine.

[UntoldGlory]

Can you add a property to lights (brightness perhaps) that is simply a number? Say, 0-Whatever, the lower the number, the "dimmer" the light, then it could just render the lights in numerical order. So a "daylight" light source (light yellow) might have a value of 10, while a torch (orangish colored) might have a value of 6. That would give you the possibility of custom, even brighter sources. For instance, Lathander, the morning lord, a god, shows up, he has a personal light source of 60', brightness 12 (almost hurts to look at), white in color. So assuming all three of these were present, it would render first the torch, then the daylight (overlapping lets say half the torch, cause he's standing in a cave mouth), then would render lathander's light, which would be a circle of bright white within the yellow light of day.


Is that something feasible?

[thelevitator]

I have 0 knowledge when it come to programming, so I am pretty much asking an academic question: What is harder from an MT standpoint, bright/shadowy light, or gradient light? By gradient, I mean a more "realistic" light source that has a set birghtness at the center and then gradually fades in intensity, like a real light. I am just asking because not all games use bright/shadowy light, so having something that worked a little more like "real" light might appeal to more systems that don't use a binary lighting system. To a non-programmer, it seems like it should be easier, since you are only working with one "light" or "color" that fades according to whatever is the scale of the light source.

I'm just curious if, for those that want a more "realistic" lighting in the game that doesn't use the bright/shadowy concept, might we have something that models actual light? I'm thinking of something like most RPG videogames, where the light is bright for a set radius and then fades gradually as it extends outward.

[Hawke]

I have 0 knowledge when it come to programming, so I am pretty much asking an academic question: What is harder from an MT standpoint, bright/shadowy light, or gradient light? By gradient, I mean a more "realistic" light source that has a set birghtness at the center and then gradually fades in intensity, like a real light. I am just asking because not all games use bright/shadowy light, so having something that worked a little more like "real" light might appeal to more systems that don't use a binary lighting system. To a non-programmer, it seems like it should be easier, since you are only working with one "light" or "color" that fades according to whatever is the scale of the light source.

I talked to Trevor about this and he informed me that with the current graphics engine gradients aren't really possible. Perhaps possible to do, but the impact on performance would be too great. I looked into several java options but none worked out for what we needed.

When it comes to gradients around light and producing lights that are more like Game Table, we'll need Java 6 and a 3D engine. Elsewhere trevor has mentioned "3D engine to display the 2D" which is basically a rewrite of how MapTool handles graphics and will allow a lot more lighting options and hopefully more realistic light.

So, in short... probably a 2.0 thing but something on the drawing board, I think.

[thelevitator]

Thanks for the explanation Hawke! I assumed it wasn't really feasible with the current set up, or would have likely been implemented already. I too was thinking of it as a "down the line" kind of thing, with all of the discussions of changing the chassis on MT.

So, assuming that MT eventually goes to something like you mention Hawke, namely the 3D engine to do 2D concept, I'm still curious whether at that point bright/shadowy or gradient light will be easier to implement? I'm just curious from a technical point of view.

[DieHard]

interesting discussion, I suggest reading the ideas that I came could be useful

To draw the lights I think to a system of multi shape associated with a token / object that overlap

for example, a torch is a circle of low light of 40 + a light full of 20

this could also serve to implement the type spells of darkness 3.5d&d (areas or objects that radiate areas brightness)

es. table of token light source for pg with Lantern, bullseye and spell darkness active
shape= cone;range=120;type=Shadowy;zorder=3
shape= cone;range=60;type=Bright;zorder=2
shape=circle;range=40;type=Shadowy;zorder=1

es. table of token light source for pg normal Torch
shape= circle;range=40;type=Shadowy;zorder=2
shape=circle;range=20;type=Bright;zorder=1

[Korpus]

Sorry for the silly question but is there a WIP build kicking about or do I need to pull the files directly from the SVN and put it together myself?

Was intrigued to see how the 4e lighting was being implemented

[Hawke]

Sorry for the silly question but is there a WIP build kicking about or do I need to pull the files directly from the SVN and put it together myself?

Was intrigued to see how the 4e lighting was being implemented

You'd need to grab it from the SVN and put it together. There's instructions stickied some place if you're interested.

[UntoldGlory]

Yeah, b35 was sort of scheduled for this weekend, but it looks like Trevor had a sudden attack of real life!

[dorpond]

I found a few bugs last night that I reported. Perhaps he is squishing them before he releases.

[UntoldGlory]

Sounds like a good idea to me.

[trevor]

Yeah, b35 was sort of scheduled for this weekend, but it looks like Trevor had a sudden attack of real life!

Boy isn't that the truth !

I've also received a few last minute bugs, and a few last minute patches that I'm putting in.

I still plan on doing the build tonight, but if I fall asleep, it'll be tmrw.

[Phergus]

So how about instead get all the new code checked in to the repository and let those of us experimenting with the repository code beat on it for a day before you do a build?