[resolved]projector.LoadBlueprint() not working?(it does work afterall)

hi im trying to make a script to automatically configure all of the projectors on a structure so i can build a space elevator, each section is welded by a climber and has a projector on it which projects the next section, since blueprints are stored in the projector by value and not by reference i need to constantly update all the projectors to the bottom most version (their are 4 nested sections of slack so the script docent have to run as quickly).

anyway everything is working except for proj.LoadBlueprint(@PATH + NAME); no blueprint is being loaded by the code below, any help on why would be greatly appreciated.

Code:

string PATH = "C:\\Users\\georg\\AppData\\Roaming\\SpaceEngineers\\Blueprints\\local";
string NAME = "Elevator Section\\bp.sbc";

public void Main(string argument) {
	List<IMyTerminalBlock> blocks = new List<IMyTerminalBlock>();
	GridTerminalSystem.GetBlocksOfType<IMyProjector>(blocks);
	
	    foreach(IMyProjector block in blocks){
		IMyProjector proj = block as IMyProjector;
		if(proj != null){
			proj.LoadBlueprint(@PATH + NAME);
			proj.ProjectionOffset = new Vector3I(-11,-28,10);
			proj.ProjectionRotation = new Vector3I(1,0,0);
        } 	
	}
}

--- Automerge ---
never-mind was program error, @Operator was only being applied to path, and PATH was missing final \\ working code below

Code:

string PATH = "C:\\Users\\georg\\AppData\\Roaming\\SpaceEngineers\\Blueprints\\local\\";
string NAME = "Elevator Section\\bp.sbc";

public void Main(string argument) {
	List<IMyTerminalBlock> blocks = new List<IMyTerminalBlock>();
	GridTerminalSystem.GetBlocksOfType<IMyProjector>(blocks);
	
	    foreach(IMyProjector block in blocks){
		IMyProjector proj = block as IMyProjector;
		if(proj != null){
			string file = PATH+NAME;
			proj.LoadBlueprint(@file);
			proj.ProjectionOffset = new Vector3I(-11,-28,10);
			proj.ProjectionRotation = new Vector3I(1,0,0);
        } 	
	}
}

 

Wow, I didn't know you could load projections from the programmable block. Cool.

Looking at the coding, it seems that you're loading blueprints into every section of space elevator and leaving them on. After a while, this will affect your sim speed.

In your foreach loop, skip all projectors that are off. Load blueprints into projectors that are on. Check to see how many blocks are unwelded in the projector. If the number is 0, then turn the projector off.

That way, you'll never have more than two projectors live at any instant and theoretically on one on at a time. If you set the projector (in the blue print) NOT to store/keep the projection you'll save some memory space as well.

 

the projector is unfortunately quite poorly documented compared to all other blocks in the game, but yeah its possible, and as for your suggestion it would work for more conventional elevators but our section projections contain extensions for rings, a docking station, and maintenance drones, which are welded separately and not on all sections, instead i just update the name so as to not be constantly reloading projections (this SERIOUSLY KILLS) FPS, but having the projectors active isn't that much of a problem, new code im using below, im building this in survival and i will post in another thread when its done.

Code:

string PATH = "C:\\Users\\georg\\AppData\\Roaming\\SpaceEngineers\\Blueprints\\local\\";
string NAME = "Elevator Section\\bp.sbc";

public void Main(string argument) {
	List<IMyTerminalBlock> blocks = new List<IMyTerminalBlock>();
	GridTerminalSystem.GetBlocksOfType<IMyProjector>(blocks);
	
	    foreach(IMyProjector block in blocks){
		IMyProjector proj = block as IMyProjector;
		if(proj != null){
			if(proj.CustomName != "UpdatedProjector"){
				proj.SetCustomName("UpdatedProjector");
				string file = PATH+NAME;
				proj.LoadBlueprint(@file);
				proj.ProjectionOffset = new Vector3I(-11,-28,10);
				proj.ProjectionRotation = new Vector3I(1,0,0);
			}
        } 	
	}
}

 

@bertie2 I would recommend not using this method. It is not supposed to be available, it's a mistake. It will be removed, it's only a matter of time. No disk access is supposed to be available.

 

While you're fixing that, can we allow PB's to call blueprints from the Steam Workshop by their serial number? More complex creations often use projectors and may have projected grids. Like the raycasting, add a cooldown time between calling workshop requests via the PB to prevent spamming and a check to see if that blueprint exists or is accessible. Is there a way around subscribing? Servers do not have to subscribe to a mod to call it, so it could function the same way.

 

could we have any type of method for loading blueprints into a projector, even if it means transferring it from an already built and manually loaded projector? like a simple getBlueprint and setBlueprint?, this would require no access to the file system or steam repo while still providing 99% of the functionality.

 

Perhaps something like: block.setBlueprint(1091748166, true);

1091748166 equals the workshop item number
true/false equals whether to ignore mod'ed blocks if mod isn't installed or to abort loading the blueprint if the mod is not present

The workshop item number would be checked to see if it's a blue print for a grid, the right size, etc.

There would be a cool down time before another blueprint could be loaded. This would be a certain number of seconds after a blueprint had been loaded via the setBlueprint method.

getBlueprint would simply return the integer of the workshop item number.

 

Just to put forward my suggestion for the simplest possible solution for an in game implementation 2 methods PB.getBlueprint(void) could return whatever data structure is used in the game engine to store blueprints or a safer sanetized variation of it (2d array of size n by 3 with x,y of block + block I'd? (I assume the way projectors work with storing block data requires a somewhat more complex implementation but it must already have been done once to implement any sort of blueprint loading)) ,Or void if their is an error (like no projection is currently loaded), And PB.setBlueprint(blueprint) which takes one of these stucts and returns 1 if successful or zero if not.
This would have no out of game interaction, no disk interaction but would still allow for the management and saving/loading of blueprints via arrays of physical in-game PB's as library's which would also look pretty cool.

 

From a end-user perspective, the PB is a way to add features to the vanilla game while still maintaining compatibility within the context of a vanilla game. MMaster's Automated LCD screens is a great example. Whiplash's thruster control for sub-grids. Functionality that Keen and its developers have no interest in or cannot justify the cost to can be expressed by end-users willing to spend the time programming. Protecting the end-users security is a #1 priority. Security vulnerabilities have to be addressed. However, the more robust the interface of the PB, the more functionality the end user can get out of the game.

The PB doesn't exist solely in the game world as it affects the end-users experience. End users aren't part of the game world. They are an external force acting upon the game world. Loading blueprints from the workshop into a projector is something that the end user can do manually. When a blueprint is loaded into a projector on a server, the server has to download the blueprint. When a server is set up with a mod, the only way to do so is to type in the item number MANUALLY of the workshop item. So there has to be some sort of trust between the game and the workshop. Blueprints HAVE to be stored on the server if they are populated in a projector. In my opinion, having the PB load a blueprint into a projector is just as risky as a player loading one in. As long as the PB can't spam the loading of blueprints at a rate faster than an end-user can, then the risks are the same.
--- Automerge ---

From what I've seen in the .sbc, items that are being projected have their block information stored within the projecting grid's data. All of the information that would normally be stored in the grid's definition are stored within the projector's definition.

 

For loading blueprints. My suggestion would just be to:

A) subscribe to one
B) each subscribed bp would then be stored in an array by an int value (1, 2, etc)
C) you could use a GetBPSubs() function to display the list on a screen, which also sets button panels to provide user input (ie. Code waits for selection by user, each button on panel corresponds to #1, #2 etc.)

D) after making a selection, that blueprint is passed to the next piece of code, which loads the bp and sets the button panels back to "argument mode"

Or something like that.

 

With that attitude you can say that nothing in the game exists solely in the game world, and you can remove pretty much all forms of immersion. The point of the PB from an end user's perspective is to add automation to your ships. Yes, it adds features compatible with vanilla, in the same way (but more powerful) than you can with a timer. But it still fights to maintain the vanilla game rules (with varying success, but it still tries - one wrong does not make another right and all that).

If you want something from an out-of-game context, you use a mod script. That's what they're for.

To be blunt, this is not something that is under discussion and not something that will change. It's a core game thing

 

I would also like to have multiple blueprints on one projector and be able to change them via programming block.

 

@JoeTheDestroyer This is specifically what the difference is between a pb and a mod script. Without this concept we wouldn't have a programmable block. Yes, I was part of strengthening this intention, but it was intended this way long before I was involved. I just happen to strongly agree with it.

If you disagreed with my bluntness, I am sorry, but I feel I have deserved that privilege where the PB is involved by all the work I have done for it. There's barely any Keen code left. Only now with Inflex have we gotten someone with Keen that is willing and able to take over - thankfully.

 

@Malware My apologies for the delay, I visit the forum rarely these days.

No, the difference between a pb and mod script is that the former should be limited to the same game rules the player is (with respect to manipulating blocks). But consequently, it should also have the same capabilities as a player in the same role. Conversely, mod scripts exist to alter the game rules.

Where I disagree with you (and Inflex) is that the PB should also be constrained by "immersion" concerns. From my perspective, arguing that the PB should not be able to load blueprints from files (NOT the filesystem) or from the workshop because they don't "exist" in the game world is silly. The player (character) also only exists in the game world. Same for the projector block. Yet we can manually load blueprints into the projector from both those sources. Any "immersion" that might have been lost from the PB having the capability was already lost by the player being able to do so. Generally speaking, I find "immersion" to be an incredibly weak argument when it comes to limiting game features. Weighed against the "fun" I imagine I could have by being able to alter the blueprints in a projector, I would toss "immersion" out the window without hesitation.

You probably do not recall, but we have had this argument before. If I recall correctly, at the time the discussion was whether various game settings (in particular, the cargo multiplier) should be available to the PB. I did not initially reply in this thread because it doesn't seem like we will be able to come to a consensus on this, so no point in arguing. But I do still disagree.

 

You misunderstand the argument. It's has nothing to do with whether the blueprints exist or not. Immersion is not a part of the argument. Denying any kind of disk access is a security thing. Blueprint access itself is possible, but not with existing features. I myself have been making suggestions on how to accomplish this within the rules of the game, but you know Keen's priorities with regards to the Pb .

Coming to a concensus is also irrelevant, because it won't change anything, it'll just be overridden at Keen's anyway. Convincing me or Inflex in this matter won't change a thing. You're killing the messengers. And also because you describe the Pb vs Mod exactly how I would. We're not in a disagreement here. It's just that the specific feature you're asking for does not exist. The exposed method requires knowledge of the end user's paths. It doesn't work for this purpose. Nobody is saying that blueprints shouldn't be available for scripting. Just that the currently accessible method is unintentional, not designed for the PB and thus generally problematic.

 

Still the function exists, but I am disappointed to know that I should avoid this. I really wanted to have the option to switch blueprints.

And you totally miss the point of your opponent. Nobody tries to convince anyone that FS access is good. I totally agree that in terms of immersion and UX it's a very nice feature to have, as it mirrors the players ability to switch blueprints. I often see developers blah-blaying about best practices, finding 100 reasons of not to do the coding, instead of proposing a solution for the problem (I do this too).

My point is: for being constructive, you either propose the solution for a technical issue (e.g. load blueprint not from FS but deserializing it from some in-game source, whatever) or give a reason why the feature should not exist at all. I think the correct way to answer was like: it's a nice feature to have, but the way the blueprint system is implemented we can't have it sandboxed easily, this function will be removed and we aren't going to replace it as we have more important features to work on (and it's totally OK).

For example, keeping cross-grid reference was an unintended and dangerous feature, you removed it and gave us antenna cross grid comm solution, that was constructive (and a big amount of work).