Let's switch to C++ ?

[LORD KILLA]

Hi guys.
Here just an idea so far: Why don't we switch to C++ instead of old pascal, wich is instable as scripting core? Well, the main idea is a normal C++ compiler, for example g++ (from gcc - GNU compiler Collection). We could write a normal C++ console app, but connected to the server somehow, If we could attach the app to the server process, we could set pointers to the variables of the game, like health/ammo/etc.... Btw pointers, that isnt possible in the normal scripting core same as classes, structures, defines, indludes/headers, and much much more stuff. If the scripting part would be running in another process, we could avoid crashes of server. For example, a error occoured and the server changes into a uncontroled process, but if the C++ app would be outside, in a different process, the server wouldnt crash, only the C++ app, what would happen much less often then the now instable pascal scriptcore, where classes/other sweets arent allowed in. But help from enesce or MM would be needed, becouse of the pointers (pointer: "Where should i point to? o_O" lol).

Facts

[/font][/size]
          Why YES
• Faster, if correctly implemendet by enesce/MM.
• Nearly absolutely crash-save(much much more stable), becouse of external processing.
• Classes/structures/pointers/defines/includes or headers/more...
• The app won't crash by itself.
• much much more... =)

          Why NO
I couldn't find any nice arguments...

I hope i won't get a ban =\
Thanks for reading.

[Furai]

I'll wait for EnEsCe to comment this thread. ;p

[iDante]

Oh LORD KILLA, you make my dreams come true.

There is no "we." Soldat is a dictatorship, and currently EnEsCe is our supreme leader.
Check out openSoldat for shabalooza.

[croat1gamer]

I'd prefer Lua or to stay like it is now. But with more options ofc.

[dnmr]

are you sure you're not confusing stability, performance and features? Remaking a huge part of the server wouldnt really give you too many features, would it? Especially since that effort could have been put in something more productive. Why would you need classes in scripts? There are structs btw, are you not happy with them? Or you just want to make things generally more complex and irritating just because pointers are cool?

[LORD KILLA]

Why this topic fails:
 - Your poll contains two 'yes' options. That makes it annoyingly difficult to see the end result, especially since users will not take it seriously.
 - gcc sucks under windows. If windows is your target OS, might as well use microsoft's own compiler or intel's
 - This requires a complete rewrite. And, most likely, this will require much more code and effort on eC/MM's behalf since Delphi does a lot of stuff for you that c++ expects you to do on your own. So, they cbf.

Only hope you have is...
>> http://opensoldat.u13.net/ <<

Pretty much all servers are running under linux, and gcc was mainly created for linux.
Well, the soldat-pascal is very instable, and it doesnt support all the classes(I'm now happy with structs, they havent got constructors), pointers, ... You cant even initialize a variable at declaration =|.
Well, one big part is, when the c++ app would crash, only it would crash and not the server together. A very easy structure to the server and the c++ app can restart it in short time after crash. Just send some data that forces the other sde to respond, if it doesnt, it's process is killed and it is started again.
Well, pointers are really cool. You can create arrays and modfiy their size easily: "char* lol = new char[sizeof(roflcopter)];".....

[pavliko]

Lol why should we change to something complicated as c++ ? Pascal is so easy to script >.< . So lets maybe change to c# because we are sick noobs that just need a cooler language. Leave pascal alone!

[Shard]

Um, I have absolutely no clue about this. Can someone explain this all simply, for me, and others like me out there?

[croat1gamer]

Scripters stuff.
If you play on non scripted servers avoid this.
If you play on scripted servers, its for the possibilities of the scripts.

[Gizd]

This would be useless at bigger scale and would just take ages to develop since we have only eC...

[Clawbug]

All I can say is... this is pathetic.

LORD KILLA, please, make your own game in C++ first. I know you haven't done it. I also know that you have no programming experience and that you don't probably know what a debugger is.

In short; someone lock this topic for good.

2) structs != classes. A struct is slightly similar to a class, except it has no methods (functions) and all members (variables) are public. Other than that, they are not interchangeable and the only reason c++ has them is to support older C libraries that people might want.

Otherwise good, but the only difference between struct and class is the fact that all the members of a struct are public by default. For class they are private by default. Keeps the backwards compatibility that way. So you could replace all the classes with structs if you wanted to, as long as you keep the access levels compatible. Same vice versa.

[hkayak]

All I can say is... this is pathetic.

LORD KILLA, please, make your own game in C++ first. I know you haven't done it. I also know that you have no programming experience and that you don't probably know what a debugger is.

In short; someone lock this topic for good.

2) structs != classes. A struct is slightly similar to a class, except it has no methods (functions) and all members (variables) are public. Other than that, they are not interchangeable and the only reason c++ has them is to support older C libraries that people might want.

Otherwise good, but the only difference between struct and class is the fact that all the members of a struct are public by default. For class they are private by default. Keeps the backwards compatibility that way. So you could replace all the classes with structs if you wanted to, as long as you keep the access levels compatible. Same vice versa.

then you must have a better solution to improve the stability of scriptcore? if not why are you speaking? every scripter that us making scripts for scriptcore knows that scriptcore isn't stable and nor will it be as the programming language for it isn't the good one we all need to find a good language to use for our scriptcore, scriptcore is the base without a base nothing will survive the soldat base is getting destroyed atm if eC and MM see a future in soldat they better take action now and repair the base or improve it before every scripter says:  "That's enough no more scriptcore for me I'm sick of it!' and when that happens soldat will collapse

[Clawbug]

All I can say is... this is pathetic.

LORD KILLA, please, make your own game in C++ first. I know you haven't done it. I also know that you have no programming experience and that you don't probably know what a debugger is.

In short; someone lock this topic for good.

2) structs != classes. A struct is slightly similar to a class, except it has no methods (functions) and all members (variables) are public. Other than that, they are not interchangeable and the only reason c++ has them is to support older C libraries that people might want.

Otherwise good, but the only difference between struct and class is the fact that all the members of a struct are public by default. For class they are private by default. Keeps the backwards compatibility that way. So you could replace all the classes with structs if you wanted to, as long as you keep the access levels compatible. Same vice versa.

then you must have a better solution to improve the stability of scriptcore? if not why are you speaking? every scripter that us making scripts for scriptcore knows that scriptcore isn't stable and nor will it be as the programming language for it isn't the good one we all need to find a good language to use for our scriptcore, scriptcore is the base without a base nothing will survive the soldat base is getting destroyed atm if eC and MM see a future in soldat they better take action now and repair the base or improve it before every scripter says:  "That's enough no more scriptcore for me I'm sick of it!' and when that happens soldat will collapse

So you're claiming that Soldat's future lies on scripting? Bullshit I say. Soldat's future lies on solid gameplay, not wimpy scripts.

The problem is NOT the programming language. It's the PROGRAM. If your houre collapses, you blame the builder and the architecture, not the tools used.

[hkayak]

I am blaming the tool and quess what! the builder is responsible for it if the tool fails the progam will fail too you are talking bull shit here i dont say that we need to use c++ i know that c++ is circuitous we dont need to use c++ there must be a better stable programming language

[ramirez]

It would be neat if the server was extensible by dynamic libraries, but there would be absolutely no point forcing people to use C++. It's a complex language; way too complex for many people to even bother learning. One thing that keeps modding community active and interesting is ease of modding, forcing something like C++ to users would be essentially the same as ruining that. Running the scripts in their own process is a nice idea (essentially the same what Chrome does browsing sites), but there are many problems with that approach as well. Running each script in their own process complicates a lot how the scripts interact with the actual game, because processes don't got direct access to other processes. Basically it'd mean that IPC (Inter-process communication) would be needed, and that even further complicates the whole deal, and would put many users away. I would rather see that the core would be extensible by dynamic libraries that are loaded in the server's process space, which simplifies things a lot. It's also more efficient, but the downside is that isomeone who doesn't know what they're doing could potentially crash the server.

That being said, all of that shouldn't be used for _scripting_, it should only be used for _extending_ the script core. Adding new functionality to it and such. Scripts themselves should still be written in some high-level, dynamic language that is easier and more accessible to wider audience. That being said, if a scripting engine is implemented correctly, and doesn't suck, it should never, and I mean never, crash the application itself. If a program lets user-written script, that is parsed and executed in a separate context, crash the software, it's the software that is at fault. Any good library that implements a scripting language would not crash the program itself, even if there was an error in a script that was run.

And I agree that Pascal scripting is not the best choice for the scripting language. Even putting aside the stability issues (which I don't admittedly know a lot about), I find it a very clumsy/non-intuitive language to be used for scripting, when there are dynamic, modern languages such as JavaScript (eg. the Google's V8 engine or Mozilla's SpiderMonkey), Lua, or even Python or Ruby. I would be much happier to see any of the above languages, and I am sure many others would as well.

[Veritas]

Did you just suggest using JavaScript for something other than web applications

What

[jrgp]

Did you just suggest using JavaScript for something other than web applications

...

Javascript is just a scripting language like any other. Certain apps even use it at the core for their UI design. Firefox does it and so does the majority of Mozilla's other apps. Did you realize that ALL firefox extensions, not to mention the entire UI, are written in javascript and css?

[Veritas]

Yes, and they do it because they have a JS engine at the core of Firefox.

JavaScript itself is up there with Visual Basic and PHP in terms of terribad language design.

[ramirez]

Uh, JavaScript is a very nice language for other stuff than web scripting. The reason why many people think that JS is terrible is not because of the language, but because of the stuff that browsers add to it and do differently (wee, portability issues!). But yeah, all that Document Object Model stuff that browsers do has absolutely nothing to do with JS itself. JavaScript is based on ECMAScript standard, that many other languages use as well (eg. ActionScript that is used in Flash). In terms of functionality, it's also very similar to Lua (which is also a prototype-based language).

[HeavyMetal.Penguin91]

A good argument for Pascal is that it is easy and safe. I found (and who else agrees?) that Pascal was a lot easier to learn than C  , and it's hard to do any damage (Forget to deallocate some dynamic memory in C   and you could crash your OS - I know I have ). Soldat already interferes with other programs running and the desktop, I don't want some careless scripter crashing my PC and messing with anything else I got running.

But all that said, I still voted for C  . Complex shizzle is a b***h to work with in Pascal, like linked-lists and polymorphic functions.

The problem is NOT the programming language. It's the PROGRAM. If your houre collapses, you blame the builder and the architecture, not the tools used.

This is rubbish - I can't be bothered to give a proper argument, but if the tools had no effect on the programmer, we'd all still be fucking around with punched cards and binary or assembly.