Easy Quest fragment (script) question.

[csbx]

I mean, easy if you're not a clown like I am !

 

The following is in a quest fragment -- most borrowed from an example:

 

--

float Property lateh = 22 auto

float Property earlyh = 24 auto

float Function GetCurrentHourOfDay() global

float Time = Utility.GetCurrentGameTime()

Time -= Math.Floor(Time) ; Remove "previous in-game days passed" bit

Time *= 24 ; Convert from fraction of a day to number of hours

Return Time

EndFunction

If (GetCurrentHourOfDay() > earlyh) && (GetCurrentHourOfDay() < lateh)

int delay = Utility.RandomInt(6, 18)

Utility.Wait(delay)

Endif

--

 

 

Error returned when compiling is: : no viable alternative at input 'Property'

Clearly I don't know what I'm doing here. What obvious thing am I missing ?

Edited March 28, 2018 by csbx

[dagobaking]

I haven't seen properties being assigned a value in their declaration line like that. Might be it.

 

Change:

 

1. float Property lateh = 22 auto
2. float Property earlyh = 24 auto

To:

float lateh = 22

float earlyh = 24

Please. Never post code with zebra bars like that again. ;)

[FlashyJoer]

Get rid of PROPERTY and AUTO.

 

These are integers, so declare them as such.

 

int lateh = 22

int earlyh = 24

 

Just like that. Think about this logically. How can you assign a property to an integer variable when there is no corresponding Form for the script property to attach to? You cannot. So, just declare them WITH your script properties, just not as a property.

Edited March 28, 2018 by joerqc

[csbx]

Had no idea it would zebra my shyte up like that.

 

You guys were right, obviously. Yeah, I'm not sure why that didn't stand out to me as absurd--I guess you acquire a kind of vision such that things look really off when you're really familiar with coding. I've skirted by doing basic stuff and am working outside my capabilities--but for a good cause !

 

Now it's saying no viable alternative at input 'Function'

[Evangela]

Type property propertyName = value auto

Is syntactically ok.

 

You're just assigning a property a default value which will be displayed in the editor that is not physically set by you. Properties are simply variables that can be accessed by other scripts, unlike regular variables(local variables).

 

The problem you're having is that you can't do this in quest fragment. Properties can only be set in the property manager(Properties tab on the bottom right hand corner, next to the Edit tab) on the quest fragment.

 

Secondly you can't define(create) functions in a quest fragment - they need to be called from a script, in this case, a quest script. From there you need to pull the quest script from a drop down in the quest fragment(it's the long box next to kmyQuest), then call the function on kmyQuest(syntax: kmyQuest.FunctionName())

Edited March 28, 2018 by Rasikko

[csbx]

@Rasikko. Thanks a lot. I've never really understood what limitations were associated with fragments--this helps a lot.

[digitalpartisan]

The input up to this point has been spot on, but I'd like to offer another perspective entirely.

This problem could be solved by not declaring the function global. Sure, that's significantly less convenient from a coding / configuration standpoint, but it would offer a significant advantage from a flexibility standpoint. Yes, you would have to attach this script to an object and have other scripts accessing your logic, which in turn means adding a property to the scripts containing the fragment you're working on, but the option to change configuration (of variables, values, and all that stuff) in the editor without needing to change a script and recompile it is incredibly helpful. Just about every mod I've worked on where I've had important time / game time / math / etc. work going on has a configuration quest object in it that every other component ends up accessing. I've almost never seen fit to change any of the values from their defaults, but it's nice to know the option exists. This is doubly so post-release where a bug may have manifested itself that hasn't got anything to do with scripts and a fix merely requires changing a value in the editor.

 

Fragments, as such, are on Quests, Terminals, Perks, Effects, etc. where there needs to be a customized response to an event of which the game engine informs the object in question. And yeah, that's a little bit obvious, but I say it to call attention to their real purpose. What does and doesn't belong in a fragment? Really, they're a pain to deal with (and yes, I know you all know that,) so they need to be as minimal as possible such that they only call other code (or perform the most basic of actions that isn't likely to change, such as closing out or activating quest objectives) that does real work. That way, the fragment doesn't need to be bothered with once it's written.

Also, it's probably best to learn to interact with the scripts where fragments live. I had to deal with moving and changing them when I wanted to work on a mod that I had in version control. Moving the fragments into the namespace for the mod was a great choice. There have been a number of times I've had to fix a busted fragment script by hand since there was no chance of getting to compile correctly by editing the fragments. Do note that when you make these changes, it's best to do so after the mod has been saved in the CK and the object in question is closed. Edit, recompile, then reload the mod. This is especially helpful for mucking about with property changes on the fragment scripts.

[kitcat81]

One more thing :) The CK won't let you assign integers to float. You need to use 24.00 or 22.00 to avoid property type error. Or use Int property if you need integer values.