Jump to content
The Dark Mod Forums

Beta Testing 2.08


stgatilov

Recommended Posts

SVN only has a 64-bit exe now, TheDarkModx64.exe, so that DR complains every time I change the FM project because it can't find TheDarkMod.exe. Are we getting rid of the 32-bit .exe for 2.08? In that case we'd need to rename the 64-bit exe to stop DR from throwing that error message.

Link to comment
Share on other sites

On 3/13/2020 at 2:47 AM, Springheel said:

I downloaded the SVN for the release branch, and although I did find a missing definition for one of the new zombies, the beastmen were properly textured.  Unless someone else can confirm the problem, I'm not sure where else to go with this.

I still see the following issues in SVN:

SVN:

Spoiler
  • werebeast mesh exists twice, (2nd one is models/md5/chars/monsters/werebeast/werebeast_mesh - Kopie.md5mesh)
  • manbeast body mesh uses the manbeast01 material 2 times and the manbeast_hair01 material 5 times
  • manbeast head mesh uses the manbeast_hair01 material 2 times
  • manbeast_hair01 material shows as "shader not found"
  • in the "Create entity" list, a new top-level folder "creatures" contains the heads, vocal set and ragdoll, which breaks conventions
    • heads are usually in Internal/AI
    • vocal sets are usually in AI/Internal/Vocal Sets
    • ragdolls are usually in Ragdolls/Bodies
  • the entities atdm:ai_undead_zombie_alt_animations and atdm:ai_undead_zombie_clothed01 are missing models, so I see just a "shader not found" box
  • the model zombie_alt01 uses the zombie_rags material 2 times
  • the material models/monsters/zombie/boney/boney on the model zombie_alt01 doesn't exist
  • the material zombie_test on the model models/md5/chars/undead/zombie/zombiehead01.md5mesh doesn't exist.

Beta 2.08 has some additional issues, will make a list of them later on. (i.e. the werebeast is covered in "shader not found").

Link to comment
Share on other sites

On 3/13/2020 at 2:20 PM, nbohr1more said:

I've been tinkering with this issue by trying to bypass the GL error check in Framebuffer.cpp if the player isn't "ready" but no permutation

of this has worked thus far. I think the other "quick fix" is to provoke reloadModels after PlayerStart is complete.

This is one stubborn issue. Every crude way I can think of to address it has failed.

Forcing "reload models?

No.

Forcing SoftShadowsQuality to toggle after PlayerReady?

No.

I am inclined to think this is a driver bug. Maybe we exclude the secondary GL error check for Nvidia?

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

On 3/13/2020 at 8:47 AM, Springheel said:

On another note, is the game supposed to default to windowed mode now? 

Fixed on trunk.

22 hours ago, Dragofer said:

SVN only has a 64-bit exe now, TheDarkModx64.exe, so that DR complains every time I change the FM project because it can't find TheDarkMod.exe. Are we getting rid of the 32-bit .exe for 2.08? In that case we'd need to rename the 64-bit exe to stop DR from throwing that error message.

No, 32-bit executables will be in 2.08 release.
I decided to remove them from trunk because keeping them up-to-date means double SVN storage, and not keeping them up-to-date has already caused some confusion.

22 hours ago, Dragofer said:

I still see the following issues in SVN:
in the "Create entity" list, a new top-level folder "creatures" contains the heads, vocal set and ragdoll, which breaks conventions

Beta 2.08 has some additional issues, will make a list of them later on. (i.e. the werebeast is covered in "shader not found").

I guess the only additional issues of beta release which are important are those caused by manifest including/excluding something which it should not.
If you want to rename any assets already released in 2.07, please write PM a full list to me. I can run a script over all released FMs to check if they are used anywhere. Because if they are already used somewhere, then renaming them becomes a much greater problem.

Link to comment
Share on other sites

Is there a way to get the old swimming animation back? Preferably using spwanargs or changing def files?

Link to comment
Share on other sites

4 hours ago, Goldwell said:

Is there a way to get the old swimming animation back? Preferably using spwanargs or changing def files?

I'm not sure what do you mean by "swimming animation".
If you talking are about player swimming movement, then I guess the answer is no. Most likely the movement is built into C++ code. According to comment, cvars can be used to change that. But since they are archivable, changing them programmatically would mean breaking them for an unaware player.

  • Thanks 1
Link to comment
Share on other sites

3 hours ago, stgatilov said:

I'm not sure what do you mean by "swimming animation".
If you talking are about player swimming movement, then I guess the answer is no. Most likely the movement is built into C++ code. According to comment, cvars can be used to change that. But since they are archivable, changing them programmatically would mean breaking them for an unaware player.


I’m referring to this: https://bugs.thedarkmod.com/view.php?id=3550

 

And that’s a bummer. I’m not a fan of the new swim style at all.

  • Like 1
Link to comment
Share on other sites

2 hours ago, Goldwell said:


I’m referring to this: https://bugs.thedarkmod.com/view.php?id=3550

 

And that’s a bummer. I’m not a fan of the new swim style at all.

These don't work?

 

The degree and frequency of modulation can be altered via cvars:
cv_pm_swimspeed_variation
cv_pm_swimspeed_frequency

Link to comment
Share on other sites

The "cv" append is internal code.

In the console, setting:

pm_swimspeed_variation 0.0
pm_swimspeed_frequency 0.0

should revert to the old swim behavior.

 

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

5 hours ago, nbohr1more said:

pm_swimspeed_variation 0.0

Setting this parameter is sufficient. I get that some people might want to disable this new viewport animation. Probably the same people that disable head-bob in FPS-games.

Link to comment
Share on other sites

22 hours ago, nbohr1more said:

The "cv" append is internal code.

In the console, setting:

pm_swimspeed_variation 0.0
pm_swimspeed_frequency 0.0

should revert to the old swim behavior.

 

Thank you!


But how do I revert this for people playing my mission? Can I change a def file in my FM folder? Or is there a new spawnarg to turn it off? 
 

I have some underwater sections in my current FM that don’t work with the new swimming style.

Link to comment
Share on other sites

1 hour ago, nbohr1more said:

I don't see a dedicated script event but you should be able to call setcvar to change this:

scriptEvent void setcvar(string name, string value);

And disable new swimming at player's machine until he resets his config. Since this cvar is archiving.

I think it's better to provide the FM to developers somehow, so that we could better understand what's the problem.

Link to comment
Share on other sites

5 hours ago, Goldwell said:

I have some underwater sections in my current FM that don’t work with the new swimming style.

Why doesn't it work? The average swim-speed is the same as before, so it shouldn't be a timing issue.

  • Like 1
Link to comment
Share on other sites

10 hours ago, stgatilov said:

And disable new swimming at player's machine until he resets his config. Since this cvar is archiving.

I think it's better to provide the FM to developers somehow, so that we could better understand what's the problem.

Currently, the setcvar script command is not very useful in general due to this issue.

Mappers have long wanted a way to do things like disable post-processing when under water or invoke

other performance related cvars during outdoor scenes, etc. Most of these uses are obsolete now

but there are still a few tricks you could do with this feature.

Ideally, cvar changes called by script would not archive but that might be tricky to implement...

The easy thing to do is create a non-archiving parent cvar that can be toggled by setcvar.

I'll evaluate the cvar archive code and see if it's not too difficult to add a bypass feature there.

 

Hmm... shouldn't be too hard to add a conditional here:

Common.cpp

// if any archived cvars are modified after this, we will trigger a writing of the config file

cvarSystem->ClearModifiedFlags( CVAR_ARCHIVE );

 

Yep, and add a variable here:

Script_Thread.cpp

/*
================
idThread::Event_SetCvar
================
*/
void idThread::Event_SetCvar( const char *name, const char *value ) const {
cvarSystem->SetCVarString( name, value );

}

 

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

 

47 minutes ago, nbohr1more said:

Currently, the setcvar script command is not very useful in general due to this issue.

Mappers have long wanted a way to do things like disable post-processing when under water or invoke

other performance related cvars during outdoor scenes, etc. Most of these uses are obsolete now

but there are still a few tricks you could do with this feature.

Reading this, I'm afraid to say that we should not implement everything that mappers "long want".
If mappers could change cvars this way, TDM graphics would have probably stayed at Doom 3 level.
We have enough problem with Builder Blocks FM, which decided to change something that should not be touched.
 

Quote

Ideally, cvar changes called by script would not archive but that might be tricky to implement...

The easy thing to do is create a non-archiving parent cvar that can be toggled by setcvar.

I'll evaluate the cvar archive code and see if it's not too difficult to add a bypass feature there.

I think mappers should not change cvars. Probably add a big fat warning at that script function!

The correct way of implementing this is to have a flag in some game object like "forbid running" or "enforce uniform swimming", and save/restore this flag with savegame file. Then take this flag into account in addition to cvar where it is used. Of course, how exactly they are mixed must be decided individually in each case.

UPDATE: Having a spawnarg on something like Goldwell suggested is also OK, and perhaps much simpler.

Link to comment
Share on other sites

45 minutes ago, nbohr1more said:

cvarSystem->ClearModifiedFlags( CVAR_ARCHIVE );

This flag is often used to catch cvar change at appropriate place where it can be handled. So you cannot rely on this flag to guard against mapper's modifications being stored into config file.

Link to comment
Share on other sites

1 hour ago, stgatilov said:

 

Reading this, I'm afraid to say that we should not implement everything that mappers "long want".
If mappers could change cvars this way, TDM graphics would have probably stayed at Doom 3 level.
We have enough problem with Builder Blocks FM, which decided to change something that should not be touched.
 

I think mappers should not change cvars. Probably add a big fat warning at that script function!

The correct way of implementing this is to have a flag in some game object like "forbid running" or "enforce uniform swimming", and save/restore this flag with savegame file. Then take this flag into account in addition to cvar where it is used. Of course, how exactly they are mixed must be decided individually in each case.

UPDATE: Having a spawnarg on something like Goldwell suggested is also OK, and perhaps much simpler.

Yes, that makes sense. We create a player entity flag then mappers can toggle the flag state with their script.

 

And yes, I am well aware that using scripts to play with cvar settings is a bad practice but since the setcvar script event exists

we should either make harmless by preventing it from archiving or remove it (presuming no mission uses it).

 

1 hour ago, stgatilov said:

This flag is often used to catch cvar change at appropriate place where it can be handled. So you cannot rely on this flag to guard against mapper's modifications being stored into config file.

 

So something like this wouldn't work?

 

if ( LiveArchiveState )

{

cvarSystem->ClearModifiedFlags( CVAR_ARCHIVE );

}

LiveArchiveState=true

 

then provoke the "LiveArchiveState=false" during the Setcvar script event

 

?

Of course, I guess there is that funny little issue of "thread safe..."?

 

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

This seems like something out of the scope of a beta test phase and should probably be post-poned to 2.09. As a workaround for the time being, we could simply remove archiving from that cvar so Goldwell can change it in his FM via script. I would still like to know 'though why the new swimming animation wouldn't work in it, @Goldwell.

EDIT: Although, when we enable archiving again eventually on that cvar, the FM would need an update, which is not good.

  • Like 1
Link to comment
Share on other sites

23 hours ago, STiFU said:

Why doesn't it work? The average swim-speed is the same as before, so it shouldn't be a timing issue.

Here's one example where I had an issue.

 

I have a sewer scene where there is machinery spinning at the bottom, if the player gets too close they die. I added a plank of wood across this area (Above where the gears are) and put some loot on it. The player also is fighting against a current I added which is a func forcefield that pulls the player down towards the spinning gears.

 

The purpose of the scene is to create some danger but some reward. If there was no current they could just swim down, grab the loot and then swim back up. No real point of it.

 

In 2.07 you can swim down, grab the loot and then swim back up fighting against the func_forcefield, it's tight but you can still make it. In 2.08 with this new swimming animation, the forcefield will keep the player down there long enough to kill them.

 

I was only hoping there was a simple way to use the old swimming style like a spawnarg on the liquid entity or changing a def file or something.

 

But as we've established it's not a simple change, so it makes more sense logically for me to remove the section of my mission, rather than disrupt something that's in the core mod.

  • Like 1
Link to comment
Share on other sites

Oh that's quite a bummer. Could you maybe reduce the strength of the force field instead of completely removing that section? I wouldn't want you to throw your work out. :(  Especially because it sounds pretty interesting.

Link to comment
Share on other sites

5 hours ago, Goldwell said:

 

In 2.07 you can swim down, grab the loot and then swim back up fighting against the func_forcefield, it's tight but you can still make it. In 2.08 with this new swimming animation, the forcefield will keep the player down there long enough to kill them.

 

 

Even when swim-running?

Link to comment
Share on other sites

1 hour ago, Springheel said:

Even when swim-running?

Yep.

 

  

4 hours ago, STiFU said:

Oh that's quite a bummer. Could you maybe reduce the strength of the force field instead of completely removing that section? I wouldn't want you to throw your work out. :(  Especially because it sounds pretty interesting.

I'll tweak with it and play with it when I get back to that section, and hopefully I can work something out. But it wont be a huge deal breaker if I have to reduce, i'll just make it a smaller scene. The mission is already quite big so maybe cutting some fat will help.

 

It's all about adaptability right? ;)

Link to comment
Share on other sites

It is also an open question if existing missions have a similar problem.
Probably most of mappers don't use external force underwater, so their underwater sections get the same average speed.

By the way, is it possible to configure average player speed underwater? I think it could be quite useful in many cases.

  • Like 1
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.

  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...