Oolite Bulletins

Posted: **Sun Aug 02, 2009 9:05 pm**

station.dockPlayer()

Is not being put in because ?

Posted: **Sun Aug 02, 2009 9:27 pm**

... because Berlios seems to be down for two days straight now...

Edit: Berlios is back in business. It's in.

Posted: **Mon Aug 03, 2009 6:33 pm**

another_commander wrote:
... because Berlios seems to be down for two days straight now...

Edit: Berlios is back in business. It's in.

ahh thanks..

Posted: **Mon Aug 03, 2009 10:04 pm**

Not sure if this is an Oolite bug or intended to work that way, but shipdata-overrides.plist and shipyard-overrides.plist only do anything if their entries are also there in other oxp's shipdata- and shipyard.plists.

I would rather have the -overrides.plist's work like normal shipdata.plists and shipyard.plists but in addition override entries of other plists if they are there.

Is this doable? It would obviously be very useful for OSE.

Posted: **Tue Aug 04, 2009 8:37 am**

One other thing.

Not entirely a scripting request, but a bugsquashing fast fix for the devs.

Could you please put this "item of equipment":

Code: Select all

<array>
                <integer>99</integer>
                <integer>99999999999</integer>
                <string>Bugsquashing Dummy Thingy</string>
                <string>EQ_BUGSQUASH</string>
                <string>Squashes the double equipment appearing because Scanner Filtering is last in line bug.</string>
        </array>

... into the core game equipment.plist - then no one has to fiddle along in the code, I don't have to issue a "core patch" for OSE and the double "Military Scanner Filtering" on F3-screen bug is history.

Please?

Cheers

L

Posted: **Tue Aug 04, 2009 10:15 am**

Disagree. This is not a correct fix, just duct tape patchwork. This kind of solution should generally be avoided and a proper way to fix problems should be investigated instead.

Posted: **Tue Aug 04, 2009 10:52 am**

And, just to refresh everybody's memory, forcibly enabling military scanner & countermeasure was not particularly encouraged by anyone on the dev team: IIRC, some unspecified possible bugs were mentioned by yours truly at the time...

The reason this specific equipment exists at all, is that once upon a time there was going to be a new standard mission - along the lines of constrictor hunt & thargoid plans, which would award the new toys to the player.

All this to say that any bug affecting equipment that is not even supposed to exist is not very likely to be worked on by the devs, at least not until the corresponding mission emerges out of vapourware!

If anyone without dev access has the time & is willing to work on squashing this parsing bug, by all means, do submit a tested patch on the forum, and I'm sure we will be more than happy to include it in trunk!

Cheers,

Kaks

Posted: **Tue Aug 04, 2009 11:29 am**

Kaks wrote:
And, just to refresh everybody's memory, forcibly enabling military scanner & countermeasure was not particularly encouraged by anyone on the dev team: IIRC, some unspecified possible bugs were mentioned by yours truly at the time...

And as I wrote earlier: On a clean system like mine the bug is not visible and the demo file from Lestradea shows the equipment only once. (The original stays hidden) Seeing two only happens when tampering with that equipment in different contradictory ways like happens with RS. For one that kept its system free from buggy stuff there is no visible problem here.

Posted: **Tue Aug 04, 2009 11:51 am**

Eric Walch wrote:
On a clean system like mine the bug is not visible and the demo file from Lestradea shows the equipment only once. (The original stays hidden) Seeing two only happens when tampering with that equipment in different contradictory ways like happens with RS. For one that kept its system free from buggy stuff there is no visible problem here.

My problem with this is that I do not understand these sentences

I don't get what you mean with a "clean system", "different contradictory ways of tampering" and "free of buggy stuff".

No offence, I really don't understand what this is supposed to mean. I make available a piece of equipment that wasn't before, but is working as intended on everybody's system who is testing it, and there is one cosmetic problem (the double show-up) which happens on my system (and also A_C's i.e., btw) ... if making this equipment available as the singular only micro-oxp in my AddOns folder.

Please, no offence meant, really, I don't understand what you are saying but would very much like to.

L

Posted: **Tue Aug 04, 2009 12:39 pm**

Lestradae wrote:
Please, no offence meant, really, I don't understand what you are saying but would very much like to.

You both set the technical level from 99 to a level at which the original equipment becomes buyable as well you add a duplicate of this equipment.
When you would just add the duplicate, the original stays invisible. Or better: use the system to set the level of the original equipment lower as the official way. Using either gives no visible bug but you use both ways simultaneously.
With "clean system" I mean among others a save file without an history of other changes.

Posted: **Tue Aug 04, 2009 1:20 pm**

To add to Eric's post. Don't include an entry for the item in your OXP's equipment.plist at all, as its already in the native equipment.plist here:-

Code: Select all

	<!-- next item has a TL too high to be available at all -->
	<array>
		<integer>99</integer>
		<integer>1500000</integer>
		<string>Military Anti-Scanner Countermeasures (MASC'M)</string>
		<string>EQ_MILITARY_JAMMER</string>
		<string>Developed from experimental cloaking prototypes, this jamming device stops enemy ships from scanning your craft.</string>
	</array>
	<!-- next item has a TL too high to be available at all -->
	<array>
		<integer>99</integer>
		<integer>250000</integer>
		<string>Military Scanner Filtering</string>
		<string>EQ_MILITARY_SCANNER_FILTER</string>
		<string>Filters out the jamming signals from MASC'M devices.</string>
	</array>
</array>

Instead, when the player docks at your special station temporaly set the available tech level to 17 (or whatever the tech level of your special station is). When the player launches from your special station re-set it back toi 99. That way, the desired effect of only having these items available at the special RS station is achieved, without the double listing bug, because you only have one entry in equipment.

This is how I made the special Gravition Missile available in Assassins only at the Rebel Outpost.

Eg:-

Code: Select all


{ 
							conditions = ("mission_assassins equal assassins_twentyone", "missionChoice_string equal twentyonea"); 
							do = ( 
								"setMissionImage: assassins.png",
								"setMissionMusic: none", 
								setGuiToMissionScreen, 
								"addMissionText: room99",
								"set: mission_assassins assassins_STAGE11deliver",
								"resetMissionChoice",
								"set: mission_TL_FOR_EQ_GRAV_MISSILE 1",
								"setMissionDescription: assassins_header20b" 
							); 
						},

In assassins when the player docks at the Rebel Outpost, there is no power so he cannot get to the F screens and has to solve a text adventure to restore power and make it safely back to his ship before he can access the F3 screen. The last "room" in the text adventure unlocks the missile so it appears on the F3 screen. When he launches its reset back to 99. For your pourposes you'd just need the mission_TL_FOR_ command to set to the tech level of your station when docked and then reset to 99 when launching.

Posted: **Tue Aug 04, 2009 2:35 pm**

Thanks guys, very slowly I am starting to understand what you are actually on about!

So the problem is this: Whenever an item of equipment is in more than one equipment.plist in the game, the items don't overwrite each other in load order as for example ships do, but they all stay on.

The duplicates are not shown on the equipment screen, but are there and might do unwanted things in the game. As the Military Scanner Filtering is last in the core equipment.plist, this process of hiding the duplicate EQ_ somehow breaks down and both first and second item version become visible on the F3 screen.

Therefore it might be a better and less bug-prone solution that I somehow alter the core items I want altered without putting them in another equipment.plist!

I want to add at that point that the only bug that anyone has noticed so far with these items is the double appearance on the F3 screen bug, though ...

OK, what about if I solve the Military Scanner Jammer with a .js that goes like this:

Code: Select all

this.reset = function()
   {
   if(missionVariables.ANYTHING = null)
      {
      EquipmentInfo.infoForKey("EQ_MILITARY_SCANNER_FILTER").effectiveTechLevel = 16;
      }
   }

... and then I never define the mission variable ANYTHING, therefore it is always null, therefore the equipment is always TL 16 (internally, 17 externally) instead of 99 but I need no second equipment.plist entry.

Could that be used as a solution?

EDIT: No answers, just questions

I tried this out but didn't work. Well, equipment.plist ducttape patch it is then if no one can help me out with a no doubt better solution I can actually implement ...

Posted: **Thu Aug 06, 2009 11:43 am**

Back to the former topic:

Will ...

Code: Select all

station.dockPlayer()

... also work for auto-docking with carriers, actually really any dockable entity?

Because that would be needed if the transfer shuttle idea should work out completely.

Thanks in advance

L

Posted: **Thu Aug 06, 2009 1:17 pm**

Lestradae wrote:
Back to the former topic:

Will ...
Code: Select all
station.dockPlayer()
... also work for auto-docking with carriers, actually really any dockable entity?

Because that would be needed if the transfer shuttle idea should work out completely.

Thanks in advance

L

I just tested it, it works, i docked to a behemoth just fine.

Posted: **Thu Aug 06, 2009 1:21 pm**

Hurray!

Go, Frame, go!

(To the festival first, there's a real life too. I just remembered

)

Oolite Bulletins

Scripting requests

...

..

..

Re: ..

..

..

Re: ..

..