ProjectsWhat's NewDownloadsCommunitySupportCompany
Forum Index » S.T.A.L.K.E.R.: Shadow of Chernobyl Forum » Mod discussion
ZRP - A joint effort in fixing S.T.A.L.K.E.R.

« Previous 10 events | 1 ... 333 334 335 336 337 338 339 | Next 10 events »
Question Do YOU want an unofficial patch?
Answers
Yes, I'm desperate!
Yeh, why not...
I don't care either way.
Could easily do without it...
Decane, stop spamming the forums with your dumb ideas! NO!
Posted by/on
Question/AnswerMake Newest Up Sort by Descending
  05:09:42  18 April 2017
profilee-mailreply Message URLTo the Top
NatVac
Senior Resident
 

 
On forum: 06/15/2007
Messages: 4163
Current Zone Reclamation Project (ZRP) download site:
http://www.metacognix.com/stlkrsoc/
ZRP FAQ: http://www.metacognix.com/stlkrsoc/ZRP_FAQ.html

Please read the documentation in the mod's archive before posting here. And your question might already be answered elsewhere; you can try Google with the search parameter site:gsc-game.com to check this site.

Have a crash? A freeze or lockup? A BSOD? A shutdown? Go here, first:

---QUOTATION---
"Crash To Desktop (CTD): Causes and Treatment":
http://www.gsc-game.com/main.php?t=community&s=forums&s_game_type=xr&thm_id=11715&sec_id=12

Crashes still in the game:
http://www.metacognix.com/stlkrsoc/CrashesStillInTheGame.html
---END QUOTATION---


Read the "Find your log file" section. Most "crashes" are fixable, but we need the info from the end of the log file.

Bugs in STALKER-SoC: http://www.metacognix.com/stlkrsoc/BugsInSTALKER.html
Troubleshooting FAQ: http://www.metacognix.com/stlkrsoc/TroubleshootingFAQ.html

Feel free to mention any bugs or crashes you know that are missing from the list.

If you don't start a new game, there may still be some minor problems with your saved games. The saves are modified versions of the all.spawn file present when you started your current game. Saved games based on mods might also include custom items from those mods, and support for them will need to be properly merged to avoid crashes.

¯¯¯¯¯¯¯¯¯¯
Information on the experimental ZRP 1.09 XR1 release is available on the previous page, as I post this.

Also, my web hosting company will be updating the site's infrastructure again, scheduled for the 27th. Expect some transitional issues.
  02:54:11  22 April 2017
profilee-mailreply Message URLTo the Top
MrSeyker
Senior Resident
 

 
On forum: 03/21/2010
Messages: 369
Damn, that's some readme. I was on vacation, so this will take me a while to process. Will try to send you updated files asap.
  08:43:24  22 April 2017
profilee-mailreply Message URLTo the Top
Tejas Stalker
Official Stalker on Facebook
(Resident)

 

 
On forum: 05/12/2007
Messages: 22065
ZRP - A joint effort in fixing S.T.A.L.K.E.R.

NatVac~

We've been doing this for 10 years now. Glad to see you still active.

TS
  09:44:31  24 April 2017
profilee-mailreply Message URLTo the Top
NatVac
Senior Resident
 

 
On forum: 06/15/2007
Messages: 4163
I've seen a couple of problems while exercising the test release.

I found out that NPCs can "join" a smart-terrain lager (camp) long before they get there. While playing in the Garbage, I came across a group of bandits heading north on the main road, just east of the vehicle graveyard. I dispatched them, then saw a couple of fatal error messages in the log to the effect that a state test for the bandit factory in Dark Valley had failed; the space restrictor data did not exist in the current level's table. Well of course it doesn't; we were in the Garbage.

Huh. That long-distance membership negated an optimization that assumed that camp members would check their state while you were on or near their camp. One bit of evidence supporting that was the fact that the bandit attack on the Dark Valley Duty guys doesn't happen until you get close enough to switch them online.

I saw the errors by accident; I was checking the console for debug info. The game didn't crash. I made a save, loaded that save and played from there just fine, so there were probably a couple of bandits in the group that died to a grenade because they weren't moving due to suspended threads.

The fix: Open gamedata\scripts\gulag_dark_valley.script, find this line about line 924:

    if vlbr_zone:inside(actor:position()) then

Change it to look line this:

    if vlbr_zone and vlbr_zone:inside(actor:position()) then

Save the file.

Also, for those who want to use SANB in the 1.09 XR1 release, there's an issue that can cause NPCs to stall after successfully navigating around an anomaly. This is due to the revised code that ignores all anomalies that are not close by. (It was silly to have every NPC on the Bar level constantly checking and evaluating every anomaly on the level.)

Workarounds include ignoring the NPC (he will eventually move on), disabling SANB, or modifying a file.

To do the last, edit gamedata\scripts\anomaly_evader.script in a text editor like Notepad. Find "local mindist=20" (line 20) and change it to "local mindist=1000". Likewise find "if dist < 20 then" (line 52) and change it to "if dist < 1000 then". Save the file.

This essentially restores the old behavior. A fix has been implemented which keeps the new approach to evaluate only nearby anomalies, but broadens the search for specific navigation around an anomaly. Expect it in the next release.

Not yet addressed: Navigation around anomaly fields. NPCs still evaluate only one anomaly at a time, so they will still perish when the act of turning/moving from one anomaly puts them in another.

Another quirk: Some formerly-invisible boxes (invisible due to contact with something like the ground) may now be visible but you still can't break them until you bump them.

A vanilla issue: the logic in trade_manager.script's update() function says if the update time is not set or it's set but it is less than right now, return.

Since it is not set the first time, it fails the test above and sets the update time to now + a game hour (i.e., an hour from now). It then does some logic checks to see if it should update any inventory.

The next time through the update() call (every second for NPCs, four times a second for that literal monster Sidorovich) it performs the check for not set (false) or if set but less than now (false), so it fails the test again and falls through.

And proceeds to set the update time to now + a game hour again, then going on to comparing buy/sell/supplies with the current situation.

This means the conditions for buying and selling and the supplies for the trader's inventory are constantly checked, when the apparent intent was to check them about once an hour of real-time play.

The constant checking is not a serious burden, but it is a general waste of processing time. The generic NPCs don't need this checking at all after initialization. The regular traders only need it when there is a new info_portion. Instead of continuous checking, this could be done during the info_portion processing, or better, when you engage in dialog or trade with them.

Aside from those few info_portion-based changes, a trader's inventory never changes during a game session. You have to make a save and reload it to change the inventory.

Input on this is welcome. I'm going to ruminate on it a bit. My current thought: don't repeatedly do it for the NPCs, just the traders, and maybe only on state change. (Everyone gets checked on session load; that won't change.)

¯¯¯¯¯¯¯¯¯¯
>> Damn, that's some readme.

Actually, that's the change notes, MrSeyker. It's been a couple of years. No rush on the updated files as I'm still immersed in code changes.

Also, don't worry about the all.spawn changes for your own purposes until I release the diff data. There's another change coming that removes all four instances of "trader_flags = 0" which I'm currently testing. At first I thought this to be harmless because the game doesn't parse it, but after the second playthrough encounter with a specific member of Mole's group who was using a pistol because he didn't have the ammo for his rifle when his profile said he should, I found he was one of the four all.spawn entries with that setting. Sid, you and the Rostok RPG merc (who always dies) are the others. The game may be stumbling over this for those NPCs.

Also, I'm thinking of consolidating the xr_kamp.script versions, using flags to enable/disable xStream's dead body clean-up and your harmonica mod. Local variable checks are very fast. There would still be a need for the separate harmonica support files, but you would probably not need to change them in future versions.

I hope you enjoyed your vacation.

¯¯¯¯¯¯¯¯¯¯
>> We've been doing this for 10 years now.

Well, from my perspective, Tejas Stalker, I've been doing this for ten years and you have been opposing it every step of the way. Yes, you mean a different "this".

Time flies. It really doesn't care if we're having fun or not.

The next ZRP update will give you even more reasons not to use it. One reason is the new inability to deprive panicked NPCs of their guitars in trade. The ability is an unrealistic bug; wounded or panicked NPCs are not thinking clearly but they definitely would not be thinking, "Oh, sure, let's trade."
  17:25:45  24 April 2017
profilee-mailreply Message URLTo the Top
Tejas Stalker
Official Stalker on Facebook
(Resident)

 

 
On forum: 05/12/2007
 

Message edited by:
Tejas Stalker
04/24/2017 17:27:01
Messages: 22065
ZRP - A joint effort in fixing S.T.A.L.K.E.R.

NatVac~

I have not been opposing what you do. Just on occasion reminding
people who think the ZRP is a MUST and nothing more than bug fixes
that it's actually a MOD with some bug fixes. When you can do some
things that the original Game never intended...you have a MOD. Now
if you would offer a version with ONLY the bug fixes, I would have been
your biggest fan. However you are free to do what you do as you wish.
I guess I've rankled you in this process as you misunderstood my attempt
to appreciate our mutual love for the Stalker Games instead of just the ZRP.

TS
  07:22:41  25 April 2017
profilee-mailreply Message URLTo the Top
MrSeyker
Senior Resident
 

 
On forum: 03/21/2010
Messages: 369
I ran a comparison betwen the 1.07's script folder and 1.09's and the amoung of changed code is a bit intimidating. The mods I use are generally small (coulple of scripts per mod), but I'm starting to wonder if they'll work at all with all these changes (if I even can find the spot to merge them).

You might be disabling too much legacy code which mods require. Can't really be sure, because I still have not even tacked porting my current version of my gamedata to the new code.

Also, regarding anomalies never creating artifacts after a new game, I've been using kstn's Artefact Respawner 1.01 in my mod, and it's pretty effective.

A single script called from bind_stalker makes anomalies in the player's current level spit out a couple of artifacts per game session.

As far as I've played with it, it's pretty effective, and easy to enable/disable via modifier.

Some update in the anomaly/artifact table is needed before though, because kstn used the wrong definition for burnt fuzz and their artifacts.
  00:00:44  27 April 2017
profilee-mailreply Message URLTo the Top
Decane
Senior Resident
 

 
On forum: 04/04/2007
 

Message edited by:
Decane
04/28/2017 1:36:09
Messages: 1644
Hi NatVac, long time no type.

I diffed the SoC version of trade_manager.script with the CS one and found them to be nearly identical - the only differences are in the comments and in the SoC version missing the set_save_marker() calls found in the save() and load() functions of the CS version. As it happens, I have already addressed the issue you raised in the CS version. Here is a paste of the current SRP version of the file: https://pastebin.com/7tCwnnPr

I deactivated the update interval checks entirely and moved the trade_manager.update() call in xr_motivator.script into the if-alive branch of function motivator_binder:use_callback(). That way, trade conditions/supplies get re-calculated for an NPC each time the player "uses" the (live) NPC. You pointed out that regular NPCs don't need even this. This is true for both vanilla games, but modders might modify trade_generic.ltx with a condition list or three, making at least an update on trade screen initialization desired, lest they are befuddled by their condition list not having any effect until a reload.

Your idea of calling trade_manager.update() only ...

---QUOTATION---
when you engage in (...) trade with them
---END QUOTATION---


... is even more efficient than what I did. I might shamelessly steal it as I have done with some other neat ZRP fixes, features, and optimizations over the years.

Update: I looked into this a bit more. In CS, actor_menu.trade_wnd_opened() gets called whenever the player engages in trade with an NPC, but it is called from the engine and takes no arguments. That makes it difficult to use as a trigger for firing trade_manager.update() for a specific NPC.

The only 'efficient' way that comes to mind is keeping track of the last NPC the player talked to using a file-scope variable -- say, 'last_interlocutor' -- and then calling trade_manager.update(last_interlocutor) from actor_menu.trade_wnd_opened(). I think that would be moderately safe to do since the player cannot engage in trade with an NPC without first speaking to the NPC.

I'm not sure how to detect "speaking to the NPC", though. If via "use" of the NPC, there could be some edge cases where that yields the wrong result - e.g. if I "use" NPC1 and NPC2 walks by and "uses" me to initiate a dialog (could happen in some mods), and I initiate trade with NPC2, then NPC1 would still be registered as the last interlocutor and NPC1's trade conditions/supplies would get updated instead of NPC2's.
  05:03:51  27 April 2017
profilee-mailreply Message URLTo the Top
MrSeyker
Senior Resident
 

 
On forum: 03/21/2010
 

Message edited by:
MrSeyker
04/27/2017 6:45:21
Messages: 369

---QUOTATION---
This is true for both vanilla games, but modders might mod(ify) trade_generic.ltx with a condition list or three, making at least an update on trade screen initialization desired, lest they be befuddled by their condition list not having any effect until a reload.
---END QUOTATION---



Huh, I was actually thinking of making all traders (including generic stalkers) use different values when entering Freeplay.

I've been looking into expanding the ZRP freeplay experience (new quests, new items to be bought/sold, trade overhauls).

EDIT:

Regarding widescreen fonts, I feel like just changing all the _1600 entries in fonts.ltx to read _1024 is a better solution to the large, overblown widescreen fonts. It seems more asthetically pleasant to me.
  01:55:58  28 April 2017
profilee-mailreply Message URLTo the Top
NatVac
Senior Resident
 

 
On forum: 06/15/2007
Messages: 4163
>> I have not been opposing what you do.

You really have been opposing the ZRP (which is what we do), and I thank you for that. It forces us to examine our choices, and it serves to promote the ZRP, something I'm fairly sure you didn't intend.

---QUOTATION---
Just on occasion reminding
people who think the ZRP is a MUST and nothing more than bug fixes
that it's actually a MOD with some bug fixes. When you can do some
things that the original Game never intended...you have a MOD.
---END QUOTATION---


Just "reminding" on every possible occasion that it is a mod, and this claim is a red herring; the ZRP website calls it a mod, the ZRP readme calls it a mod and I've called it a mod since at least the first release back in 2007 (see this thread, starting with page 4). Its primary focus is bug fixes, but it addresses the wants of a larger audience. It even supports the minority that would rather swim across the river of bugs than use the bug-fix bridge we've built, but they would have to open the gate to get to that river (that is, re-enable a few bugs and disable a few features like TZIO and the dynamic level changers, which are optional). And if you want the pure vanilla, the answer is simple: don't use the ZRP.

---QUOTATION---
Now if you would offer a version with ONLY the bug fixes, I would have been
your biggest fan.
---END QUOTATION---


Wow. That evoked a strong memory of a scene from one of Pixar's films.

This, too, has been discussed into an agonizing death. The idea of a pure bug-fix mod surfaced a few times in the early years, and good folks like fatrap made valiant attempts to do this, but the number of definitions of exactly what would constitute a "pure" bug-fix mod was only slightly smaller than the total playing population.

Here's irony for you: We've created a mod that actually comes closer to the ability to fulfill every "pure" bug-fix definition than anything else available. The only problem for some is the out-of-the-box mod default is set up for the largest audience, so there's some assembly required to restore some vanilla "charms".

(Side note: A small effort to improve vanilla with a few bug fixes is available already at the ZRP download page: The ShoC_Treatment stuff as a drag-n-drop install: SoC_ScriptFixes_1.0.7z. It obviously needs updating, though.)

>> However you are free to do what you do as you wish.

Do what now? I'm free? What about all the others who don't share your opinion, those who want to play on Linux, or who want options, or who want to play a mod for the first time instead of vanilla? The only opinion I've seen that does not earn your strong e-vocal opposition is one that already coincides with your own.

I'm not telling you to stop recommending vanilla. I'm telling you that your method is often detrimental to a community that has all sorts of players. Yes, most players should play vanilla first -- but if one doesn't want to, that is really their business, not yours. Giving advice is something helpful (usually), but saying there's something wrong with them if they don't take that advice? Not good.

---QUOTATION---
I guess I've rankled you in this process as you misunderstood my attempt
to appreciate our mutual love for the Stalker Games instead of just the ZRP.
---END QUOTATION---


Your opposition doesn't rankle me; see the first part of my reply above. I didn't misunderstand anything, although my joke obviously fell flat. I'm more than fine with your love of the games, and your subsequent efforts to share that love.

However, I would like to take advantage of the rare occasion of your presence here...

You believe that you changed Yurik's direction by being in the area where he was so that he switched online with you in the southern part of the Garbage. In reality, all NPCs go to the Agroprom level changer area to go to the Cordon. For one thing, there are no open slots in any camp in the Agroprom, not until you go there and do things. For another, I've already pointed out to you that you can mark Yurik and other NPCs and see where they are and where they go. If Yurik goes to that level changer safely, he will always -- always -- pop to the Cordon level changer and proceed to an opening in a camp there. ("Safely" as long as you don't follow him northwest in the Garbage to where he can get killed by the newly-switched-online bandits on the way to the Agroprom level changer.)

And you insist there should be no veterans in the Garbage, when even expert bandits traverse the Garbage area in vanilla. You can have veteran Dutyers at the northern blockpost. And those two bandits in the Garbage that Sidorovich wants you to take out? They are veterans. Oh, look! You found a high-ranking military guy in the Agroprom underground! Wow, you got lucky in vanilla -- the vanilla rookie bandit respawner almost always has first crack at any replacements if you save/reload or change levels. Yet both military and bandits can have veteran and expert replacements there if one is very lucky (Friar and Poker are the exceptions that prove the rule because they are already in the game, not AI respawns) -- or if one uses a fixed respawner.

You keep telling others that ZRP makes the game easier by reducing the respawns. But the ZRP only delays the first replacements. By fixing the respawner, you also get higher-ranking replacements all over -- and that makes the game harder. The ZRP even has a respawner option to behave exactly like vanilla!

You've scoffed at those who said they saw bandits on the road from Yantar into the Wild Territory. Yet that's the typical route for those veteran and expert bandits missing in your game; they come from different respawners than the rookie bandits.

You say that everyone should play the way the devs intended. I happen to agree -- except there is more about what they intended in the code and its comments than can be gleamed from just playing. They wanted the respawning states to be controlled by whether replacements were seldom, medium or often, but their code only worked if you didn't die or make/load a save or change levels. Any of those would reset the timers, something they didn't want according to their code.

Not everything they intended is good, but they didn't know that because the code was broken in places. There was a typo that kept a monolith "kill the stalker" quest from appearing in vanilla. But when fixed it was too easy and no one liked it. And the night music didn't work because the time check didn't work across the midnight barrier. Fixing that revealed that very few players actually liked the eerie music at night.

Yet we only know that because we did what the devs never got to do: We worked on fixing vanilla.

Please stop claiming that the Protect Border task can be always completed in vanilla, or someone's doors could not possibly be broken, simply because these problems didn't happen to you. It is also unreasonable to expect players to play as you do, where you've learned not to save in Pripyat because those saves won't work in vanilla. One or two long-term exhaustive playthroughs gives you a lot of expertise but not as much as the witness of thousands who chose a road not taken by you.

But by all means, please don't stop opposing the ZRP. Your contrarian viewpoints have honestly helped make the ZRP the most vanilla-supporting mod out there.
  01:57:25  28 April 2017
profilee-mailreply Message URLTo the Top
NatVac
Senior Resident
 

 
On forum: 06/15/2007
Messages: 4163
MrSeyker, my approach to porting is to re-compare the 1.07 base with the custom-mod 1.07, then merge those differences into the 1.09 base. That's how I'm updating the AI add-ons -- except it is slow when there is so much stuff not compatible with effective/efficient code execution -- I can't resist changing it. See the Grenadier mod for an example.

(Side note: one Grenadier bug I've noticed is the occasional failure to properly enter the wounded state. I've see two enemy NPCs so far that seemed impervious to outside influence. They were just wounded.)

I was hoping that you'd try the unmodified 1.09 base before customizing it to have an understanding of the ZRP changes before you updated it to your base. Also, the ZRP base is still evolving, so I wouldn't make much in the way of changes just yet.

I'm thinking of folding the fixes (note the separation of fixes and optimizations/tweaks in the change notes) into the 1.07 R5RC and issue an official 1.07 R5 release, which would make for very little impact on those who already have mods for 1.07.

I still like the 2-ms synchronizing phase for saved-game reloads in the Bar, though, once the resources are cached.

---QUOTATION---
I was actually thinking of making all traders (including generic stalkers) use different values when entering Freeplay.

I've been looking into expanding the ZRP freeplay experience (new quests, new items to be bought/sold, trade overhauls).
---END QUOTATION---


That sounds really great. You don't need to worry about trade_generic.ltx; it won't be ignored. See my reply to Decane.

---QUOTATION---
Regarding widescreen fonts, I feel like just changing all the _1600 entries in fonts.ltx to read _1024 is a better solution to the large, overblown widescreen fonts. It seems more asthetically pleasant to me.
---END QUOTATION---


I'll try it on my old LCD and on a wide-screen monitor when the opportunity arises. Those "overblown widescreen fonts" are but one reason I don't use 1.0006.

¯¯¯¯¯¯¯¯¯¯
Decane, thanks for the update and the useful information.

---QUOTATION---
I deactivated the update interval checks entirely and moved the trade_manager.update() call in xr_motivator.script into the if-alive branch of function motivator_binder:use_callback(). That way, trade conditions/supplies get updated/re-stocked for an NPC each time the player "uses" the (live) NPC.
---END QUOTATION---


Great minds think alike. Mine is just slower than yours. We didn't even have a trade_manager.script in the 1.07 releases. I only included it in 1.09 XR1 because of some general optimizations I was applying to all related scripts (see the change notes), one of which was a function signature change. When I posted earlier, I was revisiting some of the changed files.

Since then, I'd done what you'd done about the backwards comparisons, but I'd not tweaked xr_motivator.script quite the way you did. I had moved some tests around for reducing the same tests, but because of something I'd done in the 1.07 R5 RC release the "if alive" check was not as critical: there's a variable called death_recorded that I use to skip all the tests in motivator_binder:update() after the first call for a dead NPC, new or otherwise. You can gaze across a sea of NPC corpses without any noticeable hit to the corpse-free framerate.

I've also now applied that change to bind_monster.script's update() function to handle mutants the same way.

---QUOTATION---
You pointed out that regular NPCs don't need even this. This is true for both vanilla games, but modders might mod(ify) trade_generic.ltx with a condition list or three, making at least an update on trade screen initialization desired, lest they be befuddled by their condition list not having any effect until a reload.
---END QUOTATION---


If the script had been functioning as intended, they'd still be befuddled as the SoC code implies a real-time hour wait after a relevant state change (SoC example: completing the Nimble rescue) to actually act on it, and a whole real-time day before inventory change. That's like ten days in vanilla blind dog years! This means you would likely never see Sid's new stuff in normal play. Perhaps the devs expected enough time to elapse that you wouldn't associate the task completion with a whole new set of goodies instantly, and they kept tweaking it, lengthening the time without realizing the test was broken.

Yet: It isn't terrible that the time check was broken on top of the complete absence of true state persistence, except for the wasted processing cycles. It was still ten years before I noticed that it was not working properly, and only because of the system-wide optimization I was implementing. As with the "broken" night music, the "broken" vanilla behavior to instantly update is actually okay.

As far as modding goes, the ZRP code would still work if they added a buy_supplies entry, because the WIP 1.09 XR2 script currently does this in the update(): "if tt.buy_supplies == nil then trade_manager[npc:id()] = nil; return; end". This resets the entry in the trade_manager table, forcing an immediate return upon each subsequent call to update(), during that current game session -- but only if there is no buy_supplies line. Even with this optimization, a ZRP system that ignored trade updates for generics would still refresh the situation with each session change.

But I like your "on use" update approach a lot. It's like the concept behind JIT (just-in-time) compilers: compile a code block only when you actually need it. This means there would not need to be any additional action on state changes, no need to monitor anything, no need to constantly check, and no quantum-mechanics cat in the box starving to death or stinking until you actually open it -- what's not to like?

I noticed that you commented out the save()/load() functionality in your CS version. That probably requires a new game. I currently have the save() function just save a boolean false to maintain compatibility with existing saves. You probably looked at the trade_init() function with the save()/load() functions and said the same thing I did: "Say WHAT! Why even save something you throw away on every load!"

As for the idea of updating the NPC's stock when actually trading, you wouldn't be stealing anything. Something in SoC that may or may not be in CS: info_portions you can check, ui_trade and ui_trade_hide. It might not be worth it; the trader's inventory might re-adjust itself while you are looking at it. It does that now occasionally on the Marked One's side when you open the trade/search windows.

I'd forget it if it was too much trouble and just continue with the current "on use" approach.
 
Each word should be at least 3 characters long.
Search:    
Search conditions:    - spaces as AND    - spaces as OR   
 
Forum Index » S.T.A.L.K.E.R.: Shadow of Chernobyl Forum » Mod discussion
 

All short dates are in Month-Day-Year format.


 

Copyright © 1995-2007 GSC Game World. All rights reserved.
This site is best viewed in Internet Explorer 4.xx and up and Javascript enabled. Webmaster.
Opera Software products are not supported.
If any problem concerning the site functioning under Opera Software appears apply
to Opera Software technical support service.