localhero oxp ALPHA

Post by **Eric Walch** » Sat Feb 16, 2008 12:48 pm

Svengali wrote:
Hoopy wrote:
Am i right in thinking that the OXP can only be triggered in confederacy stations?
Yupp. That's right.
I'm in galaxy 4 and it doesn't have a single one!...Guess i need to buy a galactic hyperdrive...
Maybe you should do this. But maybe there is another Oxp placed in your current galaxy - you could do the missions there and if you have done it you can switch to galaxy 5.

In galaxy 4 there are no confederacy and no dictatorships. This is the galaxy were I started writing and testing UPS. That is the main reason I didn't choose any of those two for my missions.

Svengalii,
nice changes. Ships using real voice when being attacked. It all looks very well. But there is a tiny bug in the missiontext.plist. In the second last line a colon is missing. On the mac this logs as a syntax error. My mac also refuses to use the plist and thus your mission screen opens as an empty screen with only the picture present.

Code: Select all

	LOCALHERO_MISSIONCHOICE = 
	{
		LOCALHERO_ACCEPTED = "Yes, I will.";
		LOCALHERO_REFUSED = "No, I won't.";
	}
}

should be

Code: Select all

	LOCALHERO_MISSIONCHOICE = 
	{
		LOCALHERO_ACCEPTED = "Yes, I will.";
		LOCALHERO_REFUSED = "No, I won't.";
	};
}

On windows it must work fine else you would have noticed it. My experience is that when a plist has an syntax error, the whole plist is ignored on a mac. (I just double checked for random hits: that one is working on the mac with an syntax error in the plist)

Svengali · Post by **Svengali** » Sat Feb 16, 2008 1:04 pm

Eric Walch wrote:
nice changes. Ships using real voice when being attacked. It all looks very well.

Thanks Eric. This was implemented in the 1.69.x version too. I just have re-enabled it in the latest version. So I've discarded the missionVariables that were used before. The ship-script uses his own ones. And they are only local_variables.

Eric Walch wrote:
But there is a tiny bug in the missiontext.plist. In the second last line a colon is missing...
On windows it must work fine else you would have noticed it.

Thanks again. And you are right. Windows hasn't recognized this. It was the attempt to use the open-step architecture for missiontext.plist and descriptions.plist and it is working well. I've changed it and I'll upload the corrected version in a few minutes.

JensAyton · Post by **JensAyton** » Sat Feb 16, 2008 1:20 pm

Eric Walch wrote:
On windows it must work fine else you would have noticed it. My experience is that when a plist has an syntax error, the whole plist is ignored on a mac.

This is true. For extra happy fun time, GNUstep and Cocoa have different ideas of what constitutes a syntax error. For instance, Cocoa allows the root dictionary of a plist to be declared without surrounding braces, but GNUstep does not.

Hoopy · Post by **Hoopy** » Sat Feb 16, 2008 2:10 pm

@matt634: can i have 5000 for a G Hyperdrive please?

I've done all the other missions in galaxy 4 (it's my 2nd time here) so it'll have to be off to G5.

Svengali · Post by **Svengali** » Sat Feb 16, 2008 2:59 pm

Just a quick question:
I'm currently thinking about some speed tweaks, but for that it would be good to know which version is faster executed.

Code: Select all

//Setting up...
missionVariables.localhero_goal = "32"; // missionVariables are strings

1. if (parseInt(missionVariables.localhero_goal) >= 10) ...
2. if (missionVariables.localhero_goal >= 10) ...
3. if (missionVariables.localhero_goal >= "10") ...

I know that this would be no big speed improvement, but if all oxps would use the fastest way it would speed up the whole script executing.

Hoopy · Post by **Hoopy** » Sat Feb 16, 2008 3:18 pm

The differences really should be absolutely miniscule. I'm not a javascript person (although I've bookmarked the relevant wiki pages to read!) but at a guess the last one will be slowest as both strings have to get converted to integers whereas the top one will be a fraction faster than the second. It's just that you're explicitly telling it to parse the int in the first whereas in the second it will realise it's necessary and do it for you. (If it was a compiled language then they'd be the same)

Svengali · Post by **Svengali** » Sat Feb 16, 2008 3:36 pm

Hoopy wrote:
The differences really should be absolutely miniscule.

Yes, but a little bit here a little bit there... (bit, hehe).

Hoopy wrote:
...the top one will be a fraction faster than the second. It's just that you're explicitly telling it to parse the int in the first whereas in the second it will realise it's necessary and do it for you.

Maybe. I'm not totally shure about it. The parseInt has to be interpreted too. It needs time too.

JensAyton · Post by **JensAyton** » Sat Feb 16, 2008 4:41 pm

Mission variables that can be interpreted as numbers are actually automatically converted to numbers when you retrieve them. You can also set a mission variable to a number, and it will be automatically coerced to a string (actually, any object will be coerced to a string, equivalent to calling toString()).

So yeah, option 2 should be the fastest.

Edit: Regarding Hoopy’s comment on implementation details: JavaScript is not interpreted directly, but rather is compiled to bytecode at load time. (The compiled bytecode is stored in Oolite’s cache. The exception is the eval() function, which compiles and then runs its argument, but there should be no reason to use this in Oolite except in the debug console script.) Any overhead related to parsing is thus a one-time cost. However, as it’s a completely dynamically typed language, opportunities for type-based optimizations are very limited. On the other hand, some types such as “small” integers (in the range ±1 billion and a bit) can be special-cased easily at run time.

Post by **Cmdr James** » Sat Feb 16, 2008 4:57 pm

There is also the consideration of writting easy to understand and logical code.

comparing a number that is actually text >= "10" is very odd. In js, it might wok, but in many languages, and therefore to many people trying to read your code it will either not work, or do something different to what you are expecting.

Generally making things fast is secondary to making them 1) right, and 2) easy to understand.

Im sure Knuth said something about the greatest evil in software is to optimize too early, or words to that effect.

Id say the best thing to do, is to convert to a number (parseint) and then compare to a number. It may well be that js does this for you automagically, but it is confusing, and probably just as fast to do it explicitly yourself. This way, you know, and anyone reading it knows that you are dealing with numbers, and understands what is expected.

That said, I work in strongly typed languages mostly, and all this automagical conversion of types makes me feel slightly ill. Im sure other people have different views

JensAyton · Post by **JensAyton** » Sat Feb 16, 2008 5:14 pm

Cmdr James wrote:
Generally making things fast is secondary to making them 1) right, and 2) easy to understand.

Im sure Knuth said something about the greatest evil in software is to optimize too early, or words to that effect.

“Premature optimization is the root of all evil.”

Id say the best thing to do, is to convert to a number (parseint) and then compare to a number.

I got distracted from the point above, but the correct thing to do is to treat the mission variable as a number, if that’s what you put in. This is ~~the documented behaviour~~ the behaviour that would be documented if I’d got around to updating the documentation for globals.

Hoopy · Post by **Hoopy** » Sat Feb 16, 2008 5:39 pm

i'd agree. first thing to do is make the code work in the simplest way possible. then you can test to fix any bugs for edge cases etc. then if you find it runs too slow you can do some work to see which bit needs improving.

Optimising early generally results in you optimising something that's fine, introducing bugs and making it impossible to read so no one can fix them.

but we've gone off the topic here and ventured in software engineering practices 101...

Hoopy · Post by **Hoopy** » Sat Feb 16, 2008 5:42 pm

back on the local hero topic - i'm a bit confused about what exactly i'm meant to do in the first mission.

Am I meant to kill all the pirates? how many is that (is it 45 as mentioned in the briefing?) how do i know when i've got them all? if i go back to the station to check the commander there gets annoyed and the second time the mission ends.

It may be that I'm being thick but i think a longer and more explicit briefing (or maybe just the mission text on the f5 screen needs to be more explict) and some sort of feedback on how i'm doing is required.

and since it's a js OXP I'm finding it hard to work it out by reading the scripts...

Svengali · Post by **Svengali** » Sat Feb 16, 2008 7:48 pm

Hoopy wrote:
Am I meant to kill all the pirates?

It seems you have got the first and introducing message that explains the situation. If you read it - it says step to the SYSTEM DATA SCREEN (F7). There is the mission briefing where you could accept or refuse the mission.

how many is that (is it 45 as mentioned in the briefing?)

The number of 'pirates' depends on the mission number and your personal skill. From 3 up to xxxspoilerxxx. So for the first mission it is between 3 and 6 enemies. And you'll never have to face 45 enemies.

how do i know when i've got them all?

You will receive a message IN_FLIGHT, you will know if you have completed a mission.

if i go back to the station to check the commander there gets annoyed and the second time the mission ends.

I don't think that he is annoyed. He has just expected that you will do your job. From the scripting side it is necessary to generate some extra enemies when you have docked and relaunched, because they are attacking traders and police-ships too. So it is possible that they are involved in a fight far away from the space lane. So the player couldn't find them. After the fight they will return to their 'normal' route, but that would mean a player would have to wait. And docking while you are on a mission? You can. And a question if you want to cancel the running mission is just a normal thing. But if you've docked more than 2 times the mission is aborted.

All Briefing are on the SYSTEM_DATA_SCREEN (as told in the readme), all Debriefings are when you've docked. If an other missionscreen is displayed the script will wait until it's cleared.

Hoopy · Post by **Hoopy** » Sat Feb 16, 2008 8:07 pm

i got the second message ok but i'm not sure if something didn't go wrong after that.

i flew out, killed one and got his escape pod, came back and saved.

I was told to go back out so i did and killed another 4 and came back. they told me i should be out there and that they had escaped.

so i reloaded and killed 9 of them, meaning 1+9 = 10 altogether. i went back and got the same message.

sounds like your point about about a few extra ones getting spawned means you do have to kill more of them!

so i reloaded again, killed a fair few then energy bombed another 10 or so. Then i got the confirmation message.

I think it probably just needs to say something like 'go and kill all harkov's ships in this system. We estimate this will be about x ships.' After every kill it could them say 'y killed, keep going!'. Or maybe just messages like 'that's about half of them dead' or something.

in your PM you asked whether you thought it was took hard. I think it's fine with a cloaking device (you just have to manage shield levels vs energy levels) but would be very hard without it. I like the way it evolves into one continuous dogfight with more ships entering as you kill them off. Just like in an anarchy on the BBC version

Svengali · Post by **Svengali** » Sat Feb 16, 2008 8:19 pm

so i reloaded and killed 9 of them, meaning 1+9 = 10 altogether.

I'll check this. Maybe something is wrong with the bit-shifting (>>>2). Give me just a few minutes.