Project Einherjar - Final-FINAL Release

[skyrish10]

I'm not good at spotting bugs, but I had no problems at all, except for map 34.It lagged a lot, but I believe that it was my computer.

nope, it's those strobe lights, which they are generating dynamic lights too much, that's why is lagging

[Rachael]

nope, it's those strobe lights, which they are generating dynamic lights too much, that's why is lagging

Partially true. If it really were that simple, then simply shutting off dynamic lights would fix this problem.

What's happening is the strobe emitters are shooting projectiles to make their lights. It'll probably kill a lower-end CPU due to the amount of bottlenecking involved in GZDoom's physics processing.

What you can do is when you are in MAP34, remove the emitters from the map instead (using the console - commands provided below - you can actually just copy-paste that line in while playing the map), and the projectiles no longer get spawned. That saves a lot of CPU cycles if your CPU really can't handle it. Honestly, anything built within the last ~13-ish years should not have any problem with it, though, so I am surprised this was even reported as an issue.

Code: Select all

remove StrobeEmitterGreen; remove StrobeEmitterRed

[ImpieTwo]

Hi!Just thought I'd let you know I finished the whole game.I'm not good at spotting bugs, but I had no problems at all, except for map 34.It lagged a lot, but I believe that it was my computer.I used the GZDoom nightly build from Mar. 27.I'm really dumb about this stuff, sorry.I enjoyed this VERY much.Thought the gameplay was good, graphics good as well.Hope this helps some!

I've had others tell me the same problem with map 34, so I guess it is a map problem. Thanks for mentioning this so I know for sure that it's this map specifically.

EDIT: I removed all but the most essential strobes, so it should be better now. Hadn't realized how many I used. 5.2 is up now.

EDIT2: Fan project I was making on the side:

[grouchbag]

Ok, thanks for telling me, at least it wasn't entirely my computer, but maybe a little.Either way, I like this game and look forward to the official release.Thanks!

[SoundOfDarkness]

Just wondering... Why are some enemies speaking english and others german? Is there a reason behind this or is it just because you couldn't find enough english speech samples?

[ImpieTwo]

Just wondering... Why are some enemies speaking english and others german? Is there a reason behind this or is it just because you couldn't find enough english speech samples?

The game is set in two different postapocalyptic nations. I use English and German to distinguish the two peoples, so if they speak German, they're Jotuns; English, they're Midgardians. The dominant gender is also a sign of which country you're in usually, since Midgard is matriarchal and Jotunheim patriarchal.

[SoundOfDarkness]

Thanks for the answer. I think it's time I really play the mod and not just playing random levels for fun.

[ImpieTwo]

Did anyone check map 34 to see if the slowdown issue was resolved? I need to make sure that's cured before I beg someone to upload it to idgames for me (can't upload to save my life as usual.)

[Enjay]

Oh, I hadn't noticed that the fix was up. I'll check it later.

ImpieTwo already knows this but for anyone interested, that map was causing me noticeable slowdowns (and one system lock up) on an i7-6800K 3.4GHz machine with 16GB of RAM and a GTX1080!

[ImpieTwo]

Oh, I hadn't noticed that the fix was up. I'll check it later.

ImpieTwo already knows this but for anyone interested, that map was causing me noticeable slowdowns (and one system lock up) on an i7-6800K 3.4GHz machine with 16GB of RAM and a GTX1080!

Yeah, I took out more than half the strobes on that map, so I'm hoping it's fixed. Hadn't realized how badly I'd spammed those objects. There were about forty or so on the map; now theres, like, seven.

[Enjay]

Yup, the map works just fine for me now; no hint of slowdown.

I know that those strobes do spawn a lot of secondary actors and that they all have dynamic lights attached but, even so, I'm surprised how big an impact they had on performance. I mean, OK, there were around 40 of them but Doom can handle hundreds of actors. I wonder if there is something either inherently flawed with the actor or if it is exposing a problem (memory leak or something) in GZDoom? Or maybe it is just that all those actors, subsidiary actors and dynlights is too much after all.

[edit]
Oh, BTW these errors are posted to the console when I start the game:

Code: Select all

Script warning, "PE521.pk3:junoguns.wad:DECORATE" line 32:
Numeric type expected, got "Reload"
Script warning, "PE521.pk3:junoguns.wad:DECORATE" line 65:
Truncation of floating point constant 0.250000
Script warning, "PE521.pk3:val3d baddies.wad:DECORATE" line 71:
Truncation of floating point constant 0.250000

The first one is because you have:

Code: Select all

BKNF B 0 A_Jump("Reload",0)

[wiki]A_Jump[/wiki] is supposed to be...

Code: Select all

A_Jump (int chance, str "state", ...) 

The state name is supposed to be after the chance. BTW I think that it just happens to work because of how the rest of the state sequence is setup. This line can't work the way it is set up (and it may not even be needed).

The second and third errors are because you are using "random" for floating point values.

Code: Select all

A_ChangeFlag("NOPAIN",Random(1,Random(0.25,2.0)))

and

Code: Select all

TNT1 A 0 A_ChangeFlag("NOPAIN",Random(1,Random(0.25,2.0)))//otherwise the ripping would make it very OP

If you are using floating point values, use frandom instead of random. Random only picks integers and the above lines specify fractions as part of the random range.


Also, it would have been much easier to track these down if you didn't have multiple files called DECORATE in your WADs. I suggest renaming all the specific lumps to something meaningful and having one file called DECORATE that just includes all the other lumps.
e.g. the DECORATE lump for junoguns.wad could look like...

Code: Select all

#include junoplyr
#include knife
#include seagpstl
#include seagrfl
#include seagshtg
#include seagzip
#include seagboom
#include seaguzi
#include balknife
#include mako

then rename the various decorate lumps to junoplyr, knife, seagpstl etc etc

If you do that, then error messages will pinpoint exactly which file has the problem. Set up like this, the first error would have read...

Code: Select all

Script warning, "PE521.pk3:junoguns.wad:BALKNIFE" line 32:
Numeric type expected, got "Reload"

[ImpieTwo]

^Yeah that's a good idea. It's been a pain for me to find errors because of this, but I'm a new Decorate user and don't know all the tricks yet. I didn't even know "frandom" was a thing.

Thanks for the help in digging this garbage up. I'll fix it asap.

[Enjay]

Yeah, I wasn't fully aware of frandom either until fairly recently. It was the more recent versions of *ZDoom spitting out this particular error that really highlighted the need for it to me.

BTW, is there a reason that you are keeping the project as WADs inside a PK3 rather than using the PK3 format properly? If not, it might be worth going over to the PK3 format fully. That allows greater organisation of resources (e.g. sub folders for sprites, sounds etc) and lump names longer than 8 characters so, for example, the various DECORATE lumps could be named more meaningfully. If you're interested, have a poke around inside my Waterlab PK3 ( viewtopic.php?f=42&t=55741 ) because I used the PK3 structure quite extensively there.

Also, something that I found very useful during the development of Waterlab: If you have a folder that has all the lumps and folders from the PK3 in it (but the lumps are "loose" inside the directory, not zipped up) you can load the folder directly into *ZDoom. This means that graphics, text files, whatever can be worked on directly in their respective folders and then all you have to do is zip things up into a PK3 when you want to package it up for release.

[ImpieTwo]

It's easier for me to organize things this way than by separating every element's components into different directories: the proper way feels like having a project team, but putting each department in a separate building rather than having them all in the same office. And it's still quick and easy for me to find what I want, so taking all the time to organize it the other way would be kind of a waste for the most part. For me the only real benefit to the proper way is the mods will likely take less ram to run (and working on "loose" assets like you mentioned i guess, to do away with all the importing and whatnot). Might have it organized proper when I'm finished with it.

Just how I'm wired I guess.

[Enjay]

I figured it might be something like that. Keeping things together in WADs does allow the whole thing to be quite modular.