Lithium 1.6.1 (Jan. 24, 2019)

Projects that alter game functions but do not include new maps belong here.
Forum rules
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.

Got a cool project idea but nothing else? Put it in the project ideas thread instead!

Projects for any Doom-based engine (especially 3DGE) are perfectly acceptable here too.

Please read the full rules for more details.

Re: Lithium 1.5.3 (Nov. 22 2017) [2.0 info - pg24]

Postby wildweasel » Wed Aug 08, 2018 10:51 am

Rachael wrote:If Marrub wants to go to Eternity, I say let him. He might give them the boost of exposure they desperately need. I hope he continues to host his mod on this forum with that move, in addition to reaching out where-ever he needs to go to get Eternity users to try it out as well.

And if he decides Eternity does not suit him and he'd rather use GZDoom in the end, it will still be here waiting for him.

And regardless of which port ultimately serves as the medium for future projects, they'll always have a home here. One's choice of port or platform should never be anybody's basis for exclusion.
User avatar
wildweasel
change o' pace.
Moderator Team Lead
 
Joined: 15 Jul 2003

Re: Lithium 1.5.3 (Nov. 22 2017) [2.0 info - pg24]

Postby Machine-Reaper » Wed Aug 08, 2018 12:05 pm

Wasn't ZDoom like father of all Ports?

and GZDoom become like a Mother of all ports and then Eternity and other ports were like children which are still to be recognized.

(Kinda ironic seeing ZDoom dying and GZDoom still alive considering male/female life expectancy rates)

and besides that this forums is dedicated to Doom mods in general, not ports.
User avatar
Machine-Reaper
commander tea cup reporting for duty!
 
Joined: 09 Aug 2013

Re: Lithium 1.5.3 (Nov. 22 2017) [2.0 info - pg24]

Postby Graf Zahl » Wed Aug 08, 2018 12:07 pm

Seeing that Eternity predates GZDoom by several years that makes little sense... :P
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Lithium 1.5.3 (Nov. 22 2017) [2.0 info - pg24]

Postby Machine-Reaper » Wed Aug 08, 2018 12:12 pm

Graf Zahl wrote:Seeing that Eternity predates GZDoom by several years that makes little sense... :P


Really???

I thought Eternity came like, after Skulltag.

(after checking wiki) so it was a mod....hahahahahaha!
User avatar
Machine-Reaper
commander tea cup reporting for duty!
 
Joined: 09 Aug 2013

Re: Lithium 1.5.3 (Nov. 22 2017) [2.0 info - pg24]

Postby Kinsie » Wed Aug 08, 2018 2:03 pm

I feel like a lot of Marrub's issues are caused by his mind-boggling development workflow that involves a lot of compiling from one language to another (not just the C-to-ACS. I think there's something else involving actors?). It's very abnormal for a ZDoom project and I can easily see it causing both a lot of edge-case issues that most people don't normally hit (as well as generally being a pain in the dick to debug), as well as providing an understandable resistance to adopting newer ways of doing things and throwing out reams of hard work in the process. Think Community is Falling 3 and all the innovative features in it (that I think used a custom ACS compiler?) that were natively supported by the engine by the time it came out.
User avatar
Kinsie
A Concept Utterly Obsolete
 
Joined: 22 Oct 2004
Location: MAP33
Discord: Find Me...
Twitch ID: thekinsie

Re: Lithium 1.5.3 (Nov. 22 2017) [2.0 info - pg24]

Postby Graf Zahl » Wed Aug 08, 2018 2:36 pm

Kinsie wrote:I feel like a lot of Marrub's issues are caused by his mind-boggling development workflow that involves a lot of compiling from one language to another (not just the C-to-ACS. I think there's something else involving actors?). It's very abnormal for a ZDoom project and I can easily see it causing both a lot of edge-case issues that most people don't normally hit (as well as generally being a pain in the dick to debug), as well as providing an understandable resistance to adopting newer ways of doing things and throwing out reams of hard work in the process. Think Community is Falling 3 and all the innovative features in it (that I think used a custom ACS compiler?) that were natively supported by the engine by the time it came out.


Seconded. It's pretty much the same impression I got. This project is so far off the beaten path of regular mod making that hitting some rough spots is probably inevitable.
Just FYI, the compiled ACS binaries are 2 MB combined. That GDCC compiler is surely creating large amounts of code that can be extremely hard to debug.
I still suspect GDCC as the main cause of the problems here. Cross-compiling C to ACS bytecode, i.e. a VM with a restricted feature set will inevitably incur some compromises on the code generation side and may feature some hidden bugs.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Lithium 1.5.3 (Nov. 22 2017) [2.0 info - pg24]

Postby Sumwunn » Wed Aug 08, 2018 4:40 pm

I've been working on my DRPG fork off 'n on since November last year and a good chunk of its stability issues has stemmed down to GDCC versions (weird stuff like bitwises bugging out and/or returning values that don't exist, loops not working right, random junk appended to structures and more). I've settled on v0.12.0 64-bit, which gives me the least hassle. Maybe give that version a go Marrub?
It's possible DRPG is simply too much for GDCC but since Lithium has similar issues I'm skeptical. Maybe they are both too much? I dunno.
Stability of both mods does not seem to be affected by any GZDoom versions in my testing.

It seems every other version behaves different from each other especially the 32 & 64-bit versions. Which I find weird. Don't get me wrong I love GDCC and what it made possible but I do believe it's not entirely stable.

I'm considering rewriting DRPG from scratch in ZScript. With no ACS funk.
User avatar
Sumwunn
Runaway script "_Sumwunn" terminated
 
Joined: 06 Jan 2018
Location: Snited Utates
Discord: Sumwunn#9562

Re: Lithium 1.5.3 (Nov. 22 2017) [2.0 info - pg24]

Postby Graf Zahl » Wed Aug 08, 2018 5:10 pm

Sumwunn wrote:It seems every other version behaves different from each other especially the 32 & 64-bit versions. Which I find weird. Don't get me wrong I love GDCC and what it made possible but I do believe it's not entirely stable.


That strongly hints at a compiler bug in the code generator. Uninitialized variables can have bad effects and this thing is extremely complex.

When writing the ZScript code generator I constantly looked at the disassembly output for each small thing I did to ensure it's correct - and there still were some issues that only were found later with actual user code.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Lithium 1.5.3 (Nov. 22 2017) [2.0 info - pg24]

Postby Marrub » Wed Aug 08, 2018 6:06 pm

I apologize for starting an argument here, I was attempting to clarify my disposition, but it came out much more like venting (since it was in a way.)

Sumwunn wrote:I've been working on my DRPG fork off 'n on since November last year and a good chunk of its stability issues has stemmed down to GDCC versions (weird stuff like bitwises bugging out and/or returning values that don't exist, loops not working right, random junk appended to structures and more). I've settled on v0.12.0 64-bit, which gives me the least hassle. Maybe give that version a go Marrub?
It's possible DRPG is simply too much for GDCC but since Lithium has similar issues I'm skeptical. Maybe they are both too much? I dunno.
Stability of both mods does not seem to be affected by any GZDoom versions in my testing.

It seems every other version behaves different from each other especially the 32 & 64-bit versions. Which I find weird. Don't get me wrong I love GDCC and what it made possible but I do believe it's not entirely stable.

I'm considering rewriting DRPG from scratch in ZScript. With no ACS funk.

DoomRPG's issues stem from it being ported from 3 completely different languages over several years and Kyle's lack of understanding concepts in C such as pointers and memory allocation. This mod does not have those issues, and the current latest compiler version produces ACS binaries that are completely stable. If there were code generation issues they could be fixed in the compiler without consequence to the rest of the engine (and similarly changing the engine won't cause issues with ACS binaries unless the VM itself is rewritten.)

Graf Zahl wrote:Just FYI, the compiled ACS binaries are 2 MB combined. That GDCC compiler is surely creating large amounts of code that can be extremely hard to debug.
I still suspect GDCC as the main cause of the problems here. Cross-compiling C to ACS bytecode, i.e. a VM with a restricted feature set will inevitably incur some compromises on the code generation side and may feature some hidden bugs.

It is true that debugging is difficult with the ACS VM, but that's mainly an issue of the way it's implemented in GZDoom. It could do things like unwind the call stack and dump the data stack trivially, but nobody's added such things.

Kinsie wrote:Remember kids: You're not allowed to criticise something if it's free! ...unless it's made by somebody other than me.

There's quite a difference between some mod with a ridiculous workflow and the extremely popular engine made to do everything it's running on. And I'm fine with criticism, what I don't appreciate is people talking shit about David and myself behind our backs because of the way I write my mod. (This is starting to feel like a religious dispute...)
User avatar
Marrub
Xevv Va Rkvyr
 
 
 
Joined: 26 Feb 2013
Operating System: Other Linux 64-bit
Graphics Processor: ATI/AMD with Vulkan Support

Re: Lithium 1.5.3 (Nov. 22 2017) [2.0 info - pg24]

Postby DavidPH » Wed Aug 08, 2018 6:59 pm

Kinsie wrote:I feel like a lot of Marrub's issues are caused by his mind-boggling development workflow that involves a lot of compiling from one language to another (not just the C-to-ACS. I think there's something else involving actors?). It's very abnormal for a ZDoom project and I can easily see it causing both a lot of edge-case issues that most people don't normally hit (as well as generally being a pain in the dick to debug),

To be fair, GDCC compiles from C to ACS bytecode, which is the same number of steps as acc's ACS to ACS bytecode. But yes, he also has his own utility which generates Language files, but that is fairly easy to verify the validity of, and if it were wrong, the results would not likely be subtle.

As far as the abnormality of his workflow, though, I have to defend it as being consistent with any moderately sized programming project. And Lithium is a scripting-heavy mod, so it only makes sense that it deserves the application of good programming practices. Working on data in a maintainable form, such as his Language compiler. Using a build system like make. Version control with a public repository. If a project with as much code as Lithium (in whatever language) were not a Doom mod, you would be far more shocked to not see those things used. It may be unusual for a Doom mod, but that certainly does not invalidate it. (Nor do I think you intended to say it is strictly wrong, I just wanted to make the point clear for the discussion.)

as well as providing an understandable resistance to adopting newer ways of doing things and throwing out reams of hard work in the process.

I am not an avid ZDoom modder (to put it lightly), so I cannot really say from personal experience, but there are people who have taken the time to learn ZScript and find that C or a mix of C and ZScript to be the Right Tool for their purposes. There is probably some amount of inertia, but it is unfair to regard that as the sole motivator for using C in a modern project. (And yes, there are people who have simply declined to learn ZScript entirely, at least until it is more documented and stable.)

Think Community is Falling 3 and all the innovative features in it (that I think used a custom ACS compiler?) that were natively supported by the engine by the time it came out.

As I recall, it only used a custom compiler to lessen certain static limits in the compiler itself. Either way, this is just another reminder that acc is not sacrosanct, nor does it represent the practical limitations of the interpreter.
User avatar
DavidPH
Crazy Compiler Man
 
Joined: 28 Aug 2009

Re: Lithium 1.5.3 (Nov. 22 2017) [2.0 info - pg24]

Postby Rachael » Wed Aug 08, 2018 8:40 pm

DavidPH wrote:Either way, this is just another reminder that acc is not sacrosanct, nor does it represent the practical limitations of the interpreter.

Nor should it be.

But I think this statement ignores the point that the GZDoom ACS interpreter is only tested with acc.exe. It's known to work with that, and that's pretty much the extent any developer is willing to invest in it, especially for a scripting code set that has an improperly licensed source release for its compiler.

I am not going to sit here and say GZDoom's ACS VM is perfect. Anyone who has coloured outside the lines, such as NOT using ACC.exe, knows that it's not. But using ACS bytecode directly, in any form, that is not really what ACC.exe produces, means that we have to download and update GDCC.exe ourselves - which, by itself might not seem like much, but it's just another step in the workflow, it's another hassle to maintaining the code base - in short, it's inconvenient and really doesn't seem necessary.

"Oh but you guys are so lazy, you should support EVERYTHING!" - no, that's not how this works. We do what is reasonable. We provide tools for what we're willing to support. If someone wants to make their own ACS compiler, have at it, Hauss, I'm the last to stop you. But the problems you have with that are something you have to deal with, because you took on the extra responsibility. Don't just throw it on us and blame us for every inefficiency of our ACS VM when you're stretching it to its limits that it was never designed nor tested for. (Not saying you do that, DavidPH, but it feels like the responsibility is being thrust on us by some of your users)

One solution that was proposed was to rip GZDoom's ACS VM out completely, and replace it with the one developed for Eternity. Alright, let's pretend for a moment we will entertain that. If someone does it, I think it should be DavidPH himself. It should be someone who actually cares about his work, cares about the situation as a whole, isn't going to make it half-assed, by not going to test every little bit of it before calling it done. We don't want to end up with a worse implementation than we already have - that'd be crazy! But - and here's the important thing - it would be FAR from the first thing in GZDoom that's ever been redone. It's probably long overdue for one. The problem is, the developers right now have very little interest in ACS outside of map scripting, because right now our main focus is on ZScript and Vulkan.

A better solution would be someone who knows the ACS system much more intimately just going in and trying to fix what problems they can. That's quicker, easier, and probably going to result in a better system overall, than simply trying to replace it with a new one, especially something this complicated.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Graphics Processor: nVidia with Vulkan support

Re: Lithium 1.5.3 (Nov. 22 2017) [2.0 info - pg24]

Postby Marrub » Wed Aug 08, 2018 9:54 pm

Rachael wrote:But using ACS bytecode directly, in any form, that is not really what ACC.exe produces,

(This is the exact opposite of the truth but I get your point :P)

Rachlae wrote:Don't just throw it on us and blame us for every inefficiency of our ACS VM when you're stretching it to its limits that it was never designed nor tested for. (Not saying you do that, DavidPH, but it feels like the responsibility is being thrust on us by some of your users)

I don't think anyone's really ever complained about the ACS interpreter being bad in ZDoom. Pretty much any bugs that've been related to it have been stuff which universally effects all ACS scripts, not just ones using oddball instructions. The (over?)use of ACS in projects like mine is really what makes them stand out. Imagine if ZScript didn't serialize correctly in a major release - everyone would be screaming about it. But that doesn't happen with ACS because it's difficult to debug both for end users and for ZDoom developers, and it isn't used often like I use it, so issues end up going by the wayside. I'm not saying this to blame anyone, but I think everyone could chip in a little to help the issue -- and the attitude that I shouldn't even be doing this in the first place is something that bothers me a lot because it's counter-productive for everyone involved. But, again, if this is the way things are going to be, I should instead be working with a port that supports my workflow, nothing personal, and no need to put blame on anyone.

Ralchae wrote:A better solution would be someone who knows the ACS system much more intimately just going in and trying to fix what problems they can. That's quicker, easier, and probably going to result in a better system overall, than simply trying to replace it with a new one, especially something this complicated.

ZDoom's interpreter is not really all that bad. It has issues that could be resolved, and debugging capabilities that could be useful, but over all it works as it should. (Most of the time.) I think one of the bigger issues is the systems it interacts with causing really weird shit to happen, like HudMessage. But I don't think anyone would ever be able to figure out why it causes crashes, because it causes an unknown error to happen subtly over time.

With the advent of Aeon and EDF finally supporting weapons and player definitions, I'm being won over by nerdy shit I like (AngelScript, data-driven definition languages, intimate ACS integration, etc) which is ultimately the reason I'm moving over. I'm going to be honest and say that I really do not appreciate Graf's attitude most of the time but he is without a doubt a good programmer and (most of the time, nobody's perfect) knows what he's doing. I feel the same with EE's developers, but I'm good friends with them, so that changes the climate quite a bit. :P
User avatar
Marrub
Xevv Va Rkvyr
 
 
 
Joined: 26 Feb 2013
Operating System: Other Linux 64-bit
Graphics Processor: ATI/AMD with Vulkan Support

Re: Lithium 1.5.3 (Nov. 22 2017) [2.0 info - pg24]

Postby Rachael » Wed Aug 08, 2018 10:13 pm

Marrub wrote:I'm going to be honest and say that I really do not appreciate Graf's attitude most of the time but he is without a doubt a good programmer and (most of the time, nobody's perfect) knows what he's doing. I feel the same with EE's developers, but I'm good friends with them, so that changes the climate quite a bit. :P

I'm not a huge fan of it either, but in truth it's more of an acceptance of an unwritten and non-verbal compromise: He is a great programmer, he is the leader of this project, and for a large part this project is his hobby, so we (as moderators) do have to afford him some degree of berth regarding those issues.

However, the problem isn't that he's being hostile, and that's one thing a lot of people miss, in Graf: the issue is more he doesn't realize what he is saying has such a negative effect. For the sake of what he does, for the things he's done for all of us - I am willing to accept that little shortcoming, even if only from him. Mainly because he's not being evil when he does it. (But please keep in mind, I'm not justifying it and saying it's right, nor that I am saying it's right we allow it) It's a small price to pay for what he gives us in return.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Graphics Processor: nVidia with Vulkan support

Re: Lithium 1.5.3 (Nov. 22 2017) [2.0 info - pg24]

Postby a.dusty.taco » Thu Aug 09, 2018 1:38 am

How do you get the reality distortion? Is it really a thing? I can't seem to get it anywhere...
a.dusty.taco
 
Joined: 25 Jul 2017

Re: Lithium 1.5.3 (Nov. 22 2017) [2.0 info - pg24]

Postby DavidPH » Thu Aug 09, 2018 5:57 am

Rachael wrote:But I think this statement ignores the point that the GZDoom ACS interpreter is only tested with acc.exe. It's known to work with that, and that's pretty much the extent any developer is willing to invest in it, especially for a scripting code set that has an improperly licensed source release for its compiler.

Don't just throw it on us and blame us for every inefficiency of our ACS VM when you're stretching it to its limits that it was never designed nor tested for. (Not saying you do that, DavidPH, but it feels like the responsibility is being thrust on us by some of your users)

I have to admit that I get a little confused/bothered at times by the implication that GDCC is designed to do something weird to the interpreter. Outside of usercode calling VM builtins, the code GDCC generates uses the available instruction set in a manner consistent with acc. That is, relying on the same observable results acc does. And if it does not, that is a bug to be fixed in GDCC. Plenty of it is code that you could get acc to generate verbatim (unsigned right shifts, multiword returns, extended arguments). And even usercode calling VM builtins is implemented consistently, it just allows for exposing some that acc does not.

For what it's worth, though, when someone is using GDCC and has some kind of script issue, I expect them to come to me before the ZDoom devs. And only in the (highly) unlikely condition that the problem is determined to lie in ZDoom itself should it be escalated to there. And even then, only once a minimal reproduction can be made with ACS and acc.
User avatar
DavidPH
Crazy Compiler Man
 
Joined: 28 Aug 2009

PreviousNext

Return to Gameplay Mods

Who is online

Users browsing this forum: Eyesofdarkness, Player701 and 7 guests