Get Ore Markers in the Programmable Block

https://github.com/KeenSoftwareHouse/SpaceEngineers/pull/567/files

here is my pull request. please go over the code and weigh in your thoughts.

 

Maybe you should use a list as an argument instead, so people can supply their own globally allocated list.

And:

Code:

var element = deposits[i];
formattedMarkers.Add(new ModAPI.Ingame.MyOreMarker(element.Material.MaterialTypeName, element.AverageLocalPosition));

 

thanks; will do. Any reason to use var over fully specified?

 

Quicker to type and I couldn't be bothered to check what type the element actually was the point there was the list lookup reduction, instead of calling

Code:

deposits[i]

twice.

EDIT: also, apart from the name, the typeID/subtypeId would also be useful, so modders can use it to lookup the definition if they need to because the name is most likely not enforced to be unique... or just give the definition directly, not sure if that's usable in PB though.

 

allowed.
--- Automerge ---
about code, better enforce player to transer list as argument,
not protect player from NRE.(remove ref)

and question, do you checked this code on DS and MP?
also do you checked on not local grids
(grid from which you don't see markers).

cuz may work only in SP, and when player actually see those markers.

 

@phoenixcorp13 ive been having problems compiling with 2015 community but id love to test.
--- Automerge ---
Im gonna stick with ref but as for sourcing from MyHud.OreMarkers, It looks like its constantly updated when you have ore detectors. When you dont, those related MyEntityOreDeposits are unregistered.

The only difference that a nearby player in singleplayer will have is whether its visible or not; the markers are still there. In dedicated server, the ore markers are visible for allies right? It shouldnt matter because the programmable block is linked to the player who owns it. Block ownership is already a deciding factor on what information can be accessed. We may find that when the owning player is offline, that info is no longer there.

Even with my assumptions on reading the sauce, I still need to test somehow.

 

keep in mind that DS don't have active players.
and in MP only server execute scripts.

 

hmm ill have to do some research on getting it compiling.

@Digi all the oremarkers will have SubTypeName Ore so i dont see how that could be useful. ???

 

Antennas can relay ore markers to anyone in range.

PB is always executed only server side, block owner being online or not is irrelevant, most likely it won't work for out of range ore detectors in which case you'd need to access the detector component and make some fields accessible.

The definition can be quite useful, it's not like PBs can use MyDefinitionManager to access it and while mods can it's still slower to do a dictionary lookup than having an actual reference.

 

useless. it don't check if not needed+async.

 

Alright ill put in subtype id that shouldnt be a problem. Im more worried that since script is run from the servers perspective, the hudmarkers are a global collection of every marker currently in range of any detector! that would kill this idea pretty quick.

 

SubtypeId is not the definition reference.

A method triggering the scan manually would be useful (for PB and mods to use), just make sure it doesn't start multiple scans from the same detector.
Then the PB would have to wait until the results are in, for that a time indicator would be useful to know when the results from the ore detector were last generated.

 

I got my source code working and a test script. Its really strange behaviour right now im figuring out an alternative to myhud.oremarkers. its returning 500 deposits when i can only see 5.
--- Automerge ---

 

you got ore definition, but we need item definition

 

Im not feeling the need to add so much information to this struct. just a clean looking ore name, the location, the bool IsRare. Thats all players need. This is for players not modders; those can make there own changes. Ultimately its not up to me since keenSWH will decide what will fit when they test the pull request.

The test revealed that it is returning tonnes of tiny separate deposits; not just the visible markers. it is extremely laggy next to a large asteroid (garbage collected pause per run) so next i will aim to get just the visible deposits. Also dedicated server test still to come.

 

Iron_01 is voxel material, not ore.

 

ok that name is not looking clean enough so there must be a better alternative as you say. Added to todo list.

 

Code:

public void GetOreMarkers (ref List <ModAPI.Ingame.MyOreMarker> usersList)

I would remove the ref keyword from the userList parameter.
For people new to programming its just too confusing and for most beginners hard to understand. Without the ref keyword the behavior is equal to the existing GetBlocks or GetBlocKGroups methods of the GridTerminalSystem.
Also replace the inner for loop with an foreach loop to avoid multiple accesses to the same list index.

 

better just store it in variable.

 

All it takes is one msdn page to get it plus the compiler will say missing ref keyword. It is unlikely anyone reading this using a decompiler will not understand ref.

Keen has asked all pull requests to follow a design philosophy where performance is considered the highest priority. If i do as you said then we would have a new list allocation on the heap every time this is called.

 

ref not prevents from allocation of new list.
ref will speed up only when used on structs.(which otherwise copyed)
also ref requare initialized value anyway.

better use API style of other API, instead of creating new.

 

Yes, for people who already know the concept it is a 30 seconds lookup to understand the ref keyword.
But from my experience just look into a computer science course where young students trying to understand for instance pointers in C.
For many students it is just hard to understand. Especially if they are still fighting with the easier concepts of general programming. Its just that what I have concerns about it.

No, i don't want you to remove the whole parameter and introduce a return value so the method has to allocate a list every time^^. Just remove the ref keyword so it becomes just like GetBlocks or GetBlockGroups and many other existing methods where the user has to provide a list where the result gets stored in. Best case scenario will be that the user initializes just one lists that gets used for the rest of the PBs lifetime.
Regarding the best case scenario performance: it will be even better than with the ref keyword because of the dispensable if/else case at the beginning of method

 

@haveachillday, @d4rky1989 is right. There is no reason to have a ref keyword on a type that is already a reference type like lists. There's no gain.

 

ok i see what you mean now; that should be fine

 

Pull request is now fully debugged plus a couple new states. the returned ore marker list is very close to the visible hud markers; differing only by a few meters. Ive also tweaked the voxel updating method to get ore markers even when:

• A player is not present,
• there is no antenna making visible ore markers.

 

hi @DoubleCouponDay
you literaly made what i was trying to create as a mod as it seems that your request didnt make it in the last modapi update

do you, by chance already made it work as a mod?
im setting up vs atm but humble over shitloads of outdated information and lack of documentation (also joined space engineers only 2 weeks ago)

so if you havent, would you point me to some information on how to actualy create a workshop mod that would be able to achieve this?

Thanks in advance!

 

@Azunai Pull requests have a very low acceptance rate. you have to know a guy to get anywhere. I talked to a dev and he was thinking about implementing something similar. It was planned for the previous mod api update but wasnt completed in time.

I think the only way to take matters into our own hands is by making a plugin. plugins must implement VRage.Plugins.IPlugin in order to update. You could copy all the files from my pull request, change all the names BUT I have no idea how you would tell the programmable block to consider your plugin as part of the ingame API. make a new PB and new ore detector?

 

i feel like that might hurt other mods affecting the original PB, broken refs etc if you just add a second PB version to the game banning the original one
also, a plugin cant be distributed through steam workshop afaik?
and i guess it would be requiered server & clientside? (no experience here)

 

harder for users to install but not by much. They have to write a start command through library > properties > general > set launch options > '-plugin "pluginsdirectorysomewhere/plugin.dll"'
. I havent tested with multiplayer objects such as putting a block inside the plugin. would be interesting to try

I haven't seen anything in writing (steam terms of service) that prohibits distributing dlls on the workshop.

section 6. User Generated Content:
https://store.steampowered.com/subscriber_agreement/

 

ah only read this:
https://spaceengineerswiki.com/Modding_Guide#Plug-in_DLL_mods