Scripters cove

[spara]

Sorry, no, I don't even know what you are trying to do or what problem you are trying to solve. I don't want to combine two OXPs, and my OXP should work even if no naming OXP is installed (I suppose there are more than one of them). In this case, only "my" ships would have names. The only problem I had with this was more of a theoretical nature, that I'm kind of wasting cpu time for renaming a ship that already has been named by another OXP. Ignoring this, it just works fine (apart from the texture changing part).

Academically speaking, the method I'm describing allows you to run your event handler before randomshipnames giving you full control of running order. That's sort of what you asked, a way to make sure that your naming precedes randomshipnames. And naturally you would need to do checks for the existence of randomshipnames, but that's not a biggie.

Currently there are no other generic naming OXPs around. Some OXPs add ambiance ships that they name themselves. You probably don't want to mess with those.

Btw, randomshipnames is a little outdated. It uses and checks displayName, but the with the current version of Oolite, using uniqueName would be more appropriate.

[spara]

Code: Select all

materials = {
			"yah_griff_no_shader_screen.png" = {
				diffuse_map = "station_ads_dock_frame.png";
			};
		};

"yah_griff_no_shader_screen.png" is, as I understand it, not a filename but kind of a key...

It refers to the texture definition inside the model file (dat file).

[Fritz]

Academically speaking, the method I'm describing allows you to run your event handler before randomshipnames giving you full control of running order.

Ah, ok, now I'm starting to understand!

Currently there are no other generic naming OXPs around.

That seems strange, because the names of Random Ship Names are too long for memorizing and for use with Comms Pack A. I changed it completely to get shorter names that could be found on real life ships too (and that don't reveal if somebody is a pirate or a honest trader). And when I did this, I had the idea of giving the bigger freighters company-specific naming schemes, like it is done in the real world (like "<city name> Express" for Hapag-Lloyd ships or "<first name> Mærsk" for Mærsk ships). And then I had the (bad?) idea of making company textures too...

Some OXPs add ambiance ships that they name themselves. You probably don't want to mess with those.

I want to make it as simple as possible. If the ship has been given a name already by any OXP, I'll change it. If another OXP doing something with traders is executed after my OXP, doesn't check for existing names, and renames "my" ships, it probably won't be compatible with my OXP for other reasons too.

Btw, randomshipnames is a little outdated. It uses and checks displayName, but the with the current version of Oolite, using uniqueName would be more appropriate.

I've noticed that, and I'm using uniqueName. It is simpler because I don't have to replace the old name looking for hyphens, colons etc. I just do ship.displayName = ship.shipClassName + ": " + myName;

Edit: That's kind of nonense I wrote. But would displayName change if I wrote my name only to uniqueName?

[Norby]

I have to read the existing material list with ship.getMaterials(), store it in a object variable, then change the parts of the object I need to change, and then rewrite the complete object with ship.setMaterials().

An untested idea:

Code: Select all

var m = ship.getMaterials();
for(var key in m) {
	if( m.key.indexOf(".png") > -1 )
		m.key.diffuse_map = "your.png";
}
ship.setMaterials( m );

You should do the same with getShaders and setShaders also for ships with shaders, where use textures instead of diffuse_map and fill with ["your.png"] (including brackets) due to it is an array of strings, not a simple string.
http://wiki.alioth.net/index.php/Materi ... dictionary
http://wiki.alioth.net/index.php/Shader ... ng_shaders

Regarding randomshipnames I think spara's original suggestion is the best, add this into all of your ship definitions:

Code: Select all

"script_info" = {"randomshipnames" = "no"; };

[Cody]

... randomshipnames is a little outdated.

<nods> It could do with an update - and I think it lacks assassin-type names?

[spara]

Some OXPs add ambiance ships that they name themselves. You probably don't want to mess with those.

I want to make it as simple as possible. If the ship has been given a name already by any OXP, I'll change it.

If you at some point want to release your OXP to the public, you don't want to do this. It might be crucial for some OXPs that the name of the ship does not change. They might be checking the name or it's essential for identification for example.

If another OXP doing something with traders is executed after my OXP, doesn't check for existing names, and renames "my" ships, it probably won't be compatible with my OXP for other reasons too.

Currently the only OXP you need to be aware of is randomshipnames. And it does it's best not to break anything.

Your idea sounds good. Maybe at some point you could make an alternative to randomshipnames? Or they could complement each other? Btw. Norby kindly added a hook to the randomshipnames for me to use, that allows adding a secondary naming engine to it. I planned on using it to inject ship names from Rescue Stations OXP and Random Hits OXP into the Ooniverse, but never used it. Maybe you could use it?

[Fritz]

An untested idea:

Code: Select all

var m = ship.getMaterials();
for(var key in m) {
	if( m.key.indexOf(".png") > -1 )
		m.key.diffuse_map = "your.png";
}
ship.setMaterials( m );

Thank you, I'll try it. And now at least I have an Idea how to deal with this kind of data structure.

You should do the same with getShaders and setShaders also for ships with shaders, where use textures instead of diffuse_map and fill with ["your.png"] (including brackets) due to it is an array of strings, not a simple string.
http://wiki.alioth.net/index.php/Materi ... dictionary
http://wiki.alioth.net/index.php/Shader ... ng_shaders

Regarding randomshipnames I think spara's original suggestion is the best, add this into all of your ship definitions:

Code: Select all

"script_info" = {"randomshipnames" = "no"; };

Most of this currently isn't a problem for me because I don't use my own ship definitions. For now, I just want to change the core Anacondas, Boas, Boa 2s, and Pythons. They all have structurally the same material definition, with the exception of the Anaconda which has an additional "Guns" element (which should remain unchanged).

[Norby]

allows adding a secondary naming engine to it.

It is based on roles so if you add a unique role for your ships then you can define your own rename function.
http://wiki.alioth.net/index.php/Random ... me_engines

[Fritz]

I want to make it as simple as possible. If the ship has been given a name already by any OXP, I'll change it.

If you at some point want to release your OXP to the public, you don't want to do this. It might be crucial for some OXPs that the name of the ship does not change. They might be checking the name or it's essential for identification for example.

Yes, but then I would have to recognize if a name has been given by a special OXP or by Random Ship Names or something similar. That would only be possible if the special names had some common properties, but even with my fixed-scheme "company names" that would be difficult in some cases. To be perfect, there should be something like a ship.remarks property that could be written by OXPs to "claim" their ships. But most OXP will use their own models, shipdata entries and/or roles, so only changing the core trader freighters shouldn't be a problem in many cases.

Currently the only OXP you need to be aware of is randomshipnames. And it does it's best not to break anything.

I noticed this. I kept the checking parts for my "Shorter Ship Names" OXP (in fact, most of the shipSpawned function is identical), although I didn't understand everything of it.

Your idea sounds good. Maybe at some point you could make an alternative to randomshipnames?

When I think it's good enough, I won't hide it! The technological part is working fine already but I still have to find some additional naming schemes and/or adjust some probabilities to reduce the appearing of similar sounding names. I could even keep the company naming part inside and deactivate it if my freighter OXP is installed.

Or they could complement each other?

I don't think so. To combine them into one OXP would fail because of the completely different naming rules. The only solution would be to do a random split up very early, so that x% of the ships get "random ship names" and y% get "shorter ship names". Simpler would be to install both OXPs, but each of them would have to be modified so that it only affects half of the ships and leaves the other half unchanged.

Btw. Norby kindly added a hook to the randomshipnames for me to use, that allows adding a secondary naming engine to it. I planned on using it to inject ship names from Rescue Stations OXP and Random Hits OXP into the Ooniverse, but never used it. Maybe you could use it?

Perhaps. But doing the naming separately from the texturing would cause new problems. I would have to read the texture filename to find out which naming scheme has to be used. And I have some ideas in my head that would reduce the naming part to a minor issue, so I don't want the OXP to be connected too closely to a naming OXP.

allows adding a secondary naming engine to it.

It is based on roles so if you add a unique role for your ships then you can define your own rename function.
http://wiki.alioth.net/index.php/Random ... me_engines

As I said, at least in the first version I just want to change the looks and names of the ships, so I don't have to bother about their AI and behavior. The modified ships remain "traders" and should behave like any core trader. I perhaps will include some additional functionality later, that would require different roles, but that will probably be far in the future.

[spara]

...at least in the first version...

Indeed. Keep it tidy first. When you want to expand, publish or develop further, then you need to consider how your addition will fit (both technically with other OXPs and from player's perspective) into Multitude of Ooniverses. We'll be happy to help at that point, the better OXPs play together, the better the game.

[Fritz]

An untested idea:

Code: Select all

var m = ship.getMaterials();
for(var key in m) {
	if( m.key.indexOf(".png") > -1 )
		m.key.diffuse_map = "your.png";
}
ship.setMaterials( m );

This doesn't work - one thing is that it must be "m[key]" instead of "m.key" of course - but it gave me the idea. It needs to have subloops for subobjects, because a simple loop only gives two objects in the top level: key="Hull" and key="Engines":

Code: Select all

Hull: object
    diffuse_map: filename 
    specular_color: ...   
    shininess: ...
    emission_map: subobject
         name: filename
         extract channel: ...
    emission_modulate_color
Engines
    ...

I have to change the values for the keys "diffuse_map" and "name". I'm not sure yet, but it probably won't need loops at all, because the keys and subkeys have fixed and known values: m["Hull"].["diffuse_map"] and m["Hull"].["emission_map"].["name"].

Let's see if I can get this running this night...

[Fritz]

This went faster than I expected!


My code is now like this:

Code: Select all

var hullTexture = shipType + "_diffuse_" + companyKey + ".png";
var enginesTexture = shipType + "_subents_" + companyKey + ".png";
var materialList = ship.getMaterials();  
materialList["Hull"]["diffuse_map"] = hullTexture;
materialList["Hull"]["emission_map"]["name"] = hullTexture;
materialList["Engines"]["diffuse_map"] = enginesTexture;
materialList["Engines"]["emission_map"]["name"] = enginesTexture;  
ship.setMaterials(materialList);

I wonder if it would affect performance if I kept the emission maps as they are - the "a" channel is the same in all textures.

[phkb]

I'm trying to work out what events I need to watch to know if I ship that I spawn programatically is not in the system anymore. Does it make more sense to just set a timer and check "isValid", or should I hook into shipDied, shipRemoved, shipWillEnterWormhole, and shipWillDockWithStation?

[Wildeblood]

I'm trying to work out what events I need to watch to know if I ship that I spawn programatically is not in the system anymore. Does it make more sense to just set a timer and check "isValid", or should I hook into shipDied, shipRemoved, shipWillEnterWormhole, and shipWillDockWithStation?

If you've spawned the ship, are you referring to a ship script or a world script? Is there going to be only one such ship at a time, or several?

If you go with a timer, consider isInSpace rather than IsValid.

[phkb]

There'll only be one ship. I was imagining using ship.script.shipDied = myfunctionName; etc to attach to the individual ship script events. It's just that I want to make sure I cover all the bases, and it might just be simpler to monitor isValid or, as you say, isInSpace.