SUBSIM Radio Room Forums



SUBSIM: The Web's #1 resource for all submarine & naval simulations since 1997

Go Back   SUBSIM Radio Room Forums > Silent Hunter 3 - 4 - 5 > SHIII Mods Workshop
Forget password? Reset here

Reply
 
Thread Tools Display Modes
Old 02-19-09, 08:56 AM   #121
Nedlam
Ensign
 
Join Date: Oct 2005
Posts: 222
Downloads: 48
Uploads: 0
Default

@RolandLarsen

Thanks for the reply. The example I gave was sort of the shorthand version. The other lines of code were below those.

I sort of shelved any attempts to randomize the weather with Sub commander. Well, it sort of retreated into the back of my brain as I try to figure out how the heck it all works!
__________________
You can never put too much water on a nuclear reactor...
Nedlam is offline   Reply With Quote
Old 02-20-09, 12:42 AM   #122
JScones
Navy Seal
 
Join Date: Apr 2005
Posts: 5,501
Downloads: 19
Uploads: 0
Default

Quote:
Originally Posted by Raptor U-505
I can open it but how do i update it or does it do it on its own. I am using SH3Gen and those entries are there
Quote:
Originally Posted by A Very Super Market
Click a patrol. Then, in the bottom clickable area, click and then type in whatever you want. The " | " key will be the equivalent of pressing " Enter "
Of course, one could also simply click on the "Help" link in the Patrol Log Editor to get usage instructions.
JScones is offline   Reply With Quote
Old 02-20-09, 12:50 AM   #123
A Very Super Market
The Old Man
 
Join Date: Dec 2008
Location: Deep in the Wild Canadian suburbs.
Posts: 1,468
Downloads: 0
Uploads: 0
Default

Bah, thats cheating !
__________________


The entire German garrison of Vanviken, right here in your thread!
A Very Super Market is offline   Reply With Quote
Old 02-20-09, 12:57 AM   #124
JScones
Navy Seal
 
Join Date: Apr 2005
Posts: 5,501
Downloads: 19
Uploads: 0
Default

@Nedlam and Roald: Not sure what you guys are doing wrong (well, to be honest I think I can make a fairly accurate guess), but I just spent 1 minute doing two tests:

1. Using the following lines:

Code:
;----------------------------------------------------------------------------------
[0:data\Campaigns\Campaign\Campaign_LND.mis]
MISSION|FogRand=I|99|99|N
MISSION|CloudsRand=I|99|99|N
MISSION|PrecipRand=I|99|99|N
MISSION|WindRand=I|99|99|N

[0:data\Campaigns\Campaign\Campaign_RND.mis]
MISSION|FogRand=I|99|99|N
MISSION|CloudsRand=I|99|99|N
MISSION|PrecipRand=I|99|99|N
MISSION|WindRand=I|99|99|N

[0:data\Campaigns\Campaign\Campaign_SCR.mis]
MISSION|FogRand=I|99|99|N
MISSION|CloudsRand=I|99|99|N
MISSION|PrecipRand=I|99|99|N
MISSION|WindRand=I|99|99|N
2. Using--and this test was simply to highlight to Roald that his problem is a USER SNAFU, not an SH3Cmdr one--the following lines:

Code:
;----------------------------------------------------------------------------------
[0:data\Campaigns\Campaign\Campaign_LND.mis]
MISSION|FogRand=I|99|99|N

[0:data\Campaigns\Campaign\Campaign_RND.mis]
MISSION|FogRand=I|99|99|N

[0:data\Campaigns\Campaign\Campaign_SCR.mis]
MISSION|FogRand=I|99|99|N

[1:data\Campaigns\Campaign\Campaign_LND.mis]
MISSION|CloudsRand=I|99|99|N

[1:data\Campaigns\Campaign\Campaign_RND.mis]
MISSION|CloudsRand=I|99|99|N

[1:data\Campaigns\Campaign\Campaign_SCR.mis]
MISSION|CloudsRand=I|99|99|N

[2:data\Campaigns\Campaign\Campaign_LND.mis]
MISSION|PrecipRand=I|99|99|N

[2:data\Campaigns\Campaign\Campaign_RND.mis]
MISSION|PrecipRand=I|99|99|N

[2:data\Campaigns\Campaign\Campaign_SCR.mis]
MISSION|PrecipRand=I|99|99|N

[3:data\Campaigns\Campaign\Campaign_LND.mis]
MISSION|WindRand=I|99|99|N

[3:data\Campaigns\Campaign\Campaign_RND.mis]
MISSION|WindRand=I|99|99|N

[3:data\Campaigns\Campaign\Campaign_SCR.mis]
MISSION|WindRand=I|99|99|N
(Of course, this would be the silly way to do it.)

In both instances, I ended up with this in all three files:

Code:
[Mission]
Title=GWX_3
MissionType=0
MissionDataType=1
Year=1939
Month=1
Day=1
Hour=12
Minute=0
Fog=1
FogRand=99
Clouds=1
CloudsRand=99
Precip=0
PrecipRand=99
WindHeading=0
WindSpeed=4.000000
WindRand=99
WeatherRndInterval=5
SeaType=0
Briefing=
Which is exactly what I was expecting.

BUT I will now add this important comment - it is my understanding that the settings in each of the three campaign files must be the same. Same <> randomised. In other words, you cannot use the randomised events feature to set the same settings across different files. That is not its intent.

I do not know the campaign files that well, and I certainly don't know the impacts that randomising the above settings have on the weather. In other words, I provide NO support whatsoever beyond demonstrating the usage of the function itself, which I have done.

Further, if you fear that SH3Weather is mucking up your weather settings, then I don't know how using SH3Cmdr to do essentially the same thing will be *any* different, considering that all you are doing is replacing SH3Weather's randomisation with randomisation done by SH3Cmdr.

BTW Nedlam, if you read the SH3 Commander User Guide, you will find that there is a much quicker way to test whether changes are made to files - you do not need to load SH3 each time.
JScones is offline   Reply With Quote
Old 02-20-09, 01:03 AM   #125
JScones
Navy Seal
 
Join Date: Apr 2005
Posts: 5,501
Downloads: 19
Uploads: 0
Default

Quote:
Originally Posted by RoaldLarsen
If I'm wrong about this, or if this is a documented behaviour of SH3 Commander, Jaeson might get upset with me. If I am correct, perhaps he'll want to think about how he manages file I/O, specifically, about when to close files that have been opened for writing.
I think you can now see that you are wrong.
JScones is offline   Reply With Quote
Old 02-21-09, 11:27 AM   #126
Nedlam
Ensign
 
Join Date: Oct 2005
Posts: 222
Downloads: 48
Uploads: 0
Default

@JScones,

I love your program. I wouldn't run SHIII without it. I figured it was something I was doing and not your program. I'm no programmer by any stretch of the imagination so I chalked up my problem to the old GiGo rule, i.e. user error.


I'll have to go back and re-read the manual. I must have missed that part on testing to see if the changes worked.

SH3Weather changes the 'Rand' files along with the other weather variables at the start of the game including Weatherrndinterval. The weather fix sets all of these to zero (weatherrndinterval is five). I thought I could keep the 'Rand' values at 0 and just adjust the other variables with Sub Commander. I was wronng. That's also why I think it's mucking up the weatherfix. Since uninstalling SH3Weather I've had less storms. Maybe I'm just getting lucky, who knows.
__________________
You can never put too much water on a nuclear reactor...
Nedlam is offline   Reply With Quote
Old 02-21-09, 05:32 PM   #127
Sailor Steve
Eternal Patrol
 
Sailor Steve's Avatar
 
Join Date: Nov 2002
Location: High in the mountains of Utah
Posts: 50,369
Downloads: 745
Uploads: 249


Default

Whatever happened to the random banners? I miss them.

Or am I just missing them in a different way?
__________________
“Never do anything you can't take back.”
—Rocky Russo
Sailor Steve is offline   Reply With Quote
Old 02-21-09, 07:28 PM   #128
JScones
Navy Seal
 
Join Date: Apr 2005
Posts: 5,501
Downloads: 19
Uploads: 0
Default

Quote:
Originally Posted by Nedlam
I love your program. I wouldn't run SHIII without it. I figured it was something I was doing and not your program. I'm no programmer by any stretch of the imagination so I chalked up my problem to the old GiGo rule, i.e. user error.
You're fine. It's users who can't get it to work so instantly assume that it's the software, not themselves, that I find a PITA.

@Everyone: The randomised events feature is very powerful, essentially allowing you to randomise any game setting. The trade off is an element of complexity that goes beyond just simple text file editing and cutting and pasting. So, I'm happy to help anyone having problems getting the randomised or static events features to work, as long as they post the full code they are using along with details of what they are trying to achieve and what they are achieving. Partial details, or suggestions that SH3Cmdr must have bugs because you can't get it to work, will not help.
JScones is offline   Reply With Quote
Old 02-21-09, 07:29 PM   #129
JScones
Navy Seal
 
Join Date: Apr 2005
Posts: 5,501
Downloads: 19
Uploads: 0
Default

Quote:
Originally Posted by Sailor Steve
Whatever happened to the random banners? I miss them.

Or am I just missing them in a different way?
Yeah, there were some nice banners. But they had to make way for the new interface that came with SH3Cmdr R3.0.
JScones is offline   Reply With Quote
Old 02-22-09, 08:13 PM   #130
RoaldLarsen
Weps
 
Join Date: Jan 2007
Location: Control Room
Posts: 355
Downloads: 8
Uploads: 0
Default

Quote:
Originally Posted by JScones
Quote:
Originally Posted by RoaldLarsen
If I'm wrong about this, or if this is a documented behaviour of SH3 Commander, Jaeson might get upset with me. If I am correct, perhaps he'll want to think about how he manages file I/O, specifically, about when to close files that have been opened for writing.
I think you can now see that you are wrong.
Nope.

Perhaps I am wrong. Perhaps this is a case of USER SNAFU on my part. But I don't see it.

I never asserted that doing what I suggested would definitely fix the problem Nedlam was experiencing. I said I had encountered an issue which seemed similar and told him what I had done, which worked for me, and suggested he try it too. I did not claim that the software was definitely broken but I did include a mention of a particular sort of software problem that is consistent with the reported evidence, as one of a number of possibliites, after user error and RTFM issues.

I seems to me that asserting, without sufficient evidence, that a user is wrong about a software problem is to repeat the very same mistake that a user makes by claiming, without sufficent evidence, that the software is at fault.

Yeah, you ran a rudimentary test that confirmed that SH3 Commander is working just exactly as you intended. Well, you didn't test my particular failure case. You couldn't. I hadn't described it in sufficient detail yet. Now I will. Here is a simple test case that repeats reliably on my installation.

SH3 Commander version 2.7.0.130. Nothing else on my computer that interferes with Ubisoft\SilentHunterIII\data\Cfg\Basic.cfg. Windows XP Professional SP3. Running from an account with administrator privileges.

Step 1. Run SH3 Commander, Roll Back SH3, Exit SH3 Commander. Inspect Basic.cfg, Commands_en.cfg and Sim.cfg in Ubisoft\SilentHunterIII\data\Cfg to make sure that they have their default values for the lines we are trying to change in Static settings.cfg.

Step 2. Edit SH3 Commander's out-of-the-box Static settings.cfg to add the following lines at the end:

SUBMARINE_AMMO2|ForeTube10=2 ;T2
TORPEDO_TYPE5|PrototypeYear=1943

[data\Cfg\Commands_en.cfg]
Cmd313|Key0=0x0

[data\Cfg\Sim.cfg]
Visual|Detection time=1 ;[s] ;was 0.5


Because the pre-existing lines in Static settings.cfg made changes to Basic.cfg, we expect the first two added lines to affect Basic.cfg as well.

Step 3. Run SH3 Commander and use it to launch SH3.

Step 4. Inspect Basic.cfg, Commands_en.cfg and Sim.cfg in Ubisoft\SilentHunterIII\data\Cfg.

You will find that SH3 Commander has correctly changed the four indicated values.

Step 5. Exit SH3 and repeat Step 1.

Step 6. Edit Static settings.cfg to swap the first two lines you added in Step 1, so they look like this:

TORPEDO_TYPE5|PrototypeYear=1943
SUBMARINE_AMMO2|ForeTube10=2 ;T2


Step 7. Repeat steps 3 and 4.

You will find that SH3 Commander has again correctly changed the four indicated values. We do steps 5 to 7 to confirm that changing the order of commands within one file section in Static Settings does not affect the outcome.

Step 8. Repeat Step 5.

Step 9. Edit Static settings.cfg to move the SUBMARINE_AMMO2 line to become the third line from the end. Because the line you just moved belongs to a different file than the line immediately above it, you must insert before it a file designation. Your additional lines should now look like this:

TORPEDO_TYPE5|PrototypeYear=1943

[data\Cfg\Commands_en.cfg]
Cmd313|Key0=0x0

[data\Cfg\Basic.cfg]
SUBMARINE_AMMO2|ForeTube10=2 ;T2

[data\Cfg\Sim.cfg]
Visual|Detection time=1 ;[s] ;was 0.5


Step 10. Repeat Steps 3 and 4.

When I do this I find that the value for the type of torpedo in Tube 1 in a type VIIB in 1940 - the value of the ForeTube10 line of the SUBMARINE_AMMO2 section in Basic.cfg - has not been changed, but the other three values have been changed.

So, I have a simple, repeatable failure case. Will this repeat for other users? IDK. Is the software broken? IDK. Did I make an error? Perhaps, but I can't see it.
RoaldLarsen is offline   Reply With Quote
Old 02-23-09, 02:32 AM   #131
JScones
Navy Seal
 
Join Date: Apr 2005
Posts: 5,501
Downloads: 19
Uploads: 0
Default

Quote:
Originally Posted by RoaldLarsen
I seems to me that asserting, without sufficient evidence, that a user is wrong about a software problem is to repeat the very same mistake that a user makes by claiming, without sufficent evidence, that the software is at fault.
Erm, I tested the same condition as you stated in your earlier post. Specific data is irrelevent when one is testing underlying logic. I mean, you can test your data all day long, but put simply, garbage in equals garbage out. And from looking at your code snippet it's obvious that you never validated your input data structure. Fail to you.

So, now looking beyond mere data, look at my test code again and you will see that it writes to the same file multiple times in non-sequential order. Is that (logically) what you were trying to do? Yes, it is.

Heck, I didn't even need to run a specific test - all one needs to do is look at the "fuller" Randomised events.cfg file to see the same condition in action (it does exactly what you are trying to do, so is even further evidence that your problem must be user - so I'm not sure what further evidence I would need in order for it to be considered "sufficient"? Ironically, my evidence is much greater than your simple and repetitive data test).

So...why then would my code work and yours not?

Look at my sample again and compare to yours. You will notice a very fundamental difference. Why? Because I FOLLOWED THE INSTRUCTIONS IN THE FILE HEADER!

And through looking at logic rather than mere data, it took me about 1 second to see the problem with your code and 1 second to fix it...
Code:
[data\Cfg\Basic.cfg]
<snip>
MEDALS_CREW|SunkInPatrolGerman=60000; TONNAGE, GC

TORPEDO_TYPE5|PrototypeYear=1943

[data\Cfg\Commands_en.cfg]
Cmd313|Key0=0x0

[0:data\Cfg\Basic.cfg]
SUBMARINE_AMMO2|ForeTube10=2 ;T2

[data\Cfg\Sim.cfg]
Visual|Detection time=1 ;[s] ;was 0.5
Heck, the instructions even tell you what to do...
Code:
;*Prefix each repeated section name with #: to ensure that the name is unique.
Now, if you really understood file I/O you would understand why this requirement is necessary.
JScones is offline   Reply With Quote
Old 02-23-09, 05:12 AM   #132
RoaldLarsen
Weps
 
Join Date: Jan 2007
Location: Control Room
Posts: 355
Downloads: 8
Uploads: 0
Default

Quote:
Originally Posted by JScones
Quote:
Originally Posted by RoaldLarsen
It seems to me that asserting, without sufficient evidence, that a user is wrong about a software problem is to repeat the very same mistake that a user makes by claiming, without sufficent evidence, that the software is at fault.
Erm, I tested the same condition as you stated in your earlier post. Specific data is irrelevent when one is testing underlying logic.
[and]
Quote:
Originally Posted by JScones
So, now looking beyond mere data, look at my test code again and you will see that it writes to the same file multiple times in non-sequential order. Is that (logically) what you were trying to do? Yes, it is.
You tested the logic in the code that processes a different file. There is nothing in the user documentation that says you use common processes to process all the files. I cannot assume that you necessarily wrote your code to use one standard routine to process all your files. Therefore I cannot assume that when you test the same sort of condition in a different file that you are testing the same code.
Quote:
Originally Posted by JScones
I mean, you can test your data all day long, but put simply, garbage in equals garbage out. And from looking at your code snippet it's obvious that you never validated your input data structure. Fail to you.
My input data was consistent with the instructions actually written in Static settings.cfg, just not consistent with what you meant. If you write poorly worded instructions - if you assign multiple meanings to the same or very similar terms without alerting your readers to the fact that you are doing this - you cannot expect people to understand what you mean. They will do what you say, not what you meant to say.

Quote:
Originally Posted by JScones
Heck, I didn't even need to run a specific test - all one needs to do is look at the "fuller" Randomised events.cfg file to see the same condition in action (it does exactly what you are trying to do, so is even further evidence that your problem must be user - so I'm not sure what further evidence I would need in order for it to be considered "sufficient"? Ironically, my evidence is much greater than your simple and repetitive data test).
When I encountered the failure to write all the changes I wanted to make to Basic.cfg, I was attempting to make those changes by using Static settings.cfg, not Randomized events.cfg. I had no reason to read Randomized events.cfg. I had not read Randomized events.cfg. One shouldn't have to read a different file to understand that the wording in the header of Static settings.cfg is misleading, and that one shouldn't follow its directions literally if one wishes to be successful (unless, OFC, that 'other file' is a manual, errata list, or similar publication).

Quote:
Originally Posted by JScones
So...why then would my code work and yours not?
Because you knew what you meant when you used two very similar terms to mean two very different things in the same file header.

Quote:
Originally Posted by JScones
Look at my sample again and compare to yours. You will notice a very fundamental difference. Why? Because I FOLLOWED THE INSTRUCTIONS IN THE FILE HEADER!
...
Heck, the instructions even tell you what to do...
Code:
;*Prefix each repeated section name with #: to ensure that the name is unique.
No you followed the instructions you meant to give, but not the instructions you actually gave.

To quote more completely from the comments in the file:
Quote:
;USAGE:
;[Name of the file including the full path from the "data\" level]*
;ApplyToPeriod=<Start date as YYYYMMDD>|<End date as YYYYMMDD>**
;<SectionName>|<KeyName>=<Setting> for text files OR
;<Offset value>=<Setting> for binary files (do not include comments)
;
;*Prefix each repeated section name with #: to ensure that the name is unique.
According to your syntax guide, SectionName is the thing that goes before the vertical bar on the same line as the KeyName. I don't have any repeats of these. I have repeats of file names. When I see an instruction about repeated section names, I can quite easily conceive that one might want to use a given value of SectionName repeatedly. I didn't need to refer to the same section more than once, so I assumed that this instruction did not apply to me. I have no good reason when I read this instruction to infer that "section name" refers to something other than SectionName.

And yes, I see the little asterisk at the end of the line and at the beginning of the instruction about using prefixes. That does not make it clear that use of the term "section name" in the instruction refers to Name of the file including the full path from the "data\" level rather than SectionName, because a user could just as well conclude that you are referring to repeated reference to a section within a file.

And yes, I understand how the use of file names in square brackets divides the Static settings.cfg into parts that one could call "sections", and that therefore one could say that the file names become "section names"[1], just as SectionNames [2] are section names[3], except that filenames that become "section names" are not SectionNames because they are section names in a different type of file. One could say that, but you don't actually say that anywhere do you? And you know what? That's just shoddy use of terminology. Its the sort of thing that leads to people not understanding what you intend. Its the sort of thing that a proper documentation review would catch and send back for a rewrite. It's a common practice in good user documentation to avoid using the same term in multiple ways, or using two very similar terms with widely variant meanings, and when one is doing something that could be at all ambiguous to provide very clear explanations.

Quote:
Originally Posted by JScones
Now, if you really understood file I/O you would understand why this requirement is necessary.
I know enough about file I/O to know that there are more robust and elegant approaches to dealing with multiple references to the same file. And I know that with these approaches, requiring the user to prefix repeated references with unique numeric tags is not necessary.

So put it down to user error if you like. Now that we know what is going on I can confidently say that where I worked before comfortably retiring from the software industry in my 40s, we'd file it under "product defect". We'd also probably send the prefixing requirement back for a redesign. Neither of these would reflect very badly in the performance review of a junior programmer, but treating users (dumb or otherwise) the way you do would get you one warning before costing you your job.

I really like SH3 Commander. It is generally a very useful utility, and reasonably stable. I use version 2.7 a lot, and will soon upgrade to version 3.x. I am truly greatful that you spent the time and effort to create and upgrade it. If 2.7 has a weakness, it is in its user interface. Sort of like its programmer.

Grow some skin.


--------------------------------------------------------------------

[1]"Section names" = the things referred to in the asterisked instruction about using numeric prefixes - the names of sections in the Static settings.cfg file. These names will have as values the pathnames of the SH3 configuration files you wish to modify by using Static settings.cfg. A "Section name"[1] is a section name[3] but not a SectionName[2]

[2]SectionNames = syntax element of a command in the Static settings.cfg file. This element specifies the section name[3] in the sh3 configuration file which you wish to modify.

[3]Section name = (used without quotation marks or colour), refers generically to the name of a section in a file, or more particularly to the name appearing in square brackets at the start of a section of a file which is composed of sections delimited by section names[3] appearing in square brackets at the beginning of the section.

Last edited by RoaldLarsen; 02-23-09 at 05:45 AM.
RoaldLarsen is offline   Reply With Quote
Old 02-23-09, 05:57 AM   #133
JScones
Navy Seal
 
Join Date: Apr 2005
Posts: 5,501
Downloads: 19
Uploads: 0
Default

Wow, your comments really highlight how little you know about file structures...and about my professional history. It's starting to get embarrassing. Still, very humourous to read for me and my colleagues, so carry on.

BTW, I'm really surprised based on you saying that you worked in the software industry that you don't understand basic ini file structures and syntax. Ironically, for at least according to you, you should have understood the instructions easier than anyone, but why have others (not in the software industry) had little to no problems getting it to work while you have? Maybe in this case you are the weakness?

Anyway, try to justify it however you like, but simply, your problem was a USER error. Just "grow some skin" and take responsibility for it instead of trying to blame everything else.

Issue closed (as your increased personal attacks suggest that you are running out of mature arguments to justify your mistakes).
JScones is offline   Reply With Quote
Old 02-23-09, 04:35 PM   #134
makman94
Hellas
 
Join Date: Jul 2008
Posts: 2,325
Downloads: 182
Uploads: 7


Default

Quote:
Originally Posted by JScones
Wow, your comments really highlight how little you know about file structures...and about my professional history. It's starting to get embarrassing. Still, very humourous to read for me and my colleagues, so carry on.

BTW, I'm really surprised based on you saying that you worked in the software industry that you don't understand basic ini file structures and syntax. Ironically, for at least according to you, you should have understood the instructions easier than anyone, but why have others (not in the software industry) had little to no problems getting it to work while you have? Maybe in this case you are the weakness?

Anyway, try to justify it however you like, but simply, your problem was a USER error. Just "grow some skin" and take responsibility for it instead of trying to blame everything else.

Issue closed (as your increased personal attacks suggest that you are running out of mature arguments to justify your mistakes).
. you seem to me much more inpolite !
makman94 is offline   Reply With Quote
Old 02-26-09, 09:42 PM   #135
johnlax
Navy Dude
 
Join Date: Sep 2001
Posts: 172
Downloads: 21
Uploads: 0
Default SH Commander

Sorry for the newbie question here but if I install SH Commander will I have any re-supply at sea feature? DO I need another mod like GWX? I am finding all of this install and re-install stuff abit confusing. No one seems to be clear on outlining the sequence of installation. Right now I have nothing I plan on installing SH III and patch If I just install SH COmmander will I get some re-supply at sea ability. I am afraid to tackle the install of GWX it sounds like I would have to alot of installing and uninstalling maybe I should just be happy with SH Commander! Please let me know your thoughts
johnlax is offline   Reply With Quote
Reply

Tags
sh3 commander

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -5. The time now is 12:43 PM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © 1995- 2024 Subsim®
"Subsim" is a registered trademark, all rights reserved.