HI, I'm trying to resurrect an old mod and need some help. The mod ReforgedEdenMKI it is supposed to teleport ships from one sector to another (there is a jumpgate in RE, but it normally only is a portal) After updating some sector names it kind of works, but the game starts lagging instead it doing the warp. In the log this pops up: Code: -ERR- Query GetStructures_Blocking took 11429ms. Param count=0 I think the code line with the request is: Code: mod.LegacyAPI.Game_Request(CmdId.Request_GlobalStructure_Update, WARPGATE_GSI, new PString(_sourcePlayfield)); I searched for the syntax of this request in the modding doc, but did not find anything. 'would be great if someone can give a hint how to make it work. Thanks a lot!
I did a rebuild of the project (fix links to mif and modapi) and loading works fine but doing the setup to activate the gate without actually grinding through the missions isn't obvious to me- I can't even get the lead researcher to actually assign the object 82 mission. 8^) Being in a rush to get past required mission gating criteria makes jumping into real debugging a pain. The Request_GlobalStructure_Update request is being issued to identify ships in the vicinity of the gate by returning a list of all structure entities in the playfield, and WARPGATE_GSI is a sequence number returned for the request which lets you identify the matching response. This request/response interface is probably the weirdest part of the apiV1 interface and reflects a non-blocking way to write async code in the mod- issue a request and then keep watching events until the matching response comes along. The GetStructures_Blocking error looks like a timeout (11.429 seconds to get the list of entities on a playfield is way longer than you would expect) ... maybe the matching response never came along? The error seems to be internally signaled as opposed to a condition that the mod detected as the error string isn't in mod's code. The actual warping of ships is performed by the api.Game_Request( CmdId.Request_Entity_ChangePlayfield call ... if it's dying in the structure iteration you haven't gotten that far. Since the loading goes through the process of determining if there are playfield entities pending warp implies that the mod maintains state across dedi server reboots, but in a quick read I didn't see how. Stateful code is always more painful than non-stateful ... figuring out the how/why of that may help. Not sure if any of that fits a hint, but hopefully something useful. I've been wanting to figure out how to do the "Move A@playfield to A@anotherPlayfield" thing so really appreciate the chance to dig into this mod- I'll be starting at the Request_Entity_ChangePlayfield and working backwards ... sorry I don't have more to offer, but reading OO vs. procedural code isn't my happy place. Hopefully someone who's done this sort of stuff will show up with more.
Thank You. I did a little bit of testing, and it seems the request is sent, also with the playfield name, but the answer never arrives. My top suspect is the playfield parameter. Maybe it needs to be encoded or passed in a special way, failing this the dedicated server tries to answer with all structures everywhere and runs into that 12s timeout. I wonder if i can make a barebone mod to just do the request with a fixed playfield and get an answer. also for testing just teleporting there and "gm iv" turn it on should work. (i switched it on by accident when i was looking at it with "gm iv" in a new game) little update: the mod "works" after like 10 timeoouts it teleported me to the other side... but thats not like it is supposed to work. especially as i get a eac kick for packet loss in 2 out of 3 atempts... another update - after reading astics empyrion scripting source i figured i probably have to write a dual-mode mod. it seems the whole playfield stuff is only aviable in the playfieldserver... also i want to make a change to the script operation and only teleport the ship with a player pilot after he clicks the dialog.
Started messing with this and I clearly gotta write code before I talk about it- best of luck finding the right set of calls. If I figure out the specifics I'll follow up...
Here are just two quick notes: 1. Request_global_structure_list & Request_global_structure_update are no longer supported by the API of the dedicated server and have to be programmed by a DB query directly. 2. The teleport only works via the API of the dedicated server while the (current) ship/player data can only be accessed via the API of the playfield server. So here a DualMod is necessary which communicates via ModApi.Network - unfortunately quite a tedious way :-(
I have a strange Problem: a global Variable Code: public static IEntity WarpGateA = null; inside some if clauses it gets populated Code: WarpGateA=CurrentPF.Entities.Values.Where(E=>E.IsPoi && E.Name == "Ancient Warp Gate").Single(); This works, inside the if clause i can access it. now only do the else should be executed. in the else I again get Entities from the CurrentPF, just the same way. (E.Type ==EntityType.CV) Just after this the WarpGateA seems to be null again. I have no Idea why the global variable does not stay defined. this one thing does not let me sleep.
Your static variable will remain set ;-) Remember that your mod is loaded per playfield server and that a playfield server can currently handle up to 3 playfields. If your mod is also operated in the Dedi, another instance is added. Here you must always pay attention to which instance of your mod is currently active during processing (and the log outputs). PS: It is also difficult to answer your questions if the code on GitHub does not match ;-)
Yea, my local Code is really a mess, so i did not push it... The Problem consisted, but thee I found a simple solution: do it all at once and not in 2 updates. I even got rid of most globals this way. a few hours of sleep and then attacking the problem again sometimes works out
Thanks to all help and especially code I stole from ASTIC I got it working. https://github.com/me777/ReforgedEdenMKII It's a rewrite of most of the detection in the playfield server using API2; some parts of the original teleport logic made it in (into the dedi-part). I do know it's not the best code (everytime I look at something from ASTIC i'm reminded how much of a beginner I am)
