 |
A lot of warnings arise from asset redeclarations (I get these even in near-empty devmaps just from having various asset packs in my darkmod directory). It's easy for that to arise when an FM packs assets that get added to the core mod later (or they were added to core already but the mapper is using an .mtr from before that time). However, sometimes the overrides are done deliberately either to restyle the FM's aesthetics (Dragofer does this a fair amount) or to fix bugs that exist in core at the FM's time of release, so I don't recommend simply removing same-named declarations from FM packages. I suspect warnings are also generated when a model references material A, which doesn't exist, even if the model has a skin which replaces A with material B (e.g. the beggar's belt). Does the scope of this include entities' generating a lot of warnings after map load? If so, my proposed fix to 0005050 may be of interest. (There also used to be an annoyance in which func_animate entities could produce warnings about not supporting anim overrides every time they went through their animation cycle, and I'd *thought* that was still there in 2.07, but I couldn't reproduce it a moment ago.) |
|
|
Ah, I'm seeing it again today: script/tdm_util.script (32): Thread 'frameCommands': Function 'overrideAnim' not supported on entity 'func_animate_11' (where the entity is set to "model" "tdm_ai_proguard_use" and "start_anim" "idle_bottle_drunk1"). Another one is 'rigid body not at rest' -- I think this happens if a moveable isn't placed firmly on the surface below. However, placing moveables 0.125 units above the surface below can be a precaution to stop them falling through it. |
 |
Getting rid of all those 'Couldn't load sound 'player_sounds_....' warnings at the start of each map would be great. They've been clogging up consoles since 1.08: https://wiki.thedarkmod.com/index.php?title=List_of_pre_2.0_warnings |
 |
It would be nice to differentiate between these 2 warnings: 1. "Can't load A". Then it's found elsewhere, and all is good. I think searching for dds files, not finding them, and using found non-dds files is an example of this. 2. "Can't load B". Subsequent searches turn up nothing, and all is NOT good. The object is truly missing (or misspelled). IIRC,the loader is told whether the requesting code will accept a default object. If the first warning could be suppressed, a lot of spam will go away. The loader would just silently keep track of progress, and only report a final bad result where the object really can't be found anywhere. |
 |
Fixed in svn rev 8918: WARNING:Couldn't load sound 'sound' using default |
|
|
Mark for FMs cleanup. Warning: WARNING:Image name "0" is too short is caused by this line at the beginning of guis/mainmenu_briefing.gui: background 0,0,0,1 This is already fixed in assets, but old FMs still have the problem, since they (legitimately) override it. |
|
|
Added new system for tracking how assets load each other and showing the chain on "asset not found" warning. Committed in svn rev 8939 (and 8943 for compile fix) The added console printing can be disabled by setting: decl_stack 0 (archivable) You can see some examples below. WARNING:Couldn't load sound 'sound/map_specific/city_bustle_distant_loop01.ogg' using default [map entity: speaker_85] [decl: city_sounds_varied in sound/tdm_ambient_environmental_city.sndshd] [sound: sound/map_specific/city_bustle_distant_loop01.ogg] WARNING:Couldn't load image: textures/flanders/planken_donker_local [model: func_static_108] [decl: textures/flanders/planken_donker in materials/flanders.mtr] [image: textures/flanders/planken_donker_local] WARNING:Couldn't load image: textures/mcity/mcityplain6 [model: _area117] [decl: textures/mcity/mcityplain6 in <implicit file>] [image: textures/mcity/mcityplain6] WARNING:Couldn't load image: statek [map entity: func_static_176] [model: models/darkmod/nautical/galleon_hull_closed.lwo] [decl: statek in <implicit file>] [image: statek] WARNING:Couldn't load image: sleeve_frill [map entity: Lazarova] [decl: atdm:ai_townsfolk_wench_armed in def/tdm_ai_townsfolk_wench.def] [decl: atdm:ai_townsfolk_wench in def/tdm_ai_townsfolk_wench.def] [decl: wench/default in skins/tdm_ai_townsfolk_wench.skin] [decl: sleeve_frill in <implicit file>] [image: sleeve_frill] WARNING:Couldn't load image: tdm_tongue [map entity: Lazarova] [decl: atdm:ai_townsfolk_wench_armed in def/tdm_ai_townsfolk_wench.def] [decl: atdm:ai_townsfolk_wench in def/tdm_ai_townsfolk_wench.def] [decl: atdm:ai_head_female02_red in def/tdm_ai_heads_springheel.def] [decl: head_wench02 in def/tdm_ai_heads_springheel.def] [model: models/md5/chars/townsfolk/wench/wench_head02_new.md5mesh] [decl: tdm_tongue in <implicit file>] [image: tdm_tongue] WARNING:Couldn't load image: arms_legs [map entity: atdm_ai_nobleman02_unarmed_1] [decl: atdm:ai_nobleman02_unarmed in def/tdm_ai_nobleman.def] [decl: tdm_ai_nobleman in def/tdm_ai_nobleman.def] [model: models/md5/chars/townsfolk/commoner/tdm_townsfolk_commoner.md5mesh] [decl: arms_legs in <implicit file>] [image: arms_legs] WARNING:Couldn't load image: guis/assets/heart3 [window: Desktop] [window: Briefing] [window: BriefingMovingPicture3] [decl: guis/assets/heart3 in <implicit file>] [image: guis/assets/heart3] |
|
|
Detected a crash during loading of Rat's Triumphant. It was caused by dangling pointer to idWindow =( Perhaps I will remove idWindow from the stack, or add some sort of memory storage in future. But for now I have simply hacked in a check that window is alive --- it won't crash for sure. Committed in svn rev 8947. UPDATE: Reverted in svn rev 9065 (see below: https://bugs.thedarkmod.com/view.php?id=5170#c13399) |
 |
Project scope done? Create sub-task for 2.10? |
|
|
It is far from done. I'll continue work for 2.10, and I think it doesn't make sense to create another issue just to ensure proper splits into releases. |
|
|
Copying message from 0005433: ============================ Now LoadStack saves all strings (i.e. names) immediately when new object is appended onto stack. The printout code now use the saved strings. In fact, object pointer is never used now: it remains for debugging purposes only. The object can die after Append without any problem. All the strings are stored in a global pool (idStrPool), similar to the ones used for keys/values in idDict. Commands like showLoadStackMemory allow to see how much space is taken by them right now. The list of commits: r9065. Reverted commit 8947 (hack around dangling pointer to idWindow). r9066. idStrPool refactoring (use cpp file, extracted strings printing code). r9067. LoadStack now extracts strings immediately in Append and stores them in its own global pool. This should fix all sort of dangling pointers, since object pointers are never dereferenced. The r9066 has no effect, just some generic refactoring. r9067 has the main changes, and r9065 reverts some hack which is no longer needed. |
- Anonymous
