Floor plan on scale

General discussion of the House Party CSC, or get help making your own story.
Forum rules
Please follow all Eek! Forum rules.
eekdon
Posts: 1546
Joined: Tue Feb 13, 2018 4:29 pm

Re: Floor plan on scale

The prior post is correct. The Enters Zone event will fire before the Character's CurrentZone is set to that zone.
Image
Devotion
Posts: 8
Joined: Mon Dec 30, 2019 3:13 pm

Re: Floor plan on scale

Image

does not hit though.

Image

I'm coming from downstairs, so I'm not in zone already.

I dropped all my other criteria even though they were true after checking them with 'list values'.
The event trigger is hosted under the Frank character.

If this should be working it sounds like https://forum.eekllc.com/viewtopic.php? ... 7696#p5907

Even this new story with only one event (on Amy) for entering hte master bedroom doesn't trigger when you walk into the masterbedroom.
Image
https://filebin.net/8spey4274z1z67g0
eekdon
Posts: 1546
Joined: Tue Feb 13, 2018 4:29 pm

Re: Floor plan on scale

There was an issue with this in the last update. It'll be fixed in the next:

https://vimeo.com/383091023/2953d0420b
Image
Devotion
Posts: 8
Joined: Mon Dec 30, 2019 3:13 pm

Re: Floor plan on scale

Great, can't wait and I'll stay devoted now ;)

Now I'm using periodically triggers that check for 'In zone' which get the job done

Image

Talking about periodically. Do the use of too many of those give performance issues? Or are you checking criteria first before you trigger them anyway?
So like the gamecode only tries out the periodic triggers that have met the criteria at some point?

I mean:
I can have a period trigger that checks like every 1 second with criteria '<character> In zone Masterbedroom'
And another one that checks for '<character> In zone SpareRoom that checks every second.
And a 3rd one that checks for '<character> In zone Garage that checks every second.

Lets say <character> runs into the Kitchen. None of the above hits, but all 3 still check in your gamecode?

You could run all periodic triggers every second, which might cause delay?
Or just run all period triggers that meet the criteria at some point?

So once <character> runs into the Kitchen, it grabs all event triggers (and the periodic ones) that hit the criteria ' <character> in zone Kitchen' (zero in my example) or does it test all 3 in my example every second?
Or in case when <character> enters the garage, does it only test the one with the ' <character> inzone Garage' ? This sounds more healthy to me.

Just wondering how your code behind is working with those periodic triggers from a developer' s point of view. Probably the criteria first and then the periods if criteria met, the other way around might give problems when I use too many of them in my story. (Considering what is too many). Probably you meet the criteria first, just curious.

I like those to give the story a little randomness though.

I hope this makes any sense..
eekdon
Posts: 1546
Joined: Tue Feb 13, 2018 4:29 pm

Re: Floor plan on scale

There are some periodics in the Original Story that fire faster than once a second. The fastest one might be 0.33s, which is a number I chose because our Character Update tick rate is 0.3s, to which I add a small buffer. On a Character Update tick, vicinity, cansee, and distance key/values are updated, and various Should React to Reactions (event triggers) are checked (should character1 react to character2 being topless, if they're indeed topless, etc.), which effectively results in how fast characters react to things like "caught having sex", "caught masturbating", "exposes genitals", etc. The recently added "blinded" checks (from phones held by the player or an NPC) and the poked by vibrator checks also operate against this Character Update tick. Most importantly, the Event Handler Update and events handled within it (queued regular game events of any kind, AND periodic event triggers) can be updated at a speed up to the Character Update tick rate.

So in short, the fastest periodics should have to be is about 0.3s. It can be faster, but you won't gain anything. Notice the time delta on this periodic, which I set at 0.1s in the CSC:

Image

Not firing every 0.1s. So, don't bother with anything faster than 0.3s. Again this only applies to game events that are queued (won't be getting into that whole system here, but it's safe to assume a fair amount are), and periodic event triggers. The actual *contents* of the event (like setting an NPC to state immobile = true) are generally instant or near-instant. As instant as your PC can get :P Once these event "contents" fire, they're effectively ready to use in an event that is fired next OR perhaps more accurately stated: is next in the event queue. Even an event that is within the same periodic and merely one "Order" value higher (yes, Order matters other than OCD organization).

As for performance, there could be an affect with many periodics running at once. Especially if they display messages on-screen or aggressively handle character animation(s) or movement, or cause physics fun to happen. Things could also get choppy if you're handling large arrays of criteria at once and firing off many simple game events; but the threshold for for that is still higher than if you're trying to fire off momentum itemfunctions or something like that every 0.3s. Even if you have four events, one at 0.01s, 0.1s, 0.2s, and 0.3s as shown below, they'll only process at the rate of the Character Update tick rate, so you would have to try pretty hard to impact anyone with a relatively modern PC:

Image

If you're concerned about it, set ALL of your periodic event triggers to false at the beginning of a story, set them to true when you are sure you'll need them soon or imminently, disable them when they'll definitely not be used again, AND criteria-lock them. If a periodic is not enabled, none of its criteria are evaluated and nothing inside it is evaluated or will have a chance at firing.
Image
peter980
Posts: 1601
Joined: Thu Feb 15, 2018 1:50 am

Re: Floor plan on scale

In Fiery Date story, I experimented with having 3 events, where each would call one of the others 50% of time after some delay. Which is kinda like periodic events, but it's not.

And before I added some safeguards, those events could get out of sync, when they would start calling each other more and more often, leading to killing performance. We are talking about events being fired in hundreds or thousands of times in second. :D

This is only time in the game I got into situation where event systems reduced performance.

But personally, I would recommend not too quick perfiodics or anything that would make debug logs unusable.
Post Reply