Moderator: GZDoom Developers
wiki wrote:Actors are now known as classes which must inherit from Actor.
const Number1 = 1;
default
{
Radius = 9;
+ACTIVATEIMPACT;
}
const Number1 1
default
{
Radius 9
+ACTIVATEIMPACT
}
const Number1 = 1;
default
{
Radius 9;
+ACTIVATEIMPACT
}
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.
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?
MaxED wrote:This?
- Code: Select all • Expand view
const Number1 = 1;
default
{
Radius = 9;
+ACTIVATEIMPACT;
}
That?
- Code: Select all • Expand view
const Number1 1
default
{
Radius 9
+ACTIVATEIMPACT
}
Can't decide! Let's throw all of them into the mix!
- Code: Select all • Expand view
const Number1 = 1;
default
{
Radius 9;
+ACTIVATEIMPACT
}
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))
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.
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.
Major Cooke wrote:Also constants would go inside Defaults block.
Users browsing this forum: No registered users and 1 guest