Mon Oct 17, 2016 12:17 pm
Mon Oct 17, 2016 12:26 pm
wiki wrote:Actors are now known as classes which must inherit from Actor.
Mon Oct 17, 2016 12:51 pm
const Number1 = 1;
default
{
Radius = 9;
+ACTIVATEIMPACT;
}
const Number1 1
default
{
Radius 9
+ACTIVATEIMPACT
}
const Number1 = 1;
default
{
Radius 9;
+ACTIVATEIMPACT
}
Mon Oct 17, 2016 1:03 pm
FishyClockwork wrote:wiki wrote:Actors are now known as classes which must inherit from Actor.
Hmm. So if I wanted to be really daft and, say, inherit from Thinker or Object, would I get a error?
Graf Zahl wrote:That's to avoid polluting the main class body with the properties. They use quite different syntax than the rest and would cause parsing problems otherwise.
Mon Oct 17, 2016 1:44 pm
FishyClockwork wrote:wiki wrote:Actors are now known as classes which must inherit from Actor.
Hmm. So if I wanted to be really daft and, say, inherit from Thinker or Object, would I get a error?
Mon Oct 17, 2016 1:49 pm
Mon Oct 17, 2016 1:52 pm
Mon Oct 17, 2016 2:02 pm
Mon Oct 17, 2016 11:29 pm
MaxED wrote:This?
- Code:
const Number1 = 1;
default
{
Radius = 9;
+ACTIVATEIMPACT;
}
That?
- Code:
const Number1 1
default
{
Radius 9
+ACTIVATEIMPACT
}
Can't decide! Let's throw all of them into the mix!
- Code:
const Number1 = 1;
default
{
Radius 9;
+ACTIVATEIMPACT
}
Tue Oct 18, 2016 12:06 am
Tue Oct 18, 2016 12:31 am
Nash wrote:MaxED wrote:He has a point, either require the equals sign or don't... same problem with ZMapInfo currently... (needs equals signs but does not need the semicolon but otherwise everything looks like C (braces, quotes for strings etc))
Tue Oct 18, 2016 12:58 am
Tue Oct 18, 2016 1:23 am
Arookas wrote:In my opinion, the biggest hurdle zscript will have to overcome is DECORATE, not the syntax. Although I'm also not so certain so-tightly embedding actor logic with actor animation is a stable design, it is too late to change that at this point. It's not just how DECORATE works, it is how zdoom works.
Tue Oct 18, 2016 3:57 am
Arookas wrote:In my opinion, the biggest hurdle zscript will have to overcome is DECORATE, not the syntax. Although I'm also not so certain so-tightly embedding actor logic with actor animation is a stable design, it is too late to change that at this point. It's not just how DECORATE works, it is how zdoom works.
Thus, I believe zscript should replace DECORATE, not coexist with it. That's not practical because the zdoom development team works so hard for backwards compatibility (not just for older systems, but older mods), and that is admirable...but, I feel zscript will become burdened by DECORATE overtime.
Arookas wrote:I wish separate major versions (e.g. when 2.8.0 was released) was the dropoff point for mod backwards compatibility. Certain features become deprecated in minor releases, and become unsupported or removed in the next major release. Countless other engines are often not entirely backwards compatible when a new major release is out. This is a very important way to allow the engine to grow, while still giving the users some legroom of support.
Arookas wrote:Ultimately, it's up to the developers. I'm very interested in seeing how zscript develops.
Tue Oct 18, 2016 4:06 am
Major Cooke wrote:Also constants would go inside Defaults block.