I've actually never seem GameEvent fire ever. I didn't even know it was supposed to be associated with PDA events, I just assume it was a deprecated and undocumented API feature
I might be mistaken, but the GameEvent is a 'recent addition' (73), added after Event_PdaStateChange (72). This suggests it is likely to do with the PDA, and not deprecated Also I heard it mentioned in a discord, and forum (I think), at some point, that it was relating to the PDA. Again, I might be mistaken. But if it is to do with the PDA: It's broken If not: We really need something that can read events off the PDA (other than just chapter's active/deactive/completed state)
Hey, you guys are right. We took it out in 7.0 or 7.5 or lets say we deactivated it out of performance fears. It really sends a LOT! But for 8.1 (maybe also for 8.0 with a flag to deactivate in the dedicated.yaml or so) it will be tested and implemented again. If so we have quite some new things to play with The next days we will start with a lot of cool new features on the API side. Hope all goes well. I let you know then.
Sounds cool. In reality, it is for the most part enough to know: -When a chapter, task, action is: activated, deactivated, completed, (failed) -When a criteria have been partially met would be nice knowing too (for instance, if you have a subjectkilled, with amount 2, it would be nice having it spit out, when amount:1/2) These should be fairly 'low impacting', and really all I can think off, that is neccessary to get notified off, event-related. The remaining functionality would make sense to be able to querry via. a request (such as name, rewards, structure, etc.. basically exposing the yaml-imported stuff)
CmdId.Request_Playfield_Entity_List returns data, but that data is Not valid I'm receiving Entity information but none of those entities match the playfield I'm requesting Entities for
Hmm. Weird. Do you have multiple playfields running? I only tested with one, but for the most part, I got the data I was expecting. However! The Ids seemed off. And not everything was listed for me either. There's likely atleast some buggyness going on with it, yes.
No. I reported the bug, it's been confirmed by someone else. You have all the information you need to find the bug yourself.
If you can, I'm sure it would be helpfull with some screengrabs / lists, with ingame expected, versus logged outputs^^ I've deleted the code I used to logging, so if you still have it, that would be the easiest The more detailed 'what is going wrong', the easier it usually is to fix.
Bug: When closing a server, mods DO NOT get the chance to execute 'Event_Player_Disconnected'. This *should* always be sent, and the server *should* wait for the mod to finish, before shutting down. (To reproduce, click 'save and exit' in server-window /shut it down, and notice no disconnect event is sent in log/other)
Bug: When connecting to a server, 'Event_Player_Connected' doesn't fire, if the user is tabbed out. (Ie. the user is ON a playfield, and active, according to the 'sneak preview'. Only when you OPEN the game, does the event get sent) (To reproduce, click 'connect' to a server, then tab out of the game, and refer to the logfile / like, if event is received)
Hm. I mean it's not the end of the world to hook it up to game_exit.. In my usecase I'm fine. But in general, the difference between game_exit, and having it be an event, is that you have (each) users entityid to work with. You are a little more blind in the game_exit case. You can maintain your own list, of players online to work around this.. But for consistensies sake, I'd think having it work foreach DC would be more intuitive, no?
in 8.0 after loading playfield, request strucrureslist and structureupdates some time return incorrect values.... devices = 65535, lights = 65535, blocks =-1, Triangles =-1, class =255
This is actually kind of correct. With 8.0 invalid data (since some data can't be delivered when the playfield is still loading) will be set to -1. That way you can determin if a value is correct or not. Before he send you a 0 which lead to even more problems. 65535 is -1 in this case, but this will be fixed soon. Thanks for reporting.
Player connected event doesn't always get sent. Quite frustrating, and breaking I have no been able to reliably reproduce it, and it seems to happen randomly. But nonetheless, the event for a player having connected doesn't reliably trigger.
Minor bug: If launching several 'popups' (such as itemexchange), only one will appear. I'm not sure how much of a bug this really is, but it can possibly lead to unintended behaviour. If intended, noting it in the documentation would be fine, I think. (Please let me know, if intended, so that I can update the wiki accordingly)
For Request_ShowDialog_SinglePlayer; Text is bugged. (formatting) [Possibly related: The first line is encased in ; Perhabs that is being counted as indendation?] Both buttons, and text, is not always properly behaving: See https://imgur.com/a/WiWHUvp Note, that the same result comes from \n , \r, \n\r & Envoirenment.NewLine (Although \r does nothing) Bonus bug1: Too much content (than what can be handled by client-screen) doesn't get auto-wrapped, but rather overflows. Bonus bug2: Popup box persists, even after exiting game (servershutdown) Bonus bug3: Overflowing in y-axis (top-bottom), doesn't get handled properly either. In this case, a scrollbar would be expected. (see image) Bonus bit: I feel it would be greatly beneficial being able to specify [ RIGHT],[ /RIGHT] [ LEFT],[ /LEFT] [ CENTER], [ /CENTER]tags, to define how the text behaves, per-line. EDIT: After further testing, it appears to be mostly related to few lines. More lines seems to make the end-result more stable. (See imgur link for all documentation) Edit2: added overflow-y bug.
