General Discussion

[DarkTl]

We have and I thought that through a lot myself but it's not a priority, we don't even discuss jobs much which are far more important

I don't remember...
I doubt I can understand sympy logic without long explanations, and the rest of the jobs code in rpy doesn't need discussions, it needs quite simple improvements on my part and potent writers for moar lines 

[DarkTl]

Hm. Not all MCs have sprofile pictures. Or, rather, they use the very same picture as both battle sprite and profile, but with different names. That's a waste of space, the game should do so without it when needed.

[Xela]

I doubt I can understand sympy logic without long explanations, and the rest of the jobs code in rpy doesn't need discussions, it needs quite simple improvements on my part and potent writers for moar lines 

Oki, gonna keep hacking at logic, i actually had a list of questions about jobs but the post prolly never went through...

Hm. Not all MCs have sprofile pictures. Or, rather, they use the very same picture as both battle sprite and profile, but with different names. That's a waste of space, the game should do so without it when needed.

You can create an issue if you like, this does not seem important + we planned to generalize tagging systems so tagging db is used everywhere + that will ulock the road to even better logic.

[Xela]

We might have to rewrite BE Skills declarations a little bit (for the last time). I'll try to work with what we got but it's confusing and incomplete system, especially if we want to have the best management for general attack types (custom types can obviously do anything at all at cost of extra code).

===
New MC sprites look a LOT better, I still didn't get a chance to grab new packs though

[Xela]

I put in a couple of hours into ironing out BE gfx this morning, there are a few kinks to work out and generalization across all classes is needed but I will try my best to finish that part today

Zero Prism looks totally awesome with a properly timed sprite shatter effect I am running right now, I can't stop running the attack over and over again. Gtg for an hour or two but I'll have another 5 - 6 hours to hack at it tonight.

[DarkTl]

Do you think we can afford now to add small special effects to all spells, like in that last Eliont's game? Like, ice reduces agility or something.

[Xela]

Do you think we can afford now to add small special effects to all spells, like in that last Eliont's game? Like, ice reduces agility or something.

Effects themselves have nothing to do with what I am doing right now, at best it will be simpler to add gfx representations of those effects. If you want to mess with that before next release, we can always add another issue but we already have a lot of those

[DarkTl]

You did mentioned rewriting skills. Might as well add effects, if it's simple to code.

[Xela]

You did mentioned rewriting skills. Might as well add effects, if it's simple to code.

We can do it though events and add to calculations as modifiers and it's not hard but we'll need graphical icons if we want to do it properly... it just feels too early with everything else currently on the plate.

I need 3 - 4 hours more for gfx normalization + there is one huge and complicated bug there that I only know how to get past by in theory (because it's very rare and occurs only during skipping, making my theories even harder to test). Once that is done, if you insist on modifiers bound to attacks, I'll code that in and show you how to use them with a proper, well commented example (I can find an icon or two on google or I even recall some in my resources/DB).

If not, if there is still time/will left, I'll add a couple new gfx effects.

[DarkTl]

Nah, I need to think properly about the concept first.

I added another new issue instead 

[Xela]

I added another new issue instead 

Advanced portraits logic #147

It's not a good idea to pollute general access methods with logic like that, I'd much rather see indifferent (or even random) instead of in pain if sad is missing (for example). Same for shy > scared thing and couple of others. You obviously see thing differently, if we ask someone else, it can be a whole different opinion.

I want general access methods/funcs to obey plain, common rules with as little overrides as possible, if you want it to work like that during your events, I can have the portrait method have special "Dark Events Mode" rules override

[Xela]

===
Yeah, I am gonna rewrite the declarations, it'll take another couple of hours but it'll be worth it in the end...

[DarkTl]

"Dark Events Mode"

You misunderstood, it works in one direction. Sad can replace in pain and tired, tired can replace in pain, in pain cannot replace anything.

[Xela]

You misunderstood, it works in one direction. Sad can replace in pain and tired, tired can replace in pain, in pain cannot replace anything.

LoL

Code: [Select]

Happy<>Confident
Sad<>Tired<>In Pain
Angry<>Defiant
Shy<>Uncertain<>Scared
Ecstatic<>Suggestive
it should have been:

Happy>Confident

then. It makes more sense... it's still unorthodox but we can roll with it none the less.

[DarkTl]

Yeap, my bad -_-

I'm telling it based on my pack maker experience. Sad ones are much more common than tired, and tired ones are much more common than in pain.