Progress
Moderators: winston, another_commander
- Tricky
- ---- E L I T E ----
- Posts: 821
- Joined: Sun May 13, 2012 11:12 pm
- Location: Bradford, UK. (Anarchic)
Re: Progress
Does this interfere with track_contacts in shipdata?
Re: Progress
It won't track contacts with exceptions, but others will continue to be tracked.Tricky wrote:Does this interfere with track_contacts in shipdata?
- Norby
- ---- E L I T E ----
- Posts: 2577
- Joined: Mon May 20, 2013 9:53 pm
- Location: Budapest, Hungary (Mainly Agricultural Democracy, TL10)
- Contact:
Re: Progress
Cim, you are a mind-reader. I just made a workaround in Escort Deck to avoid the non-stop collisions if there isn't about 30m between the main ship and escorts, which looks too much in closeups. So I place escorts near and move further back after landing in 1m steps at each collision which result a bit smaller but still too big gaps (at least no more escorts killed by the owner accidentally ).cim wrote:exclude ships from collision tests against each other
Then in parallel you make a real solution without I ask, brilliant!
Working well in my tests, just I put a
logcontrol.plist
into my package with collision.except=no;
else I got about 1MB log in every minutes and CTDs after 1-5 minutes, but no problem without log.Re: Progress
The debug log lines will be gone in tonight's build.Norby wrote:collision.except=no;
-
- Quite Grand Sub-Admiral
- Posts: 6667
- Joined: Wed Feb 28, 2007 7:54 am
Re: Progress
Following some recent discussions regarding ambient level lighting, the JS read/write property
The property is set on a per-system basis and the default is still whatever is present in the planetinfo.plist
Since ambientLevel is a per-system property, it will be reset to the new system level whenever you hyperspace or enter witchspace. If you are planning to use it for setting light levels universe-wide, you must be aware of that.
system.ambientLevel
has now been implemented (commit 2962ab9) and will be available for testing in the next nightly.The property is set on a per-system basis and the default is still whatever is present in the planetinfo.plist
ambient_level
property, or 1.0 in case of absent value. The light level is now capped at 10.0, which is more than enough to light up the existing universe plus a few more parallel ones.Since ambientLevel is a per-system property, it will be reset to the new system level whenever you hyperspace or enter witchspace. If you are planning to use it for setting light levels universe-wide, you must be aware of that.
Re: Progress
Quite a few bugfixes in tonight's build. A couple of substantive changes, too.
Scenario restrictions can now be more complex. You can combine different restriction types, and you can also tell Oolite not to process a core game plist while in a specific scenario. (For example, if you have a scenario where you don't want the player to be able to buy a Cobra III, you could exclude the core
The
Scenario restrictions can now be more complex. You can combine different restriction types, and you can also tell Oolite not to process a core game plist while in a specific scenario. (For example, if you have a scenario where you don't want the player to be able to buy a Cobra III, you could exclude the core
shipyard.plist
so they can't). [wiki]scenarios.plist[/wiki] has more details. Scenario authors can get themselves into a larger than normal mess with this feature, as some entries in some of the plist files are required (e.g. if you override descriptions.plist
- not recommended! - you must respecify all the entries used by core Oolite, or if you override trade-goods.plist
you must redefine goods keyed "slaves", "alloys" and "minerals") - but it means that people developing scenarios that aren't just an addition on top of the core Oolite will have a much easier job of clearing out Oolite's defaults.The
corona_flare
property has also been updated a bit, so that its appearance doesn't depend so much on the star's radius (for a given corona_flare value, the actual radius of the corona was proportional to the square of the radius of the star). Appearance within the star radii and corona_flares in the core game should be mostly unchanged, but if you were using larger values for either you might notice a difference.- Amah
- ---- E L I T E ----
- Posts: 486
- Joined: Tue Aug 28, 2012 8:05 pm
- Location: aboard the Laenina Crowne - Yasen-N class space freighter
- Contact:
Re: Progress
I'm editing the noshaders oxp/oxz to make them v1.81 compliant. I was able to mend most warnings so far.
Don't know if it's the right place to ask, but I have got following my problem. Refering to the wiki I was able to setup up conditions via conditions key in shipdata.plist:
But It seems this isn't support in current development release anymore. After digging through the files I saw the _number was removed from the keys. Yet it still nags about the deprecated conditions key. I suppose the conditions was part of the old script engine, so maybe some is out there who's able to point me in the right direction (Wiki/Posting).
thanks in advance.
Don't know if it's the right place to ask, but I have got following my problem. Refering to the wiki I was able to setup up conditions via conditions key in shipdata.plist:
Code: Select all
"conditions" = (
"systemGovernment_number equal 3",
"systemEconomy_number lessthan 4"
);
thanks in advance.
Amah
- about Amah: wiki
- noshaders versions of Griff's extra, alternate ships and accessories: discussion, wiki
- ocpc - customize the player ship: discussion, oxp repository
- Wildeblood
- ---- E L I T E ----
- Posts: 2445
- Joined: Sat Jun 11, 2011 6:07 am
- Location: Western Australia
- Contact:
Re: Progress
Use a conditions script, similar to equipment items.
http://wiki.alioth.net/index.php/Oolite ... wSpawnShip
http://wiki.alioth.net/index.php/Oolite ... wSpawnShip
- Amah
- ---- E L I T E ----
- Posts: 486
- Joined: Tue Aug 28, 2012 8:05 pm
- Location: aboard the Laenina Crowne - Yasen-N class space freighter
- Contact:
Re: Progress
thanks wildeblood. allowSpawnShip and allowOfferShip seem to be the ones I have to use then... too bad the simple conditions is gone now, usage was straight forward, but I think the script is probl. more versatile in the longrun.
Anything else I have to have an eye on?
Anything else I have to have an eye on?
Amah
- about Amah: wiki
- noshaders versions of Griff's extra, alternate ships and accessories: discussion, wiki
- ocpc - customize the player ship: discussion, oxp repository
Re: Progress
[wiki]OXP_standards[/wiki] is probably the document you're looking for (including other things which are part of the legacy scripting system). Not yet updated for 1.81/1.82, but other than commodities/markets there's not going to be much change there.
- Amah
- ---- E L I T E ----
- Posts: 486
- Joined: Tue Aug 28, 2012 8:05 pm
- Location: aboard the Laenina Crowne - Yasen-N class space freighter
- Contact:
Re: Progress
thanks cim for the reply and the hint with the oxp standards. Does allowspawnship work for (system)stations too? It does mention only ships as entities to be spawned in the wiki.
Amah
- about Amah: wiki
- noshaders versions of Griff's extra, alternate ships and accessories: discussion, wiki
- ocpc - customize the player ship: discussion, oxp repository
Re: Progress
Yes. A station is just a special type of ship with some extra capabilities.Amah wrote:Does allowspawnship work for (system)stations too?
Note that if you use conditions to make it impossible to spawn a ship with the main station role designated in
planetinfo.plist
for that system, the game will fall back to a coriolis as backup [1], and complain in the log file. If you want particular main system stations it's usually easier to set their role in planetinfo.plist
than to use conditions.[1] If that doesn't work either, it'll use any station it can find and complain even louder.
- Amah
- ---- E L I T E ----
- Posts: 486
- Joined: Tue Aug 28, 2012 8:05 pm
- Location: aboard the Laenina Crowne - Yasen-N class space freighter
- Contact:
Re: Progress
ah ok. I see how far my efforts will bring me now, and if it's ok will get back if I fail.
I understood planetinfo.plist is more a hardfixed approach (put station xy in System z). I'm working on the small Dertien Z_GrOovy stations and they are originally spawned based on systemproductivity plus its roles weighting.
I understood planetinfo.plist is more a hardfixed approach (put station xy in System z). I'm working on the small Dertien Z_GrOovy stations and they are originally spawned based on systemproductivity plus its roles weighting.
Amah
- about Amah: wiki
- noshaders versions of Griff's extra, alternate ships and accessories: discussion, wiki
- ocpc - customize the player ship: discussion, oxp repository
Re: Progress
A big set of changes in this morning's build, relating to equipment. A few of these have been in the nightlies for a while, but I don't think I mentioned them before, and they're all part of the same piece of work.
Basically the overall purpose of these changes is to make it much easier to make OXP equipment similar to the core equipment items and/or change the functionality of (some) core equipment.
So:
There have been some quite big changes to how many pieces of core equipment - energy units, shield boosters, heat insulation and large cargo bay especially - work internally. Careful observation that these items are all still functioning as they did in 1.80 will be required.
Basically the overall purpose of these changes is to make it much easier to make OXP equipment similar to the core equipment items and/or change the functionality of (some) core equipment.
So:
- Considerably more ship properties are writable by JS - maxRoll, maxPitch, maxYaw, maxThrust, maxEnergy, energyRechargeRate, cargoSpaceCapacity - and on the player ship also maxForwardShield, maxAftShield, forwardShieldRechargeRate, aftShieldRechargeRate. Yes, you can adjust forward and aft shields independently.
- heatInsulation is also writable for the player ship (it's been writable for NPCs for a long time)
- There are
equipmentAdded
andequipmentRemoved
events. These don't supersede the existing worldscript events, but may often be easier to use. They are also shipscript events, unlike the others, so can be used on NPCs. - There are some new ship properties for injector control -
injectorBurnRate
,injectorSpeedFactor
- and for modifying the Scanner Targeting Enhancement text -scanDescription
. - Condition scripts get an
updateEquipmentPrice
method which can be used to provide variable price equipment (like fuel and renovation are in the core) in an OXP. - Various core equipment items have been modified internally to make them fit with the above capabilities. The actual effect should be unchanged, but if you currently have an
equipment.plist
which overrides the core one, you will need to merge in the changes. - There's now a concept of "provides" in equipment, to allow OXP equipment to provide core functionality (e.g. a navigation computer which provides docking computer, ASC, and advanced nav array as a single item). There's potential here for breaking down some of the more multi-functional items of equipment into a few pieces, too - the only one in the core game at the moment is that fuel and cargo scooping are now provided as separate functionality blocks (though the core game "Fuel Scoops" item of course continues to provide both of these features at once). See [wiki]equipment.plist[/wiki] for more information on what functionality blocks are available. There's a
ship.hasEquipmentProviding(key)
method which does what it says.
There have been some quite big changes to how many pieces of core equipment - energy units, shield boosters, heat insulation and large cargo bay especially - work internally. Careful observation that these items are all still functioning as they did in 1.80 will be required.
- Norby
- ---- E L I T E ----
- Posts: 2577
- Joined: Mon May 20, 2013 9:53 pm
- Location: Budapest, Hungary (Mainly Agricultural Democracy, TL10)
- Contact:
Re: Progress
Very nice improvements, for example the writable maxshields are better than shield capacitors and the new injector properties made easier the making of my Small Fuel Injector idea. This game still growing faster than my ability to make my upcoming ideas.