[WildCard65]

Originally Posted by Neuro Toxin I'm use to casting in other langs. And can see if someone only used source pawn how they could get tricked between syntax. Edit: lets use the new syntax here. float val = float (someval); Wait a sec. That's not right lol

PHP Code:

#if !defined __sourcepawn2__
/**
 * Converts an integer into a floating point value.
 *
 * @param value            Integer to convert.
 * @return                Floating point value.
 */
native Float:float(value);
#endif 


[nergal]

Originally Posted by KissLick Should I port this to 1.7 syntax? And who is gonna port Zombie:Reloaded, UMC or SourceBans etc. ?

Easy, Converted it all to 1.7 syntax with nothing flat.

I suggest you replace the enum-structs with actual variables and methodmaps however...

in case you're wondering how I was able to convert it so fast, I made a regex parser in Python that changes old syntax to new syntax.

[Potato Uno]

The parentheses just adds spam to the code like so:

PHP Code:

if (view_as<TFTeam>GetClientTeam(iClient))
if (view_as<TFTeam>(GetClientTeam(iClient))) 


It should have been left as optional but there is no point arguing since it's here to stay. And yes, I know there is a TF2_GetClientTeam native or whatever it is called.

Also nergal, you don't understand how spcomp works. Old syntax and new syntax compile to the same bytecode. For all the JIT gives a shit about ("sourcemod" on srcds) they are the exact same thing and it can't tell which plugins came from old syntax and which plugins came from new syntax.

So there's no point in carrying your already-unsupported-and-defeated argument of breaking old plugins. At its core, the JIT needs to be able to support everything. The devs can make many variants of spcomp if they want to, where old plugins may not compile on one spcomp but it will in another, but the final bytecode has to be supported by the VM at the end of the day.

So congrats wasting your time converting plugins that have absolutely no change before and after with respect to the JIT.

[WildCard65]

Originally Posted by Potato Uno The parentheses just adds spam to the code like so: PHP Code: if (view_as<TFTeam>GetClientTeam(iClient)) if (view_as<TFTeam>(GetClientTeam(iClient)))  It should have been left as optional but there is no point arguing since it's here to stay. And yes, I know there is a TF2_GetClientTeam native or whatever it is called.

The parenthesis requirement for view_as was added because it looks nicer then without, it's also how c++ casting works:

PHP Code:

int a = 10;
void *p1 = static_cast<void*>(&a); 


[Miu]

Originally Posted by WildCard65 Is actually: new Float:val = float(someval);

that's an actual cast, not the same thing as view_as<float>() or Float:

[klippy]

Originally Posted by Miu that's an actual cast, not the same thing as view_as<float>() or Float:

And that, in my opinion, adds more confusion. Yeah, tags instead of types are a really bad concept. I think that user-defined type conversions would be great, just like for example C# and C++ have.

[Drixevel]

Originally Posted by WildCard65 Is actually: new Float:val = float(someval);

If you want to take the example too literal.

[nergal]

Originally Posted by Potato Uno Also nergal, you don't understand how spcomp works. Old syntax and new syntax compile to the same bytecode. For all the JIT gives a shit about ("sourcemod" on srcds) they are the exact same thing and it can't tell which plugins came from old syntax and which plugins came from new syntax. So there's no point in carrying your already-unsupported-and-defeated argument of breaking old plugins. At its core, the JIT needs to be able to support everything. The devs can make many variants of spcomp if they want to, where old plugins may not compile on one spcomp but it will in another, but the final bytecode has to be supported by the VM at the end of the day. So congrats wasting your time converting plugins that have absolutely no change before and after with respect to the JIT.

IIRC, the new syntax uses actual types and not tagged 32-bit integer based types unless a certain someone was lying...

So how's it compiling to the exact same bytecode regardless of version used?

You've got alotta 'splainin' to do!

[Miu]

Originally Posted by nergal IIRC, the new syntax uses actual types and not tagged 32-bit integer based types unless a certain someone was lying... So how's it compiling to the exact same bytecode regardless of version used?

what would the difference be? o__O

[WildCard65]

Originally Posted by nergal IIRC, the new syntax uses actual types and not tagged 32-bit integer based types unless a certain someone was lying... So how's it compiling to the exact same bytecode regardless of version used? You've got alotta 'splainin' to do!

I seem to recall asherkin saying something about spcomp for SM 1.7(and 1.8 as well) compiling to same bytecode and it makes sense as Lysis can still decompile the new syntax without any special casing for 1.7(I BELIEVE).