General Discussion

[Xela]

Right... so the intercept part of the guard job is ready. There are 5 or 6 loose ends in these "skeletons" that I need to take out but overall, we have our jobs back. After that is done, it's prolly SE or Job Events mechanics.

We'll put some skin on those skeletons later, I need a break from working with the same code.

[DarkTl]

I'm linking screenshots from neptunia again to show how I imagine SE logic (not gui). One, two.

[Xela]

It's very close to Gismo's gui design. I'll have to change a lot there anyway. I'll start with some basic code setups, maybe salvage something from older design (if I can find where the heck that code is, I think Gismo destroyed old interface, but logic is still three somewhere).

===>
I'll wrap up some things tonight with jobs and think about best way to do the SE.

[DarkTl]

Found remnants of our old gender filter, we had it before Gismo's gui.

            filter = self.FILTERS[index]
            items = store.items
            if filter == 'all':
                if self.male_filter:
                    self.items = list(items[item] for item in self.content.iterkeys() if items[item].sex != "female")
                elif last_label in ("char_equip", "items_transfer") or self.female_filter:
                    self.items = list(items[item] for item in self.content.iterkeys() if items[item].sex != "male" and items[item].slot in self.FILTERS)
                else:
                    self.items = list(items[item] for item in self.content.iterkeys())
            else:
                if self.male_filter:
                    self.items = list(items[item] for item in self.content.iterkeys() if items[item].slot == filter and items[item].sex != 'female')
                elif last_label in ("char_equip", "items_transfer") or self.female_filter:
                    self.items = list(items[item] for item in self.content.iterkeys() if items[item].slot == filter and items[item].sex != 'male')
                else:   
                    self.items = list(items[item] for item in self.content.iterkeys() if items[item].slot == filter)

[Xela]

Noted.

==>
I spent most of the evening looking over SimPy land in our code, I barely began to figure it out when starting to work on the jobs. Code needs to get more generic and some design flows gotta be fixed. I also want to get a handle on some form if unified events system for jobs, prolly a class with a couple of methods and some way to call them from SimPy land.

===>>
We also run code building by building while SimPy can handle running multiple buildings simultaneously and communicating with one another if needs be, not sure if I am going to recode it for beta yet (rest of the code is the same in all cases).

[DarkTl]

So turns out win10 bug is a matter of scaling factor that works incorrectly for presplash, and hopefully will be fixed 

[Xela]

I've seen the issue. Gonna be really busy for a couple of days, so I'll either try to take out smaller issues if we have those or start coding SE line by line.

[Xela]

Oki, so I took a quick look at old FG code, is was written to work completely on it's own, with it own systems and structure (And most (or any at all) if it is not reusable in SimPy land, large parts of it, really, really badly try to emulate what SimPy already does (perfectly I might add), and rest is plainly built around that). I now remember that it was while writing original FG (SE) code that I've tried to code in a new Jobs system that worked like SimPy (which I didn't know existed) and failed miserably after two days of coding efforts...

We'll do:

1) SE Building: Normal Modern NewStyleUpgradableBuilding. I am not sure if this will be a unique building, it's not required by code but FG will have unique interface... so it makes some sense.
2) SE Exploration Business: First thing I am going to "core" code, it will take care of the main exploration loop.
3) SE Generic Job, will be a normal Job with a function of building reports + applying stats as well as holding check methods like all normal jobs do.
4) SE Exploration Run object. This one will be new, it will hold/store all the data of an exploration run (which can run multiple days). In a perfect world we would just leave the SimPy object but it is absolutely impossible to save SimPy land in Ren'Py land (generators cannot be pickled with Python without extraordinary measures). It's a minor inconvenience anyway.
5) SE SimpleEvent object: This one is mainly for interface purposed because we want advanced reports with can also be buttons to open more info. This is the best way of doing it.

6) Job Events: I talked about this before, we'll need it for events to be generic and reusable.

===>>
This looks like a plan, which is more likely to work than to fail (and to work well). Once SE core code is complete, I'll add JobEvents and normalize jobs code in general, then explain the concept on how it is working and we can stuff it with content (events/matron mods/more + better reports/better clients handling/moar meaningful upgrades/complete building system and etc.) together job by job.

[DarkTl]

I suppose we should make some design decisions then:
- should MC be able to act inside SE or not; in terms of normal gameplay it probably means straightly skipping all those days he's inside, since the player acts via MC, and maybe replacing these days by something that Old Huntsman made in his first game about traveling in fogs.
- should we limit the max number of teams acting inside SE at the same time or not; what if too many teams will slow it down?
- can multiple teams be sent to one location? If so, then simpy probably should handle their occasional meetings too.

[Xela]

- should MC be able to act inside SE or not; in terms of normal gameplay it probably means straightly skipping all those days he's inside, since the player acts via MC, and maybe replacing these days by something that Old Huntsman made in his first game about traveling in fogs.

I am not sure... basically, game doesn't give a sh!t if it's MC exploring or not, system is generic enough so the only issue is skipping days ahead. I tried that little over an year ago and it didn't work for unspecified reasons (Engine went into infinite recursions loop without an explanation). I am better with code today maybe I can try it again.

Second part I don't like, we may have normal exploration of some sort in the future and they'll collide, it's not a sound plan to try and maintain two systems at the same time.

- should we limit the max number of teams acting inside SE at the same time or not; what if too many teams will slow it down?

It will slow it down a bit but Civ5 turns are slow and it doesn't really ruin the game + we are not nowhere enough the logic required to noticeably slow things down. Basically we're running Brothel on per char basis! I wouldn't worry about that, system will assume any number of teams and we'll adapt interface to whatever works best.

- can multiple teams be sent to one location? If so, then simpy probably should handle their occasional meetings too.

Not a problem (at all), I am even planning coop fighting, it's all relatively easy with SimPy

[DarkTl]

Hm, we don't actually have to skip multiple days, we can just lock off all options like talking to characters, entering MC inventory, going to the city, etc. So player can see what's going on in his absence, but not act.

[Xela]

Hm, we don't actually have to skip multiple days, we can just lock off all options like talking to characters, entering MC inventory, going to the city, etc. So player can see what's going on in his absence, but not act.

Means adding extra conditions to every button in the game and killing auto-event system... too messy. I'd avoid that if possible.

[DarkTl]

We don't have to allow it to MC, it's as simple as saying that human y chromosome cannot exist in areas where SE taking place 

But if it's simple enough, why not.

[Xela]

We don't have to allow it to MC, it's as simple as saying that human y chromosome cannot exist in areas where SE taking place 

I don't know what this means

But if it's simple enough, why not.

I'll be very busy in the next few days, got about an hour now so I'll see (try again) if ND can be ran over a period of multiple days without issues.

[DarkTl]

I mean, if we'll have only have female characters in parties eventually, we might as well take another step and say that males actually cannot survive in SE areas due to genetic issues and close the issue once and for all with the help of the lore 

Of course we also can introduce short (for 1 day) explorations not far from the city, where MC can be without any additional coding, for the price of all AP probably.