Events missing
-
If the queue persists from tick to tick, then there absolutely is a benefit. It could eliminate tons and tons and tons of polling each tick. if creep.hits < creep.hitsMax no longer needs to be checked for each creep. you get a message once (attacked) you know the specific creep. you don't need to loop over every creep to check. you just add the creep to a heal queue. then you can check only the creeps in the heal queue to target for a while hits < hitsMax loop to send your healers to.
I won't get in an argument with the devs of the game.. if you don't want to do it, that's your choice of course.. but it absolutely can save cpu time to generate events and have them be responded to, rather than polling, especially if there are numerous creeps.. And extra especially if there are numerous creeps across numerous players.
Also, if you don't want to generate a persistent message queue across ticks, that's fine, just tell people they have only 1 tick to take their messages out of the tick queue and put them in memory themselves.. You don't even have to change the tutorial, people can still do polling, they just have the option of being more efficient with message processing if they want to.
-
Events are wrong tool for the stated problem - OP wants events, but OP really needs a finite-state automata.
Creep poll can't be eliminated due the nature of the game. Since it can't be eliminated, it's relatively cheap to incorporate aotomata state updates, based on creep current statistics and data stored in its memory, into this creep poll loop.
Actions that creep does or that will be done on him, can then take this creep state into consideration.
-
take an example of a rampart attacked then. I may only scan my ramparts infrequently to save CPU. I'll stop arguing. You are correct about every creep needing a visit each turn.
-
Ok, time to kill some myths:
- Event loops Its true that they can be simulated. But does it fit in fixing the problem
- Death creeps Event trigger is no solution if the simulator itself can't reliable tell (timeouts) if the event has been handles. A solution has to fix within the screeps architecture. Logs or event history queue's may be a better solution.
- creep.hits < creep.hitsMax is actually close to a no-op compared to computing done to complete a path finder. If you believe this is not true, run benchmarks and try to find the biggest time waster or post a question/discussion. Maybe we need some public benchmarks about this.
-
creep.hits < creep.hitsMax part II: its very easy to disagree with a certain architecture. It's also easy to get exhausted from these kinds of discussions as well
-
just to clarify, I'm not proposing event triggers, I'm suggesting a message queue of events (and other user communication) that can be processed by the user each tick. see my other post linked in an earlier message
-
@nugarin: FSM and Events are two completely separate paradigms! They have nothing to do with each other. Did you ever hear of event driven FSM?
Anyway, at the moment, there are situations which can lead to an "indeterminate" state of the FSM due to a lack of information, which could be leveraged with events.To make my point clear:
The event system I would like to have:
You subscribe to certain events, which (in case they are emitted) land in an event queue that can be processed in the next tick.
Reason:
Case 1:
Two enemy creeps with 60 damage each - both in range to your creep, which receives exatly this 60 damage - which of the enemy creeps attacked yours? You can't decide, because you're lacking information. With events on the other hand, you process the emitted attack event (which includes the attacker information) and simply update your FSM accordingly.
Case 2:
A construction site finished. In the next tick, it's ID is not valid anymore. Thus you have to do several steps, to 1) register the new structure 2) reassign the worker. Of course, it can be done, but it just would be way easier, if you had an according event with the necessary information, e.g. the id of the former constructionsite and the id, type and position of the new structure.
-
I never said that FSM and events are connected. What I said is that your problems are better solved by using FSMs. Events are horrible solutions to both of your cases.
Case 1 - it's really not important which of the enemy creeps attacked you, what is important, is their potential for the attack, which you would have to check for anyway.
Case 2 - you loop construction sites for build anyway, removing an id from the list is not expensive. Events won't really make it easier, you still have to id sites that you don't have events for at initial stage, then keep your data model in sync as events fire - how is this any better than just getting these structures from game data model with appropriate filters applied?
When you have a hammer, everything you see is a nail, now you don't have a hammer, but you want one to hammer in that philips-head screw.
-
well, you either are incapable or just don't want to understand my point. Also you seem to confuse terms here and contradict yourself. We obviously have different opinion on that matter, so it's no use arguing about it. I guess this thread can be closed, since there will be not much valuable input anyway.
-
I'm still wondering though why it takes such a fight to at least trying to get a clear solution.
If we all would agree that something is a good solution, the solution is easy to integrate (some easy to implement code for example), we might not be in such a situation.
Anyway, things takes time, lets at least hope we've learned something out of this.
-
I was just gonna post about this and stumbled about this thread in the procedure, and I very much agree to what chris said, especially the two examples he gave which I was gonna post myself (damage identifying the source; construction finished - identifying the new structure). I believe something needs to be done to let us REACT to stuff instead of just ACTING - if events aren't possible, some other solution needs to be found. I believe this could potentially even reduce CPU usage overall and thus reduce server load, since we wouldn't need to actively scan and monitor stuff quite as much as we do now.
and btw:
> Case 1 - it's really not important which of the enemy creeps attacked you, what is important, is their potential for the attack, which you would have to check for anyway.
yes it is important, if those creeps belong to different players, or to a player and invaders, in terms of diplomacy. For example, I might wanna have code that makes sure that my creeps do not attack a certain player unless he attacks me first - which is basically impossible with the current API, because scripts are completely unable to know who attacked.