[fgsfds]

Don't think crash log contains something useful.

Quote

Problem Event Name: AppHangB1
Application Name: mapster32.exe
Application Version: 1.9.9.9
Application Timestamp: 4f833b9e
Hang Signature: ceab
Hang Type: 0
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1049
Additional Hang Signature 1: ceab36e535c4f1b28057f936244b848c
Additional Hang Signature 2: 224d
Additional Hang Signature 3: 224d5a205f630086ea18d54763b2af6e
Additional Hang Signature 4: ceab
Additional Hang Signature 5: ceab36e535c4f1b28057f936244b848c
Additional Hang Signature 6: 224d
Additional Hang Signature 7: 224d5a205f630086ea18d54763b2af6e

I tried to launch mapster and eduke32.exe in win xp compatability mode and it seems it works well without any crashes. I'll try to test it for a longer time.

[Helixhorned]

empy, on 28 April 2012 - 12:53 PM, said:

I tried to launch mapster and eduke32.exe in win xp compatability mode and it seems it works well without any crashes. I'll try to test it for a longer time.

Well that's a result at least! Hear that, everyone?

[fgsfds]

That's funny how Win XP mode solved some annoying problems. Now duke runs in polymer and polymost with Aero support.

[Micky C]

The duke infosuite mentions that you can make a 2 way train self oscillate, which I take to mean move backwards and forwards continually. Is there an example map I can look at to study the effect? I'm having trouble getting it to work.

[Paul B]

 Micky C, on 03 May 2012 - 12:16 AM, said:

The duke infosuite mentions that you can make a 2 way train self oscillate, which I take to mean move backwards and forwards continually. Is there an example map I can look at to study the effect? I'm having trouble getting it to work.

Hi Micky, yea i've done that in a map to create that effect. To do that you place a Sector effector lowtag of 10 on the two way subway car. It will cause the car to bounce back and forth automatically. I have a sample map i can send you when i get home if you still want to see how it's done.

[Diaz]

Has anyone else noticed that performance is higher in Mapster32 when using Unreal-style movement?

Also, when using that movement style, oscil type animating tiles don't play correctly...they do work when not moving, or when using the arrow keys to move. These animations are also messed up in the game executable.

[Hank]

Paul B, on 03 May 2012 - 07:18 AM, said:

Hi Micky, yea i've done that in a map to create that effect. To do that you place a Sector effector lowtag of 10 on the two way subway car. It will cause the car to bounce back and forth automatically. I have a sample map i can send you when i get home if you still want to see how it's done.

can I have that map also? It will go to the wiki (if you permit), saves me time to do it myself.
Old mappers (like me) made a sector+SE31+SE10+GSPEED, your version is a whole lot simpler.

[Plagman]

Diaz, on 03 May 2012 - 08:49 AM, said:

Has anyone else noticed that performance is higher in Mapster32 when using Unreal-style movement?

Also, when using that movement style, oscil type animating tiles don't play correctly...they do work when not moving, or when using the arrow keys to move. These animations are also messed up in the game executable.

I think the aiming code doesn't run while Unreal-movement is in progress, which is probably why it appears faster. A lot of stuff gets skipped IIRC, including the animation stuff that you already noticed.

[Paul B]

Hank, on 03 May 2012 - 02:24 PM, said:

can I have that map also? It will go to the wiki (if you permit), saves me time to do it myself.
Old mappers (like me) made a sector+SE31+SE10+GSPEED, your version is a whole lot simpler.

Okay here is the map with the subway car effect. It is used to make a re-occuring alarm sound. You'll find it in the South East Corner of the map. You can see the attached and if you want to dumb down the effect to include it in the Wiki by all means please do so.

Attached File(s)

•  RunningScared.zip (26.34K)
  Number of downloads: 293

[Paul B]

A recent bug has surfaced with TROR and deleting walls using recent builds of mapster I tested using mapster release (R2615) and I'm pretty sure previous releases have been plagued with the same problem. It has to do with TROR and deleting walls in a TROR extended sector. We now receive the error message as shown when attempting to delete walls within an extended TROR sector:

The error states: "Deleting Wall # would leave Sector # with 2 walls.

This is an incorrect error message and the wall point don't get deleted. I noticed this bug when trying to clean up unnecessary walls in the Parkade.map. The cross hatch symbol (#) above represents the wall number and the sector number associated with the walls I'm trying to delete.

Okay I've taken it upon myself to go back 3 months and slowly keep trying different releases of Eduke until I found the exact version that corrupted the TROR wall deleting feature. This problem was introduced with R2599 and since that release it has been broken in all future updates. Can you please fix this functionality again Helix as it has made TROR very difficult to use the way it is now.

I hope this helps provide enough technical information for a fix.

Thanks!

[Diaz]

Plagman, on 03 May 2012 - 08:30 PM, said:

I think the aiming code doesn't run while Unreal-movement is in progress, which is probably why it appears faster. A lot of stuff gets skipped IIRC, including the animation stuff that you already noticed.

That explains it, thanks! Now what's weird is that oscil doesn't work in EDuke32 either but that doesn't belong in this thread...

[Helixhorned]

Paul B, on 03 May 2012 - 10:23 PM, said:

I hope this helps provide enough technical information for a fix.

It's nice of you to have done some research, but this is not a bug. When you're dragging or deleting wall-points of extended secors, you're potentially acting on many of them, so Mapster has to assure that no sector is left with less than three walls. The check is a recent addition, and the bug that existed before has been pointed out by Diaz on the preceding page.

[Paul B]

Helixhorned, on 04 May 2012 - 04:01 AM, said:

When you're dragging or deleting wall-points of extended sectors, you're potentially acting on many of them, so Mapster has to assure that no sector is left with less than three walls.

Hmm... well this prevents the removal of unnecessary walls which get used up really quickly with TROR. Would it make more sense to have the wall limit 2 instead of 3? That way there always has to be two points for a wall. Otherwise, I end up having all these extra sectors and walls I can't remove in a TROR environment. I've had to resort to going back to build R2597 as my primary editor so that I can use TROR without having all these unnecessary walls. I find it strange because I've been using TROR for a while and it was never a problem before. Now I find I'm making a mess of having all these overlapping sectors that I can't clean up because it won't let me delete them. Maybe my technique is wrong because I seem to be the only person complaining about this problem. I'm curious to know how other people are handling this and if there is a better way to manage walls with TROR?

Thanks

[TerminX]

I don't have an answer to your general question as I'm not a mapper, but yes, your technique is wrong... sectors with less than 3 walls are corrupt sectors, so you're essentially saying you prefer to use an older version of the editor because creating corrupt maps is more convenient for you. This is definitely not a very good way to go about making a map.

[Paul B]

TX, on 04 May 2012 - 08:55 AM, said:

I don't have an answer to your general question as I'm not a mapper, but yes, your technique is wrong... sectors with less than 3 walls are corrupt sectors, so you're essentially saying you prefer to use an older version of the editor because creating corrupt maps is more convenient for you. This is definitely not a very good way to go about making a map.

In fact, there is not one corrupt sector in Parkade.map and what I am talking about is a wall that has three vertices. If you try to delete one you cannot because of this new limitation. When you play with TROR you will see it makes it very difficult to clean up vertices in extended sectors because of this.

[Helixhorned]

The rationale for considering a 2-walled sector corrupt is that it's not useful as such any more, being a mere line, and that bugs in the engine may be hit then (they certainly did in the past; I know that Lezing uses such sectors for alignment hacks, but that's a different story). So, if you were to be left with a 2-walled sector as a result of an editing operation, you could get rid of the sector beforehand in the first place, for example by joining it to a sector connected by a red wall, or if the sector has only white walls, just deleting it or unlinking (Ctrl-U) its vertical neighbors. Bottom line is, I don't see a case where the check and warning would impede proper editing.

[Paul B]

Okay I just tried using the latest version of Mapster with a new map file. It appears it works the way I want it to with a fresh new map. I think the problems I am experiencing are specific to Parkade and the way Parkade was created from previous versions of the Mapster Editor. Sorry for being a pest I never thought of trying a new map as I am still editing and tweaking parkade which TROR was created using an older version of Mapster.

Thanks for your time Helix. Have a great weekend! I'm looking forward to more mapping this weekend! =)

[Helixhorned]

The sector you have to edit in such a case in not (usually) the one you're currently editing but a lower or higher one. Try noting the exact sectnum in the message and jumping to that offending sector, which necessarily has exactly three walls.

Also note that your suggestion of allowing the 2-walled sectors to silently appear with point deletion doesn't fix the real problem: you'd eventually get to a point when a 1-walled sector would be created. The ideal fix is to auto-delete sectors appropriately with point deletion, but Mapster isn't that sophisticated yet.

[Helixhorned]

Paul B, on 04 May 2012 - 10:08 AM, said:

Thanks for your time Helix. Have a great weekend! I'm looking forward to more mapping this weekend! =)

Glad to help, but editing your post like that will seriously confuse users that will read this at a later time and don't check the timestamps. Oh the joys of parallelism...

[Paul B]

Helixhorned, on 04 May 2012 - 10:41 AM, said:

Glad to help, but editing your post like that will seriously confuse users that will read this at a later time and don't check the timestamps. Oh the joys of parallelism...

Yea I'm sorry about that Helix, I have a reputation for being long winded on the forums so I was just trying to eliminate my complaint in hopes not to confuse anyone anymore.

I hate to post multiple problems within 24 hrs. But... here is another observation I have found and correct me if i'm wrong. This has to do with the Polymer lighting or the console command that enables the mode I am referring to is: r_pr_lighting=1 coupled with a certain sprite in Eduke. Sprite 1079. Its a toxic gas canister that emits a green glow. At the moment of writing this I am using Duke High Resolution Pack and I'm not sure as of yet if this is part of the problem.

In any case I was doing some shading with sprites giving them a palette of 4. If I had a nearby Sprite 1079 the light from this canister exposes the sprites that have a palette of 4 showing the sprite object instead of a shade.

Okay I guess I can answer my own question here. I just tested it by disabling the HRP and there wasn't a problem. So I will conclude that this problem is because of the Duke High Resolution Pack not because of Eduke or Polymer lighting. I'll leave this post for reference only.

[fgsfds]

Can you add feature like "select all sprites with tile #" and "delete all selected sprites"? I think it will be very useful.

[Helixhorned]

This is doable from m32script using sethighlight like this:

for i allsprites, ife .picnum XXX sethighlight 16384 i 1

[Diaz]

If you can't delete a point by dragging it over another even you should be able to, it probably means you have two overlapping points somewhere in your map that the editor didn't delete because it would create map corruption. When you have one of those you can't delete points in the whole map anymore (the editor will say "invalid operation". If this is your case, you're gonna have to find that offending point manually I'm afraid...

[fgsfds]

I used 8-bit texture with 48x96 resolution on the floor. This is how it looks in polmost and software. http://i.imgur.com/CbYuR.png
Can this be fixed?

[Diaz]

Textures that are not powers of two have always looked like that in software... I'm not sure it can be fixed.

[TerminX]

Are you using some old build? I'm pretty sure Helixhorned came up with a way to properly draw stuff on the floor without requiring a power of 2 for the texture dimensions, but maybe that was only for sprites.

[fgsfds]

No, it's the latest build. Not power of 2 textures works fine on walls and sprites but not floors and ceilings.

[Diaz]

Or maybe the fix was only for OpenGL modes? I haven't used software in ages so I can't recall if it has ever worked, but last time I used it floor textures were like this.

[Danukem]

Diaz, on 08 May 2012 - 07:20 AM, said:

Or maybe the fix was only for OpenGL modes? I haven't used software in ages so I can't recall if it has ever worked, but last time I used it floor textures were like this.

The problem never existed in OpenGL modes. And note that he said it looks like that in both software and Polymost.

[fgsfds]

No, I meant it looks ok in polymost \ polymer (upper half of screenshot).