F#!? I said before that even though I like Haskell, I would never recommend it. F# is as much a functional programming language as Haskell is, despite it trying to be also imperative. Functional programming languages are things you simply don’t want to force on a scripting community for a game. People with experience in php, C(/#/++), python etc. can Lua easily enough, but with a functional language they will go “WHAT THE FUCK HOW DOES THIS WORK”
You should know that the purely functional paradigm (i.e. Not F#) has no notion of changing variables, casual sequential commands (you need monads), loops and classes.
I remember full well asking myself “how the fuck can you program anything if you can’t change your variables?”. F# has the above constructs, but only because it tries to be both functional and imperative. People will still have huge trouble with concepts that the functional paradigm introduces:
Monads, currying, lazy evaluation (not f#, but still functional), the type system in general, data types, classes (not to be confused with OOP classes), catamorphisms, anamorphisms and hylomorphisms.
I reckon that even to many seasoned scripters in this thread I look like I’m making up words. Functional languages are too different from imperative languages to expect anyone, especially in a scripters community like this to latch on quickly. That is exactly the power of Lua.
Listen to this man.
My Haskell-obsessed friend tried to convince me to learn it a few months ago.
Never again. Until next semester when I take a class in functional programming. Kill me.
And .NET/Mono actually already has built-in functions to call delegates/events (hooks, basically) asynchronously and the results can be checked at any time, or you can wait for the results to arrive. Meanwhile, you can execute other code.
Starting with .NET 4, the async/await paradigm really took off, and even my lil’ brother who used C# (his first programming language) for only 2 days easily understood it and was able to make a simple text file viewer that never gets stuck on huge files (tens/hundreds of megabytes).
I thought it might be nice - not necessarily a good idea. I can clearly see why C# or Lua are superiour choices for this use case.
Also, I’m not one of those people who pushes functional programming to the exclusion of anything else. I use C# and C++ in my day job.
Anyway, you can declare mutable variables in F#. But again, it doesn’t look enough like C or Lua to be particularly helpful to the majority of users so I recognise that it wouldn’t actually be a serious contender. If we do end up with .NET Core, we should still stick to one language I think - and that would most likely be C#.
You can probably stop debating languages now. We have decided our priorities.
What sucks in Garry’s Mod, what do you want to do in Garry’s Mod 2 that you couldn’t in Garry’s Mod?
Player movement on moving entities
-More 3rd party libs (it’s the right name, right ?) like ScaleForm GFx (Renders vectorized shapes with Flash), maybe Oculus support by default and TrackIR , so we could play on multilayer server without being GAC’ed
-A new/better physic engine, let’s be honest : players collision sucks, the weld system sucks (See Willox post)
-More than one thread, we can’t let the game be stuck because of one core performance.
-Remove the saves/dupes from the workshop, i mean on the workshop page you can “sub the dupes” but will be deleted when you start gmod because it’s not a valid .gma file, it’s also spamming the workshop with shit.
-Better support for “load/add/reload entities/weapons without reload the map”
The engine is being replaced. No more old version of Havok, and very likely proper use of multiple cores.
A new physics engine alone wouldn’t fix the player-player or player-prop collisions though. The issue is that there’s no leniency for clients to deter from the server’s calculations and props/other players aren’t predicted at all client-side so they ‘lag’ behind based on data the server networks instead.
Wait … do you really need prediction in singleplayer ?
(It happens also in singleplayer)
I’m talking 'bout multiplayer. You do need prediction for listen servers though, even if the lack of is going to be hard to notice.
I don’t think vphysics handles movement on props awfully well, but on singleplayer it’s going to network properly at the least. WYSIWYG.
We have to remember that Garry’s Mod isn’t just about developers. We also need to think about gameplay for your “average everyday gamer”. Even though it is importation to supply developers, mappers and modelers a like with the tools and resources they need. Some people are saying that Garry’s Mod should become its own game with its own models. Though I do support this, I still think Garry’s Mod should still support external games. Because that’s what Garry’s Mod is known and loved for. So I think new content for the player base should be focused on a great deal as well.
So what if Garry doesn’t like it, it’s not like he’s releasing addons.
I don’t like wearing pants at home, but does that mean everyone else has to walk naked while visitting my house?
Ye well, the point is that there are alternatives that other might also find easier to use.
Then change language so just this, tiny group of people is happy?
[editline]8th July 2015[/editline]
I mean, Lua is so easy and effective, that they even teach it to kids: http://luaforkids.com/introduction/whats-lua/
the game name,
voice chat quality(?)
Also, huge things like:
Model damaging thing we see in GTA IV/V,
Being able to dig some map parts (,models) (map creators would have to specify what can and cannot be digged)
I believe what really needs changing in GMod is the way decisions are/were made. It’s an old behemoth of a game, and every decision was right-ish… when it was taken.
Only when the GMod 13 beta started, I’ve seen you worry about future-proofing a bit. And your devblogs definitely show that future-proofing is now a priority (or even routine) for you. So I believe you’re on the right track.
All I wish is that you keep thinking long-term before short-term.
As far as APIs go, I believe you should allow the community to write asset loaders.
This would allow people to work on loading assets for virtually any game, and it would rid you of any legal responsibility. (we know other game devs are butthurt about this)
If the loaders are distributed through “non-official” channels (e.g. not the Workshop), no butthurt dev would go around chasing tens/hundreds of thousands of users.
One major benefit of custom asset loader is that people would be able to create models/textures/sounds in whatever format they want and use it immediately in the game.
(e.g. PSD textures, raster fonts, emoji fonts)
[editline]pl0x[/editline] Why not, layla?
The top 3 things that suck in GMod, in no particular order, are:
The lack of multi-threading for the engine/physics/Lua (This is 2015 and processors do not have the same single-core performance they once had; instead we have more cores to spread the load over).
Side note: Lua multi-threading could be created whereby each addon works in its own thread; just need a communication ability.
Networking communication for Lua threads on the same server should be low enough latency not to notice whereas today with single-thread Lua massive amounts of code in the same thread can slow down a server tremendously.
The outdated and antiquated physics that you still refuse to get the license for to fix the crashes it makes (It sucks, it’s old, and it crashes servers all the time).
Arbitrary limitations and the lack of garbage collection (modelprecache 2048 models, lua files 2048, etc). I personally haven’t hit the lua file limit, but modelprecache gets full all the time and crashes servers and clients.
Things like the modelprecache could remain at a limit if the least-used paths of them could get flushed and replaced with new ones. It’s just silly to be in 2015 and there’s so much ‘baby-proofing’ still around.
As a special bonus, not being able to debug mdmps and sending you mdmps to no response does not give any useful info. The metastruct site doesn’t have the symbols so it provides no useful information about the call stack that caused a crash.